-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ron Bonica wrote: > Folks, > > During a very pleasant telephone conversation, Joe Touch convinced me > that I am not so much _extending_ selected ICMP messages as > _redefining_ selected fields in those ICMP messages. At first glance, > the distinction between extension and redefinition might appear to be > inconsequential, but it is not. > > If we were extending ICMP, future ICMP developers could write code that > is compliant with RFCs 792 and 1812, not specifying the length attribute > described in draft-bonica-internet-icmp. In fact, that > future programmer could be totally unaware of draft-bonica. > > However, omission of the length attribute could cause compatibility > problems. > > In order to maintain compatibility, when a future ICMP programmer codes > an ICMP message with the "original datagram" field greater than or equal > to 128 octets, that programmer MUST specify a length attribute. Minor addition: AND all ICMP programmers MUST NOT parse more than 128 bytes of an ICMP message unless indicated as valid by a nonzero length attribute. FWIW, the term 'future' above may be misleading; both requirements apply to all implementations - existing and future, since an exhaustive search of existing implementations is infeasible. Joe > So, in the next few days I will post an updated version of draft-bonica > that reflects Joe's comments. I realize that the word "redefinition"will > expose the draft to greater scrutiny, but I think that this is the right > thing to do. > > Ron > > Joe Touch wrote: > >> >>Ron Bonica wrote: >> >> >>>>Joe Touch wrote: >>>> >>>> >>>> >>>>>I raised a few on the INT-AREA mailing list in Oct 2005 in the >>>>>pre-ICMP/MPLS split which were not addressed in either the 00 or 01 >>>>>versions of this draft. >>>>> >>>>>--- >>>>>Use of the "unused" area, as Ron suggested, seems inappropriate because >>>>>those fields are not known to be 'cleared' by existing ICMP sources, so >>>>>their value cannot be reliably used for flags IMO. >>>>>--- >>>> >>>> >>>>Joe, >>>> >>>>RFC 792 compliant implementations clear all unused bits. The statement >>>>below is from RFC 792: >>>> >>>>"Any field labeled "unused" is reserved for later extensions and must be >>>>zero when sent, but receivers should not use these fields (except to >>>>include them in the checksum)." >>>> >>>>The rest of the argument hinges upon us being able to trust that a >>>>non-zero value in the length field really represents the length of the >>>>original-datagram field. If we can't agree on that much, the rest of the >>>>argument is moot. >> >> >>The issue is that the receiver doesn't check that the fields are zero; >>that makes sense from the sense of the original spec, but means that >>setting their value will not be checked by the existing implementations. >>This means that the payload that the option refers to CANNOT change >>based on those fields; it can be AUGMENTED (mean more), but the existing >>meaning (without length) cannot change. See below... >> >> >> >>>>>A few further concerns are below: >>>>> >>>>>The technique of using a valid checksum to "correctly determine" that >>>>>the option is present at the 137th byte is overstated. The 1's >>>>>complement checksum can be used to infer that data has not been >>>>>corrupted, but it is not appropriate for data synchronization (the use >>>>>here), as would, e.g., a stronger sum such as a CRC. 1's complement is >>>>>known to be susceptible to packet corruption that dovetails portions of >>>>>packets together (see Stone and Partridge, Sigcomm 2000). >>>> >>>>I reluctantly agree... >>>> >>>>If the checksum is not correct, the application determines that the >>>>subsequent bytes do not represent valid extensions. However, if the >>>>checksum is correct, the application is not 100% certain that the >>>>subsequent bytes represent valid extensions. It is certain only to some >>>>level of probability. >>>> >>>>However, I think that there is a way to work around this. See my final >>>>comment, below. >>>> >>>> >>>> >>>> >>>>>Finally, and most importantly, the document does not sufficiently >>>>>address how it will affect the payload of ICMP packets, in changing >>>>>existing Internet recommendations. When the payload of certain messages >>>>>is smaller than 128 bytes, it will work fine. However, section 6 >>>>>suggests (somewhat obscurely) that future implementations send only 128 >>>>>bytes to represent the datagram. This is in direct opposition to the >>>>>recommendations of RFC 1812. >>>> >>>> >>>>We could back off from that suggestion. >>>> >>>>The only reason that we make it is because a widely deployed base of >>>>partially compliant TRACEROUTE applications relies on the original >>>>datagram field containing exactly 128 octets. However, this is not a >>>>hard requirement. If an ICMP implementation doesn't need to be backwards >>>>compatible with those partially compliant TRACEROUTE applications, it >>>>could send more octets. >> >> >>Dealing with one widely deployed base isn't the same as the issue of the >>current recommendations, as per 1812. This document appears to override >>that recommendation - that certainly needs to be more clear, at least. >> >>I would prefer wording that addresses the impact more specifically: >> >> IF this option is supported and used in a particular reply, >> the node MUST NOT send more than 128 bytes of the >> original packet. This overrides the reccomendation of RFC1812 >> to include s much of the original packet as possible, >> up to a total of 567 bytes, and may affect the parsing of the >> packet contents in some cases. >> >>(this is alluded to, but not as specifically stated. >> >> >> >>>>>The only solution to these issues appears to be the creation of new type >>>>>codes and the emission of two errors for each ICMP error - one under the >>>>>current code, one with the new, augumented code. Short of this, it is >>>>>unclear that a backward compatible extension such as this can usefully >>>>>coexist. >>>> >>>>Do you think that the proposal could be salvaged by saying that a fully >>>>compliant application MUST NOT parse for extentions unless a length >>>>attribute is specified? >> >> >>Sure. The trouble is that this is not backward compatible. >> >>Compliant existing implementations will ignore the length attribute, and >>then can (and should) interpret the entire payload as a prefix of the >>original segment. >> >>There is nothing they can do to know this is not the case. They can't >>check the IP checksum - the entire packet may not be included. >> >> >> >>>>That said, vendors would have two choices: >>>> >>>>- field fully compliant applications, understanding that TRACEROUTE >>>>would not be backwards compatibile with partially compliant ICMP >>>>implementations >> >> >>I don't understand how existing implementations that follow existing >>specs aren't fully compliant. This seems like an extension to ICMP; if >>you're overriding existing standards in a non-backward compatible way, >>that would be bad ;-) >> >> >> >>>>- field a partially compliant TRACEROUTE, possibly in addition to a >>>>fully compliant version of the same program. >> >> >>I don't know what the partially-complaint version refers to. I was >>thinking of two fully-compliant versions: >> >> - one that knows the existing codes >> - one that knows new codes with new meanings >> >>Joe >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD6RwjE5f5cImnZrsRAlXJAKDV20fePKM0ToPoRT4GIb6fmJvkmACfW1Qg PpQt3EYZH1axzvdLAm18r9Y= =PMfv -----END PGP SIGNATURE----- _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
