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.
>> 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.
>> 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".
Agreed.
Kindest regards,
--
Fernando Gont
e-mail: [EMAIL PROTECTED] || [EMAIL PROTECTED]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
