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).
>>>> 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.
>>>> 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.
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
