Fernando,
Thanks for the quick feedback, please find some comments inline.
On 9/27/2006 1:40 AM, Fernando Gont allegedly said the following:
> At 23:27 26/09/2006, Carlos Pignataro wrote:
>
>>>> Page 4, Section 2:
>>>> " This document also addresses a fundamental problem in ICMP
>>>> extensibility. Many of the ICMP messages addressed by this memo
>>>> include an "original datagram" field. The "original datagram" field
>>>> contains the initial octets of the datagram to which the ICMP message
>>>> is a response. Although the "original datagram" field is of variable
>>>> length, the ICMP message does not include a field that specifies its
>>>> length."
>>>>
>>>> I'm not sure I see the "fundamental problem". When it comes to
>>>> "extensibility", you can always define a new ICMP type/code.
>> In my reading, the "fundamental" (and I'm reading innate, relating to
>> essential structure) extensibility problem for a given ICMP is having a
>> variable length field without a Length attribute;
>
> Given that there was supposed to be only one field in the payload
> ("original datagram"), I'm not sure there was a need for such a length field.
>
>
>> defining new ICMP
>> types/codes is a possible solution to this fundamental problem. But one
>> that has drawbacks as well, such as possibly needing to update all
>> traceroute implementations for instance (I guess the problem description
>> is how to make these messages extensible without breaking existing
>> applicaions). Do you think that "fundamental problem in ICMP
>> extensibility coupled with/while retaining backwards compatibility" is
>> more accurate?. Please note that defining new ICMPs has been suggested
>> and discussed in this list as well.
>
> 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.
The current memo also addresses backwards compatibility with existing
ICMP implementations that either do not implement the extensions
defined herein or implement them without adding the required length
attributes. In particular, this draft addresses backwards
compatibility with certain, widely deployed, MPLS-aware ICMPv4
implementations that send the extensions defined herein without
adding the required length attribute.
>
>
>>>> 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.
>
>
>>>> 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 agree this is possible (under ICMP "relaying" from a tunnel, as in
>> Section 4 of RFC2003), though with "compliant extensions", the extension
>> could (depending on the offending datagram's length) be placed passed
>> the complete original datagram. In my experience however, the
>> implementations I've seen use the "soft state" method in Section 5 of
>> RFC2003, where this tunneling problem would be much more unlikely if at
>> all possible.
>>
>> IMHO, it would be useful to add a brief paragraph at the end of Section
>> 5.1 mentioning these 2 cases and their relationship to non-compliant and
>> compliant extensions, to expand the "no apps have been identified".
>
I just wanted to ack that this would indeed be IMHO a very strange case,
and a quick comment on:
> 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). 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).
> Agreed.
>
> Kindest regards,
>
Thanks again for the comments !
--Carlos.
> --
> 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
