At 16:38 26/09/2006, Ron Bonica 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.
I guess this depends on your definition of the word "fundamental". I
agree that you can always add a new ICMP type/code. However, you can't
add very much to existing messages.
So, I would like to push back on this comment.
Is there any reason for extending the current codes, rather than
defining new codes which can include (from starters) the extensions
draft-bonica-internet-icmp proposes?
> Page 7, section 4:
> " The length attribute represents the length of the "original datagram"
> field, measured in 32-bit words. When the length attribute is
> specified, the "original datagram" field MUST be zero padded to the
> nearest 32-bit boundary. Space for the length attribute is claimed
> from reserved octets, whose value was previously required to be zero."
>
> In the case of ICMPv6, this new length field will not accommodate
> those cases in which as much information from the original payload is
> being including without exceeding IPv6's minimum MTU (i.e., a
> one-byte length field is not enough).
>
Good catch. 4 x 255 = 1020 < 1280. I will add one more bit to the v6
lengths!
Good.
> 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.
I agree that these TCPs will inappropriately discard some ICMP messages.
However, I would argue the following in response:
a) inappropriate discard will only occur for a small range of packet sizes
b) the inappropriate discard of an ICMP message is not so bad
I agree with both of your points.
Being that the TCPM WG is working on this, it'd probably be a good
idea to clarify this, and probably include a reference to the
relevant section of draft-ietf-tcpm-icmp-attacks.
In the same way, I think it'd be appropriate to include a few words
on this document in the ICMP attacks draft.
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.
Agreed.
This may also cause an ICMP message to be misdirected to a wrong TCP
endpoint. This is not an issue for soft errors, but might be an issue
for hard errors (which the specs currently state that should cause
the corresponding connection to be reset). Anyway, I think none of
the messages type/codes you propose to extend represent hard errors
(see my other post).
> 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.
Although theoretically possible, this would be a very odd case indeed!
First, the TCP header would have to begin after the 120th octet. So, we
would need to have four or five layers of IP-in-IP encapsulation.
If IP options are in place, you only need one layer of IP-in-IP encapsulation.
Second, the source address on the outermost IP header would have to be
on the same device as the source address on the innermost IP header.
(Otherwise, the ICMP messages would never arrive on the box where TCP
was running.) If this were the case, I would wonder what all those
levels of encapsulation were about.
The tunnel endpoint by process the ICMP error message, and resend a
"new" one to the TCP endpoint. IIRC, this is what some drafts meant
for the softwires WG suggest?
I'm not really sure whether there are implementations that currently
do this sort of thing.
> Page 14, Section 6:
> " As stated above, the total length of the ICMP message, including
> extensions, MUST NOT exceed the minimum protocol MTU. Figure 6
> depicts the ICMP Extension Header."
>
> As explained above, this requirement cannot be met: IPv4's minimum
> MTU is 68 bytes. You may change this as explained above (s/minimum
> MTU/minimum reassembly buffer size/), though.
I will replace "minimum MTU" with "minimum reassembly buffer size".
Good.
> Page 15, Section 6:
> Version: 4 bits
>
> ICMP extension version number. This is version 2.
>
> Version 1 is that used by the non-compliant implementations?
If we do this, we lose backwards compatibility with what is already
widely deployed. I would like to push back on this one.
I just wondered what was version "1" being used for. Not sure if the
draft mentions that that version number is being used for the
"non-compliant" messages. (Might be good to point out).
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
