Subject: [Int-area] Re: Feedback on draft-bonica-internet-icmp-08

From: Ron Bonica <[email-masked]>
Date: Mon, 02 Oct 2006 10:43:03 -0400

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-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Fernando Gont <[email-masked]>
Date: Mon, 02 Oct 2006 17:02:27 -0300

At 21:36 27/09/2006, Carlos Pignataro wrote:

> > 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).
>
>These seem to be covered in the Introduction:
>
>    Protocol
>    designers can make an ICMP message carry additional information by
>    encoding that information in an extension.
>    ...
>    Reference [6] and reference [7] provide
>    sample applications of the ICMP Extension Object.

I think the text I just received from Ron addresses my point. I 
basically asked to state clearly what is the motivator of these 
extensions. i.e. "we are trying to solve X problem, we cannot do this 
with the current ICMP messages because Y (blah, blah)"

> > 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.
>
>The evaluation of these scenarios seems to be inline with what the draft
>currently says:
>
>    So, only those ICMP applications that
>    identified.

I get a feeling from this paragraph that "there's no problem, because 
nobody is doing this". I'd switch the discussion to "what if somebody 
were doing this?". There's the case of the checksum, but there's also 
the case of rewriting other fields, such as the port numbers.

As I have stated in other posts, you may certainly get to the 
conclusion that in most deployed scenarios, there won't be much 
trouble. The reasons being:

* You are just playing with ICMP "soft errors". Therefore, even if an 
error message is misdirected, there won;t be a connection reset, or anything.
* In most cases, it will be impossible to check the TCP checksum. 
(Probably the only possible case is that of ICMP error messages 
elicited by pure ACK segments)
* Use of IP options: I bet the header does not usually get to 60 
(although I would have to look back at the IPsec spec)

And there might be others...

Kindest regards,

--
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1