The MPLS WG Archive

["Ferrell, William" <William.Ferrell@titan.com>]

I tend to agree , useing the CRC is one of the oldest and proven methods but
is one of the easiest to subvert and corrupt. When developing the protocol
one has to keep in mind of a way of integrating a security solution. oftens
we've put in a functional solution and then been forced change/modify it to
fit with a security option and ending up with a less effective product in
the end.
Will

-----Original Message-----
From: Naidu, Venkata [mailto:Venkata.Naidu@Marconi.com]
Sent: Thursday, March 27, 2003 12:12 PM
To: 'Shahram Davari'; 'curtis@fictitious.org'
Cc: 'Thomas D. Nadeau'; 'George Swallow'; W. Mark Townsley; Andrew G.
Malis; 'mpls@uu.net'; tnadeau@cisco.com
Subject: RE: [PWE3] MPLS PID 


Shahram,

-> First of all I meant computing CRC over the first 20 byte of 
-> payload header
-> and comparing it to the suspected IP CRC in octets 11 and 12 
-> of the payload.
-> If they match then it is IPv4, if not it is something else 
-> (similar procedure for IPv6)
-> 
-> Secondly I am proposing it now. Is there a problem? 

  Yes. There is a problem. First of all relaying on CRC to
  figure out the *type* of payload is not at all advisable.
  One could produce (there is a remote possibility) a payload
  which is not IPv4 or IPv6 but the CRC can be matched to
  the payload of first 20 bytes to the bytes in 11 & 12.

  RFC1071 uses 16 bit's one's compliment, which we all know
  that won't catch all the bit errors/flips.

Venkata.