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

From: Ron Bonica <[email-masked]>
Date: Tue, 26 Sep 2006 15:38:24 -0400

Fernando,

> 
> Page 4, Section 2: Protocol
> "   designers can make an ICMP message carry additional information by
>     encoding that information in an extension."
> 
> Maybe s/extension/extension object/ ?
> 

O.K.

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

> 
> 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!

> 
> Page 10, Section 4.6:
> "   The ICMP Extension Structure MAY NOT be appended to any of the other
>     ICMP messages mentioned in Section 4."
> 
> Did you mean "MUST NOT"?

I will change this to MUST NOT.

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

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.

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

> 
> Page 13, section 5.3:
>     Provided that the entire ICMP messages does not exceed the minimum
>     MTU (576 octets for ICMPv4 or 1280 octets for ICMPv6), there is no
>     upper limit upon the length of the "original datagram" field.
> 
> This is incorrect. IPv4's minimum MTU is 68 octects, not 576 (576 is 
> the minimum reassembly buffer size). In the case of ICMPv4 The limit 
> is imposed by the reassembly buffer size, not by the MTU.
> 

I will replace "minimum MTU" with "minimum reassembly buffer size".

> 
> Page 13, Section 5.3:
> "   However, each vendor will decide how many octets to include.  Those
>     wishing to be backward compatible with non-compliant TRACEROUTE
>     implementations will include exactly 128 octets.  Those not requiring
>     compatibility with non-compliant TRACEROUTE applications may include
>     more octets."
> 
> This is not compliant with RFC 1122 itself. I think this modifies a 
> "SHOULD" in RFC 1812. (RFC 1812 states that as much information from 
> the original datagram SHOULD be included, without exceeding....?)

RFC 1812 says "SHOULD", not "MUST". So, I think that is is OK to suggest
a reason why some vendor might not.

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

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

> 
> Page 15, Section 6:
> "   Checksum: 16 bits
> 
>        The one's complement of the one's complement sum of the data
>        structure, with the checksum field replaced by zero for the
>        purpose of computing the checksum.  An all-zero value means that
>        no checksum was transmitted."
> 
> You should probably clarify the reason of this checksum, as there 
> already is a checksum field in ICMP messages.

I will add a cross reference to Section 5.2.

                                 Ron

