Fernando, On 9/27/2006 4:00 PM, Fernando Gont allegedly said the following: > At 11:24 27/09/2006, Carlos Pignataro wrote: > >>> This is the bottom-line for some of my comments: I think it should be >>> clear what is driving he addition of this extensions, and why it's >>> being done this way, rather than defining new message types/codes. >> I'd think that this existing para (and the two paragraphs adjacent to it >> not copied here) cover it: >> >> Therefore, this document proposes a >> length attribute as well as an extension structure that is appended >> to the ICMP message. > > It is not yet clear to me why you need to include in the ICMP error > message more data than the first chuck from the original datagram. > What type of problem does these extensions let me solve? > > This type of stuff should be present in the introduction (if not in > the abstract itself).
These seem to be covered in the Introduction: Protocol designers can make an ICMP message carry additional information by encoding that information in an extension. ... Reference [6] and reference [7] provide sample applications of the ICMP Extension Object. > > > >>>>>> Page 12, Section 5.1: >>> [....] >>>>> AFAIK, ICMP extensions will only cause the ICMP message to be discarded >>>>> when the trailing octets of the TCP segment are overwritten by the >>>>> extension header and the TCP segment is not truncated in any other way. >>>>> >>>>> When this happens, the effect is no worse than having lost an ICMP >>>>> message due to congestion or an ACL. >>>> Pekka Savola raised the same point. A description of this with a pointer >>>> to Appendix C of draft-ietf-tcpm-icmp-attacks would likely not hurt. I'd >>>> point out though that this is true for "Non-compliant Extensions", and >>>> that "Compliant" extension could (in some cases, depending on the >>>> original datagram's len) be placed passed the original datagram (and >>>> allowing for the tcp checksum to pass). >>> Agreed. I think this clarification would be useful. >> I was thinking about this a bit more. The section (5.1) that contains >> this paragraph intends to address backwards compatibility between >> classic (legacy) applications receiving ICMPs with extensions. Would the >> embedded tcp checksum check be more precisely a lateral-compatibility >> case? A concurrency case that can be solved with "compliant extensions"? >> I still think that including the clarification would be helpful though. > > I'm don't really know if there are any implementations that perform > the TCP checksum. Firstly, because the driver of all the ICMP > modifications proposed in the ICMP attacks draft is security, and the > checksum doesn't improve it. Secondly, because in many (most?) cases > you won;t receive a full datagram to be able to check it. > > But what's in that draft is pretty much what most vendors have > implemented. That's why I think a clarification on this aspect would be > useful. > The evaluation of these scenarios seems to be inline with what the draft currently says: 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. Like I said though, adding a couple of additional sentences, pointer to icmp-attacks Appendix C, and how to prevent using "compliant extensions" might not hurt at all, and could certainly improve the document. > > >>>>>> 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. > [....] >> I just wanted to ack that this would indeed be IMHO a very strange case, >> and a quick comment on: > > The bottom-line here is that the specs allow for this to happen. > Honestly, I don't think this is a "killer", but I think this type of > thing does need to be addressed. > > >>> If IP options are in place, you only need one layer of IP-in-IP >>> encapsulation. >> With tcp over single layer of IP-in-IP, it seems that the (allowed but >> very odd) worst encap case for the embedded original datagram is having >> the encapsulating and encapsulated ip option headers with ihl of 15 (60 >> octets each); this would leave 8 octets for TCP. This is no worst than a >> number (majority to my knowledge) of existing icmp implementations (IPH >> + 64 bits of transport). > > Many implementations have been updated to include more than that, in > response to my ICMP drafts. FreeBSD improved this a year ago or so. > Linux has been doing this for years, IIRC. > > >> In fact, those 8 bytes include i. the ports, so >> there is no mis-demultiplexing possible, and ii. the sequence number, so >> the receiver can check that the icmp corresponds to a sent but >> unacknowledged segment (snduna <= seq < sndnxt). > > The point here is that you may be overwriting information in a way > that is not really backwards compatible. As I said above, this does > not necessarily means that it's a killer to your proposal. But IMHO > the document should do this analysis. If you conclude that in most > deployment scenarios this will not have any negative effects, good. > But I think the draft should include a discussion on this. I see your point, see above. Many thanks for the thorough review and comments. --Carlos. > > Kindest regards, > > -- > Fernando Gont > e-mail: [EMAIL PROTECTED] || [EMAIL PROTECTED] > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > -- --Carlos Pignataro. Escalation RTP - cisco Systems _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
