Fernando, Ron, Please find a couple of comments inline.
On 9/26/2006 3:38 PM, Ron Bonica allegedly said the following: > 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. >> 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. > > 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 point ! 204 octets short :) >> > > 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. 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). > >> 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 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". >> > > 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. "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. > >> 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 PROTECTED] || [EMAIL PROTECTED] >> 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 PROTECTED]> >> Subject: Re: [SAVA] Re: [Int-area] Call For Participation and >> Interest:SourceAddress Validation Architecture (SAVA) >> To: Fred Baker <[EMAIL PROTECTED]> >> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], Jun Bi >> <[EMAIL PROTECTED]>, James Kempf <[EMAIL PROTECTED]>, >> [EMAIL PROTECTED] >> Message-ID: >> <[EMAIL PROTECTED]> >> >> >> In message <[EMAIL PROTECTED]> >> 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 PROTECTED]> >> Subject: Re: [SAVA] Re: [Int-area] Call For Participation and >> Interest:SourceAddress Validation Architecture (SAVA) >> To: "James Kempf" <[EMAIL PROTECTED]> >> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], Jun Bi >> <[EMAIL PROTECTED]>, [EMAIL PROTECTED] >> Message-ID: >> <[EMAIL PROTECTED]> >> >> >> In message <[EMAIL PROTECTED]> >> "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 PROTECTED]> >> Subject: Re: [SAVA] Re: [Int-area] Call For Participation and >> Interest:SourceAddress Validation Architecture (SAVA) >> To: Fred Baker <[EMAIL PROTECTED]> >> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], Jun Bi >> <[EMAIL PROTECTED]>, James Kempf <[EMAIL PROTECTED]>, >> [EMAIL PROTECTED] >> Message-ID: >> <[EMAIL PROTECTED]> >> >> >> In message <[EMAIL PROTECTED]> >> 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 PROTECTED]> >> Subject: Re: [SAVA] Re: [Int-area] Call For Participation and >> Interest: SourceAddress Validation Architecture (SAVA) >> To: Per Heldal <[EMAIL PROTECTED]> >> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], >> [EMAIL PROTECTED] >> Message-ID: >> <[EMAIL PROTECTED]> >> >> >> In message <[EMAIL PROTECTED]> >> 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 PROTECTED]> >> Subject: Re: [SAVA] Re: [Int-area] Call For Participation and >> Interest:SourceAddress Validation Architecture (SAVA) >> To: [EMAIL PROTECTED] >> Cc: Jun Bi <[EMAIL PROTECTED]>, [EMAIL PROTECTED], James >> Kempf <[EMAIL PROTECTED]>, [EMAIL PROTECTED], >> [EMAIL PROTECTED] >> Message-ID: <[EMAIL PROTECTED]> >> 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 PROTECTED]> >> Subject: Re: [SAVA] Re: [Int-area] Call For Participation and >> Interest:SourceAddress Validation Architecture (SAVA) >> To: [EMAIL PROTECTED] >> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], >> [EMAIL PROTECTED] >> Message-ID: >> <[EMAIL PROTECTED]> >> >> >> In message <[EMAIL PROTECTED]> >> 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 PROTECTED]> >> Subject: Re: [SAVA] Re: [Int-area] Call For Participation and >> Interest:SourceAddress Validation Architecture (SAVA) >> To: Eliot Lear <[EMAIL PROTECTED]> >> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], Jun Bi >> <[EMAIL PROTECTED]>, [EMAIL PROTECTED], James Kempf >> <[EMAIL PROTECTED]>, [EMAIL PROTECTED] >> Message-ID: >> <[EMAIL PROTECTED]> >> >> >> In message <[EMAIL PROTECTED]> >> 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 protected] >> https://www1.ietf.org/mailman/listinfo/int-area >> >> >> End of Int-area Digest, Vol 16, Issue 21 >> **************************************** >> > > _______________________________________________ > Int-area mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/int-area > -- --Carlos Pignataro. Escalation RTP - cisco Systems _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
