Hi Fernando
I am about to submit another version (v10) of the draft that addresses
your comments. Responses inline....
Fernando Gont wrote:
> 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?
>
I have added a paragraph to the bottom of Section 2 that points to
draft-ietf-mpls-icmp and draft-atlas-icmp-unnumbered-01 as cases
where it is better to extend an existing ICMP message than create a new
one. In both cases, we are extending the ICMP Time Expired Message for
consumption by TRACEROUTE. The alternative would have been to make
routers emit two ICMP messages every time they dropped a packet due to
TTL expiration. One ICMP message would be consumed by old applications
and the other by new applications.
>
>> > 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.
>
>
I have added some text about this issue to the bottom of Section 5.1.
>
> 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).
>
Sorry, I misunderstood the question the first time I read it. We are
using version number 2 because that is what is widely deployed. We
bumped the version number to "2" back in 1999, even though we didn't
really need to. Implementations with version "1" were never deployed.
Ron
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
