Notes below... Fernando Gont wrote: >> > Page 12, Section 5.1: >> > " When a classic application receives an ICMP message that includes >> > extensions, it will incorrectly interpret those extensions as being >> > part of the "original datagram" field. Fortunately, the extensions >> > are guaranteed to begin at least 128 octets beyond the beginning of >> > the "original datagram" field. So, only those ICMP applications >> that >> > process the 129th octet of the "original datagram" field will be >> > adversely effected. To date, no such applications have been >> > identified." >> > >> > I think this assumption is wrong. Some implementations may be checking >> > the TCP checksum included in the TCP header of the original >> datagram. In >> > those cases, these extensions will likely lead to an error, with the >> > ICMP message being discarded. >> >> Agreed, but the statement in the doc says that no such implementations >> have been identified. Althought they could check the TCP cheksum, they >> currently don't. > > Unless you have assessed every existing implementation (which is very > unlikely), the statement "No such implementations have been identified" > doesn't mean much. > > Again, this is not at all a killer for the document. I just mean that > some text should be included both on this and on the possibility of > overwriting some fields that may lead to unexpected results.
I thought that was what the checksum was there for (maybe I'm remembering it fuzzily; I didn't dig deep into it since the last IETF). It might be useful to highlight that where this is mentioned, though. >> > Also, if some kind of tunnelling mechanism was in place when the error >> > was elicited, important information such as TCP's port numbers may >> be at >> > (or past) the 129th octet. This may lead to the ICMP error messagebeing >> > demultiplexed, for example, to the wrong TCP endpoint. Thus, >> > guaranteeing that the extensions are "at least 128 octets beyond the >> > original datagram" may not be enough. >> >> ICMPs in tunnels are meaningful per se only to the tunnel endpoint, >> i.e., to the source of the tunnel. That endpoint MAY generate a >> subsequent ICMP back to the source or might not (as per Sec 4 of >> RFC2003), but full unrolling of all interior headers is not presumed to >> be possible (see Sec 5 for a solution involving soft-state, albeit >> cumbersome. > > There may be more than one instance of tunelling. In some scenarios it > may be possible to unroll the interior headers - one per tunnel endpoint. Agreed; 2003 addresses that specifically. > Also, by overwriting the 129th byte, you may overwrite the TCP ACK. And > there are firewall implementations (OpenBSD's PF, at least) which check > the ACK field when it's available. Again, 2003 covers this. There are cases where the interior is meaningless to parse. >> If they were, then RFC1122 would require MUST rather than >> SHOULD for as many payload bytes as possible. > > RFC1222 was written, as all other specs, by humans. > Also, I don't think tunnels were as common in 1989 as they are nowadays. Agreed, but that's what 2003 specifically addresses anyway in Sections 4 and 5 (i.e., that 1122 didn't talk about tunnels, and that sending less than the full packet affects relaying). > Last, but not least, enforcing a such a MUST for ICMP would not make > much sense. If you really mean a MUST, you wouldn't be using > non-reliable signalling, after all. What's inside can be a MUST, even if the packet is lost ;-) Joe
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