> 
> Kindest regards,
> 
> --
> Fernando Gont
> e-mail: [email-masked] || [email-masked]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
> 
> 
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 26 Sep 2006 09:52:44 -0400
> From: Curtis Villamizar <[email-masked]>
> Subject: Re: [SAVA] Re: [Int-area] Call For Participation and
> 	Interest:SourceAddress Validation Architecture (SAVA) 
> To: Fred Baker <[email-masked]>
> Cc: [email-masked], [email-masked],	Jun Bi
> 	<[email-masked]>,	James Kempf <[email-masked]>,
> 	[email-masked]
> Message-ID:
> 	<[email-masked]>
> 
> 
> In message <[email-masked]>
> Fred Baker writes:
> 
>> 
>>On Sep 20, 2006, at 9:02 AM, James Kempf wrote:
>>
>>>Here's an idea (which, BTW, I'm not adovocating). ISPs agree that  
>>>if they detect spoofed packets from someone they cut off forwarding  
>>>to/from that AS until the problem is fixed. Really simple and  
>>>modestly straightforward to deploy, but not a technical solution.  
>>>It requires the RIRs and operator associations to issue a policy,  
>>>and the operators to agree to it.
>>
>> 
>>well, there's the rub.
>> 
>>If the source address is spoofed, it's pretty hard to say what AS the  
>>packet arrived from. If you can detect the spoofed packet on a link  
>>to a neighboring AS, you could cut off that AS, but you won't know  
>>whether that AS actually allowed it in or whether it has some other  
>>customer that allowed it in. You only know it got to you.
> 
> 
> 
> Back to the future.
> 
> The NSFNET used to collect src/dst network pairs on all outfacing core
> interfaces.  This was easier with classfull routing but doable with
> classless routing.  If the set of source addresses started to vary
> greatly there was a spoofing attack coming from that interface and the
> peer provider (or customer) was notified (with threats to shut down
> peering if no action was taken - the incentive).  Rarely making good
> on that threat, but ready to do so.  If it was a customer, they were
> simply shut down if they didn't respond right away which generally did
> not draw complaints from the customer (acknowledged to be their fault).
> 
> Spoofing attacks through the NSFNET could be traced back to the source
> if reported within 48 hours of the attack.  Most spoofed attacks could
> be detected automatically due to a noticable change in the set of
> source addresses in the collected data and then dealt with proactively
> (no customer complaint needed before taking action).  This even worked
> for intermittent senders intending to make it harder to trace.  This
> was in the pre-RPF days.
> 
> The NSFNET didn't block this traffic, just made it very traceable to
> the upstream.  RPF seems to have been a response to all the NOC
> overtime resulting from upstream providers without this data
> collection capability having a difficult time tracing the source
> further upstream.  This was also before widespread DDoS.
> 
> UUNET used to advocate and practice a similar approach, identifying
> the target of spoofed traffic and temporarily blackholing traffic to
> affected destination(s) from offending peers.  Again the peer was
> notified, but not as forcefully.
> 
> Data collection suitable for this use is still available on many core
> routers but apparenly it is rarely if ever collected.  The only
> incentive to doing something like this is that clued in customers want
> something done by their provider when they are experiencing an attack.
> Lack of response might mean loss of customer.
> 
> Initially there was good motivation for RPF.  What may have changed is
> that no one in a decade has taken the same hard line approach that
> NSFNET took in insisting that their peers trace each the problem
> further upstream and fix it or fix it more permanently with RPF.
> 
> Those who don't bother with RPF are those that don't have the large
> customers who are often the target of DDoS attacks.  Lack of RPF is
> tough for providers with these sort of customers if those without them
> don't bother to do RPF.  Its made worse if the problem can't easily be
> traced to the upstream though that may be for lack of applying an
> available solution.
> 
> Curtis
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Tue, 26 Sep 2006 10:03:47 -0400
> From: Curtis Villamizar <[email-masked]>
> Subject: Re: [SAVA] Re: [Int-area] Call For Participation and
> 	Interest:SourceAddress Validation Architecture (SAVA) 
> To: "James Kempf" <[email-masked]>
> Cc: [email-masked], [email-masked],	Jun Bi
> 	<[email-masked]>, [email-masked]
> Message-ID:
> 	<[email-masked]>
> 
> 
> In message <[email-masked]>
> "James Kempf" writes:
> 
>> 
>>Hmm, well sounds as if there may be a technical problem after
>>all. First, an intrusion detection problem: does this stream of
>>packets have forged source addresses? Then, a traceback problem: if so
>>where do these packets originate from?
> 
> 
> Solved problem.  Solution is not being applied by those affected.  Far
> from a zero cost solution.  Problem beat to death at IPMA meetings and
> discussed at least in IETF going way back.  Two flavors of raw data
> collection, netflow and 1-in-N packet sampling.  Most core routers
> today (afaik) are capable of doing one or both of these at line rate
> on 10 Gb/s interfaces (or concatenations of these).
> 
> 
>>Presuming these problems were solved, what would one do with the
>>information? Go to the offending ISP and ask: "Someone is forging
>>source addresses from your domain, can you please institute source
>>filtering to stop them?"
> 
> 
> Not a solved problem.  Back in NSFNET days it was a "we don't want to
> do this but if we do it is going to hurt you a lot more than it will
> hurt us" situation.  Not always so today and DDoS makes the job
> harder (multiple upstreams, potentially millions of sources).
> 
> 
>>            jak
> 
> 
> Curtis
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Tue, 26 Sep 2006 10:21:37 -0400
> From: Curtis Villamizar <[email-masked]>
> Subject: Re: [SAVA] Re: [Int-area] Call For Participation and
> 	Interest:SourceAddress Validation Architecture (SAVA) 
> To: Fred Baker <[email-masked]>
> Cc: [email-masked], [email-masked],	Jun Bi
> 	<[email-masked]>,	James Kempf <[email-masked]>,
> 	[email-masked]
> Message-ID:
> 	<[email-masked]>
> 
> 
> In message <[email-masked]>
> Fred Baker writes:
> 
>> 
>>On Sep 21, 2006, at 2:09 PM, James Kempf wrote:
>>
>>>Hmm, well sounds as if there may be a technical problem after all.  
>>>First, an intrusion detection problem: does this stream of packets  
>>>have forged source addresses? Then, a traceback problem: if so  
>>>where do these packets originate from?
>>
>> 
>>And the news in this statement is what, precisely?
>> 
>>Yes, people put bogus source addresses into packets. Barry indicates  
>>that it is far less common than it once was, but someone else (name  
>>escapes me and I'm too lazy to go find the email) that some attacks  
>>depend on them doing so.
> 
> 
> 
> An example of such an attack is resource related attacks such as TCP
> SYN attacks to web servers.  Immunity to this type of attack is much
> better than it used to be but not perfect.  Following with a SYN-ACK
> has a 1 in 65K chance of creating an established connection.  There is
> also the more dangerous TCP hijacking problem with sessions that are
> authenticated but carry no payload validation (or encryption).  The
> latter is nothing IPSEC, kerberos, or ssh couldn't solve if available.
> 
> Unpopular organization such as Microsoft, SCO, or the governemt of
> China might find themselves targets of resource attacks but since
> these attacks are now far less effective (and rather pointless) they
> are far less common.  In the past AOL and Yahoo have been targets.  I
> think whitehouse.gov was a target at one point (even when Al was
> there).  Probably thousands more have been targets of small scale
> attacks.  Some were even personal vendetas.
> 
> Curtis
> 
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Tue, 26 Sep 2006 10:36:21 -0400
> From: Curtis Villamizar <[email-masked]>
> Subject: Re: [SAVA] Re: [Int-area] Call For Participation and
> 	Interest:	SourceAddress Validation Architecture (SAVA) 
> To: Per Heldal <[email-masked]>
> Cc: [email-masked], [email-masked],
> 	[email-masked]
> Message-ID:
> 	<[email-masked]>
> 
> 
> In message <[email-masked]>
> Per Heldal writes:
> 
>> 
>> 
>>2. A significant software supplier (e.g. OS vendor) including spoofing
>>probes in their SW. [...]
> 
> 
> 
> Is this going to happen before or after said OS vendor fixes the many
> security flaws in its OS.  How about back versions including now
> unsupported versions which still have significant installed base.
> 
> Also how much will the upgrade cost and will it run on the old PC with
> 16MB of RAM that grandma turns on to pick up email once a week.
> 
> You've certainly hit on the source of the problem here and there is a
> straightforward solution but not one that the end user seems willing
> to use (erase disk, install Linux or *BSD).  Not something grandma
> will want to try.
> 
> I often wonder what the effect would be of fining the end user if
> their machine was used in an attack, even if through no fault of their
> own other than using security flawed software and what market
> reprocussions that might have on the source of this flawed software.
> 
> Tough medicine to swallow but it may be what the patient needs.  Some
> side effects.
> 
> Curtis
> 
> ps - grandma has about as much clue as many "IT professionals".
> 
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Tue, 26 Sep 2006 15:53:28 +0200
> From: Eliot Lear <[email-masked]>
> Subject: Re: [SAVA] Re: [Int-area] Call For Participation	and
> 	Interest:SourceAddress Validation Architecture (SAVA)
> To: [email-masked]
> Cc: Jun Bi <[email-masked]>, [email-masked],	James
> 	Kempf <[email-masked]>, [email-masked],
> 	[email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=UTF-8
> 
> Curtis Villamizar wrote:
> 
>>>[What would one do with information about an attacking ISPs]
>>
>>  
> 
> 
>>Not a solved problem.  Back in NSFNET days it was a "we don't want to
>>do this but if we do it is going to hurt you a lot more than it will
>>hurt us" situation.  Not always so today and DDoS makes the job
>>harder (multiple upstreams, potentially millions of sources).
>>  
> 
> 
> Indeed.  For example (by close analogy): 
> http://infosecon.net/workshop/pdf/emailblocking.pdf
> 
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Tue, 26 Sep 2006 11:04:19 -0400
> From: Curtis Villamizar <[email-masked]>
> Subject: Re: [SAVA] Re: [Int-area] Call For Participation and
> 	Interest:SourceAddress Validation Architecture (SAVA) 
> To: [email-masked]
> Cc: [email-masked], [email-masked],
> 	[email-masked]
> Message-ID:
> 	<[email-masked]>
> 
> 
> In message <[email-masked]>
> Mark Williams writes:
> 
>> 
>>1. Does the forum consider spoofed source addressing to be a problem?
>> 
>>2. If Yes, does the forum consider it to be a problem that the IETF 
>>should address?
> 
> 
> 
> IMHO what we are hearing is:
> 
> 1.  Yes.  Technically solved.
> 
> 2.  No.  Already technically solved.
> 
> btw- Tracing backscatter source was also used in finding source of
> "spray attacks" such as virus propogation to random addresses.  Some
> providers use the opposite - detection of non-routable source
> addresses as a simple way to identify spoofed attacks and its source.
> 
> Enabling RPF by default may be a good idea.  There are three cases.
> 
>   1.  Clueless or clueful provider with no assymetric routing.  No
>       problem.  RPF gets left on (on purpose or not).
> 
>   2.  Clueless provider with assymetric routing.  This change becomes
>       a "clue hammer".  It hurts but only on a one time router
>       software upgrade.  The provider is forced to think about which
>       routers may be carrying assymetric routing.  Some may turn it
>       off everywhere.  (Vendor can say IETF made me do it and the
>       provider should have read the big warning on page one of the
>       release notes).
> 
>   3.  Clueful provider with assymetric routing.  No problem - RFP
>       cannot be applied and gets disabled hopefully only where it
>       might be a problem and not everywhere.
> 
> The tradeoff is the gain realized by 1 (and maybe 3) vs the disruption
> caused by 2.  I think it was Bill Manning or Randy Bush who first said
> (paraphrased from memory from circa 1992 or 1993):
> 
>   The Internet is growing exponentially but the amount of clue is only
>   growing linearly at best; theefore the "clue density" is decreasing
>   exponentially.
> 
> That may be the underlying reason RPF is not enabled by default.
> 
> Curtis
> 
> 
> 
> ------------------------------
> 
> Message: 8
> Date: Tue, 26 Sep 2006 13:17:45 -0400
> From: Curtis Villamizar <[email-masked]>
> Subject: Re: [SAVA] Re: [Int-area] Call For Participation and
> 	Interest:SourceAddress Validation Architecture (SAVA) 
> To: Eliot Lear <[email-masked]>
> Cc: [email-masked], [email-masked],	Jun Bi
> 	<[email-masked]>, [email-masked],	James Kempf
> 	<[email-masked]>, [email-masked]
> Message-ID:
> 	<[email-masked]>
> 
> 
> In message <[email-masked]>
> Eliot Lear writes:
> 
>> 
>>Curtis Villamizar wrote:
>>
>>>>[What would one do with information about an attacking ISPs]
>>>
>>>  
>>
>> 
>>
>>>Not a solved problem.  Back in NSFNET days it was a "we don't want to
>>>do this but if we do it is going to hurt you a lot more than it will
>>>hurt us" situation.  Not always so today and DDoS makes the job
>>>harder (multiple upstreams, potentially millions of sources).
>>>  
>>
>> 
>>Indeed.  For example (by close analogy): 
>>http://infosecon.net/workshop/pdf/emailblocking.pdf
> 
> 
> 
> Spam blocking is blocking.  NSFNET used a threat of service
> termination but didn't need to follow through.  I do remember a
> regional network shutting down a university for 3 days due to lack of
> response to a complaint of being used to launch attacks.
> 
> Curtis
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/int-area
> 
> 
> End of Int-area Digest, Vol 16, Issue 21
> ****************************************
> 

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Fernando Gont <[email-masked]>
Date: Tue, 26 Sep 2006 18:59:04 -0300

>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?

>Good catch. 4 x 255 = 1020 < 1280. I will add one more bit to the v6

Good.

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

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

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

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

>I will replace "minimum MTU" with "minimum reassembly buffer size".

Good.

>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,

---

From: Carlos Pignataro <[email-masked]>
Date: Tue, 26 Sep 2006 22:27:25 -0400

Fernando, Ron,

Please find a couple of comments inline.

>> "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; 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.

>> one-byte length field is not enough).

Good point ! 204 octets short :)

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

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

> widely deployed. I would like to push back on this one.

"non-compliant" existing implementations are also version 2, and I agree
we should keep version 2 (for the same backwards compatibility reasons).
version++ from 1 to 2 happened in draft-ietf-mpls-icmp-00 -> 01.

Thanks,

--Carlos.

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 Sep 2006 02:40:29 -0300

At 23:27 26/09/2006, Carlos Pignataro wrote:

>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

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:
[....]
>allowing for the tcp checksum to pass).

Agreed. I think this clarification would be useful.

Agreed.

Kindest regards,

---

From: Carlos Pignataro <[email-masked]>
Date: Wed, 27 Sep 2006 10:24:47 -0400

Fernando,

Thanks for the quick feedback, please find some comments inline.

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

   The current memo also addresses backwards compatibility with existing
   ICMP implementations that either do not implement the extensions
   defined herein or implement them without adding the required length
   attributes.  In particular, this draft addresses backwards
   compatibility with certain, widely deployed, MPLS-aware ICMPv4
   implementations that send the extensions defined herein without
   adding the required length attribute.

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

>> compliant extensions, to expand the "no apps have been identified".

I just wanted to ack that this would indeed be IMHO a very strange case,
> If IP options are in place, you only need one layer of IP-in-IP

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

> Kindest regards,

Thanks again for the comments !

--Carlos.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 Sep 2006 17:00:04 -0300

>    length attribute as well as an extension structure that is appended

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

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

[....]
>I just wanted to ack that this would indeed be IMHO a very strange case,

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.

>+ 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

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,

---

From: Carlos Pignataro <[email-masked]>
Date: Wed, 27 Sep 2006 20:36:44 -0400

Fernando,

> This type of stuff should be present in the introduction (if not in 

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.

> 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
   process the 129th octet of the "original datagram" field will be
   adversely effected.  To date, no such applications have been
   identified.

Like I said though, adding a couple of additional sentences, pointer to
icmp-attacks Appendix C, and how to prevent using "compliant extensions"
might not hurt at all, and could certainly improve the document.

> But I think the draft should include a discussion on this.

I see your point, see above.

Many thanks for the thorough review and comments.

--Carlos.