Re: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))
On Jul 15, 2011, at 10:24 AM, Jimmy Hess wrote: In most cases if you have a DoS attack coming from the same Layer-2 network that a router is attached to, it would mean there was already a serious security incident that occured to give the attacker that special point to attack fr This scenario is quite common in physical/virtual co-lo IDCs, FYI - customer A attacking customer B, both within the same subnet, in many cases. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com The basis of optimism is sheer terror. -- Oscar Wilde _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
Re: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))
On Mon, Jul 11, 2011 at 8:17 PM, Karl Auer ka...@biplane.com.au wrote: RFC3756 IPv6 Neighbor Discovery (ND) Trust Models and Threats In this attack, the attacking node begins fabricating addresses with the subnet prefix and continuously sending packets to them. The last hop router is obligated to resolve these addresses by sending neighbor solicitation packets. A legitimate host attempting to enter the network may not be able to obtain Neighbor Discovery service from the last hop router as it will be already busy with sending other solicitations. Hi Karl, My off-the-cuff naive solution to this problem would be to discard the oldest incomplete solicitation to fit the new one and, upon receiving an apparently unsolicited response to a discarded solicitation, restart the process flagging that particular query non-discardable. That would be an implementation change, not a protocol change. I would expect to occasionally lose a packet due to the discard while the router was under attack with the accordingly minimal impact. I would also expect to see a multicast flood on the LAN of about the same data rate as the inbound attack packets. Where does this naive approach break down? On Fri, Jul 15, 2011 at 12:13 AM, Fernando Gont ferna...@gont.com.ar wrote: On 07/15/2011 12:24 AM, Jimmy Hess wrote: A similarly hazardous situation exists with IPv4, and it is basically unheard of for IPv4's Layer 2/ARP security weaknesses to be exploited to create a DoS condition, even though they can be (very easily), IMO, the situation is different, in that the typical IPv4 subnet size eliminate some of the attack vectors. Hi Fernando, Not at a practical level. The reason it's unheard of for IPv4 is that if you're a hacker with an ability to generate arbitrary packets on a LAN, DOSing the adjacent router by overwhelming its ARP cache is one of the least interesting things you can do... and one of the easiest to get busted at. It isn't necessary (or possible) to solve every conceivable *local* DOS attack. And frankly remote saturation-bomb attacks are out of bounds too. The concern Karl presented was that it was possible to remotely disable an IPv6 LAN with tailored traffic much less than that network's inbound capacity. Solve that issue with IPv6 ND and we're done. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004 _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
Re: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))
On Sun, Jul 17, 2011 at 11:42 AM, William Herrin b...@herrin.us wrote: My off-the-cuff naive solution to this problem would be to discard the oldest incomplete solicitation to fit the new one and, upon receiving an apparently unsolicited response to a discarded solicitation, restart the process flagging that particular query non-discardable. Do you mean to write, flagging that ND entry non-discardable? Once the ND entry is in place, it should not be purged for quite some time (configurable is a plus), on the order of minutes or hours. Making them permanent would, however, cause the ND table to eventually become full when foolish things like frequent source address changes for privacy are in use, many clients are churning in and out of the LAN, etc. Where does this naive approach break down? It breaks down because the control-plane can't handle the relatively small number of punts which must be generated in order to send ND solicits, and without the ability to install incomplete entries into the data-plane, those punts cannot be policed without, by design, discarding some good punts along with the bad punts resulting from DoS traffic. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
Re: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))
On Jul 17, 2011, at 10:35 AM, Jeff Wheeler wrote: On Sun, Jul 17, 2011 at 11:42 AM, William Herrin b...@herrin.us wrote: My off-the-cuff naive solution to this problem would be to discard the oldest incomplete solicitation to fit the new one and, upon receiving an apparently unsolicited response to a discarded solicitation, restart the process flagging that particular query non-discardable. Do you mean to write, flagging that ND entry non-discardable? Once the ND entry is in place, it should not be purged for quite some time (configurable is a plus), on the order of minutes or hours. Making them permanent would, however, cause the ND table to eventually become full when foolish things like frequent source address changes for privacy are in use, many clients are churning in and out of the LAN, etc. I believe it was obvious in the context he means flagging the incomplete ND entry as one that is not to be discarded early for pruning of potentially DOS-related ND entries. Basically an ND entry would have the following states and timers: Flagbits: I Incomplete (1 = ND entry is not complete) D Discardable (1 = Incomplete entry is result of incoming packet for unverified neighbor) Timers: A Age -- Counts up from time ND entry was created (most likely synthetic and calculated by storing T in the ND entry and using Tnow - Tentry). The system would have a two timer policies: 1 for Incomplete Timeout and 1 for Complete Timeout. (TI and TC) At A=TI, an incomplete entry would be discarded regardless of the D flag. At A=TC, a complete entry would be discarded regardless of the D flag. When a packet arrives for a host which does not exist in the ND table, a new entry with flags I and D would be created. An ND request would be generated as normal. When a new ND table entry is required and the table is full, the oldest entry with both I and D flags (max(A)) would be replaced with the new entry. When an ND response is received matching an entry with the I flag set, the I and D flags would be cleared and the entry would be filled in with the appropriate data. When an ND response is received not matching an entry with the I flag set, a new entry with the I flag and no D flag would be created. In this way, you cannot overflow the neighbor table in a way that creates significant disruption unless there are actually too many neighbors, in which case, it's bad network design and not DOS. Where does this naive approach break down? It breaks down because the control-plane can't handle the relatively small number of punts which must be generated in order to send ND solicits, and without the ability to install incomplete entries into the data-plane, those punts cannot be policed without, by design, discarding some good punts along with the bad punts resulting from DoS traffic. I think most of this punting could be handled at the line card level. Is there any reason that the ND process can't be moved into line-card level silicon as described above? Sure, that doesn't solve the problem on current hardware, but, it moves it from design problem to implementation issue, which IMHO is a step in the right direction. Owen _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
Re: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))
On Sun, Jul 17, 2011 at 3:40 PM, Owen DeLong o...@delong.com wrote: Basically an ND entry would have the following states and timers: I've discussed what you have described with some colleagues in the past. The idea has merit and I would certainly not complain if vendors included it (as a knob) on their boxes. The downfalls of this approach are that they still don't ensure the discovery of new neighbors (rather than ever seen neighbors) during DoS, and you make the local DoS a bit more complex by needing to establish more rules for purging these semi-permanent entries. I think most of this punting could be handled at the line card level. Is there any reason that the ND process can't be moved into line-card level silicon as described above? You could implement ND solicit in the data-plane (and remove punts entirely) in even some current chips, to say nothing of future ones. Whether or not that is a good idea, well, keep in mind that the ND solicits would then be mcasted to the LAN at a potentially unlimited rate. That is not necessarily a problem unless the L2 implementation is not too good with respect to multicast. For example, in some switches (mostly those that are routers that can switch) the L2 mcast has surprising caveats, such as using up a lot of fabric capacity for whatever replication scheme has been chosen. Of course, you also hope NDP on all the connected hosts works right. I believe some Juniper customers noticed a pretty big problem with JUNOS NDP implementation when deploying boxes using the DE-CIX addressing scheme, and in a situation like that, the ingress router for the attack could be crippled by spurious responses from the other mis-behaving hosts on the LAN, essentially like smurf except without sending any garbage back out to the Internet. What you definitely don't want to do is assume this fixes the local DoS, because it doesn't. I would like for you to keep in mind that a host on the LAN, misconfigured to do something like local proxy-arp, or otherwise responding to all ND solicits, would accidentally DoS the LAN's gateway. I do not think we should assume that the local DoS won't happen, or is fixable with a whack-a-mole method. Sure, that doesn't solve the problem on current hardware, but, it moves it from design problem to implementation issue, which IMHO is a step in the right direction. Well, it already is a design problem that implementations can largely work-around. Vendors just aren't doing it. :-/ -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
Re: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))
On Sun, Jul 17, 2011 at 1:35 PM, Jeff Wheeler j...@inconcepts.biz wrote: On Sun, Jul 17, 2011 at 11:42 AM, William Herrin b...@herrin.us wrote: My off-the-cuff naive solution to this problem would be to discard the oldest incomplete solicitation to fit the new one and, upon receiving an apparently unsolicited response to a discarded solicitation, restart the process flagging that particular query non-discardable. Do you mean to write, flagging that ND entry non-discardable? Hi Jeff, I meant flagging the new incomplete solicitation ineligible for previous sentence's early load-based discard. When you get a response to a solicitation you no longer remember making, solicit again and don't forget about it until the normal protocol timeouts this time. Where does this naive approach break down? It breaks down because the control-plane can't handle the relatively small number of punts which must be generated in order to send ND solicits, and without the ability to install incomplete entries into the data-plane, those punts cannot be policed without, by design, discarding some good punts along with the bad punts resulting from DoS traffic. Let me try to restate what you've said to make sure I understand. When the data plane knows what ARP or ND is underway, it can guard against overwhelming the control plane by discarding excessive traffic for the same yet-unresolved destination while allowing packets for new destinations on the lan through to the control plane. Without that knowledge, it can only have one queue causing the data plane to discard packets which would initiate neighbor discovery prior to the control plane seeing them, preventing any solicitation or implementing the logic I described. This doesn't sound particularly hard to me. Most CPE has the control and data planes on the same silicon. A guard at the data plane is pointless in the first place. Just punt the packet up and move on. On the bigger iron where the planes are on running on different chips, you can move the initial ND solicitation packet into the data plane. After failing to find an incomplete ND, generate and send the ND solicitation and THEN make the decision whether to punt to the control plane or discard. If you discard, the control plane will find out about the good ones when the response comes back. This means you could multiply a unicast flood into a multicast flood but you'll have to pump out several orders of magnitude more packets than with the original problem before it causes me grief. Still, you've sold me on part of the claim: A /64 is inherently vulnerable to a remote DOS attack that a /120 is not. Now sell me on the other part: How does this require effort on the attacker's part that's enough smaller than the general form flood his link attack that I should care about it beyond poking my vendors to see if they've reasonably covered the high-load corner cases? I see how the original attack could kill a lan with a relatively small number of packets. With the naive solution, it seems to require something a lot closer to a steady flood. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004 _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
Re: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))
On Jul 17, 2011, at 1:17 PM, Jeff Wheeler wrote: On Sun, Jul 17, 2011 at 3:40 PM, Owen DeLong o...@delong.com wrote: Basically an ND entry would have the following states and timers: I've discussed what you have described with some colleagues in the past. The idea has merit and I would certainly not complain if vendors included it (as a knob) on their boxes. The downfalls of this approach are that they still don't ensure the discovery of new neighbors (rather than ever seen neighbors) during DoS, and you make the local DoS a bit more complex by needing to establish more rules for purging these semi-permanent entries. Sure they do... Just not necessarily on the first attempt. There are no semi-permanent entries. In fact, it doesn't make any entry more permanent than today's state. The D flag just makes entries more readily discardable than today's entries. So you have some misconceptions about how it would work in practice, I think. Under DOS, the first packet that arrives for a known host generates the standard ND request sent to the host, but, the Incomplete ND table entry is created with the D flag set. If the host responds before the ND table entry is discarded, all functions as normal. If the entry is discarded before the host responds, then the response from the host creates a new incomplete entry without the D flag set. This entry will live for the normal time that an incomplete ND entry would be kept (not eligible for early discard) and the retry packet from the originating host would then generate a new ND request and the response should arrive before the normal incomplete ND timer expires. At that point a normal complete entry is created and things continue to function. So, what happens under this scenario is that you have a small chance that you need to wait for an initial connection retry on an unseen host, but, you can easily discard incomplete ND entries for which no response has yet been received. Further, since you're only discarding the oldest one entry each time you need to create a new entry in a full table, this would only start discarding things when an actual table overflow is occurring whether from DOS or other cause. If it's another cause, I don't think this makes life any worse. If it's DOS, then, it should be relatively rare that a responsive host is the oldest ND table entry that would get discarded, no? I think most of this punting could be handled at the line card level. Is there any reason that the ND process can't be moved into line-card level silicon as described above? You could implement ND solicit in the data-plane (and remove punts entirely) in even some current chips, to say nothing of future ones. Whether or not that is a good idea, well, keep in mind that the ND solicits would then be mcasted to the LAN at a potentially unlimited rate. There's no reason it would have to be an unlimited rate, but, I think that would probably be acceptable in most cases anyway. That is not necessarily a problem unless the L2 implementation is not too good with respect to multicast. For example, in some switches (mostly those that are routers that can switch) the L2 mcast has surprising caveats, such as using up a lot of fabric capacity for whatever replication scheme has been chosen. If your L2 implementation sucks on Mcast in IPv6, you're kind of in a bad way anyway. Of course, you also hope NDP on all the connected hosts works right. I believe some Juniper customers noticed a pretty big problem with JUNOS NDP implementation when deploying boxes using the DE-CIX addressing scheme, and in a situation like that, the ingress router for the attack could be crippled by spurious responses from the other mis-behaving hosts on the LAN, essentially like smurf except without sending any garbage back out to the Internet. I think the bad NDP implementations on the hosts will get sorted fairly quickly anyway. Since all a spurious hosts would do is create a new incomplete entry without the D flag set the FIRST time it sends an unsolicited ND response, I'm not sure how that would really cripple the ingress router. Care to explain that? What you definitely don't want to do is assume this fixes the local DoS, because it doesn't. I would like for you to keep in mind that a host on the LAN, misconfigured to do something like local proxy-arp, or otherwise responding to all ND solicits, would accidentally DoS the LAN's gateway. I do not think we should assume that the local DoS won't happen, or is fixable with a whack-a-mole method. I consider local DOS to be a corner case unique to universities and very poorly run colos. We've already had that discussion and IIRC agreed to disagree. Sure, that doesn't solve the problem on current hardware, but, it moves it from design problem to implementation issue, which IMHO is a step in the right direction. Well, it already is a design problem that implementations can largely work-around.
Re: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))
On Jul 17, 2011, at 1:32 PM, William Herrin wrote: On Sun, Jul 17, 2011 at 1:35 PM, Jeff Wheeler j...@inconcepts.biz wrote: On Sun, Jul 17, 2011 at 11:42 AM, William Herrin b...@herrin.us wrote: My off-the-cuff naive solution to this problem would be to discard the oldest incomplete solicitation to fit the new one and, upon receiving an apparently unsolicited response to a discarded solicitation, restart the process flagging that particular query non-discardable. Do you mean to write, flagging that ND entry non-discardable? Hi Jeff, I meant flagging the new incomplete solicitation ineligible for previous sentence's early load-based discard. When you get a response to a solicitation you no longer remember making, solicit again and don't forget about it until the normal protocol timeouts this time. If you're going to solicit again rather than wait for a new packet, what's the point of not just installing a complete entry? After all, if someone sends you a spurious response, they'll likely also be able to respond to the solicit, so, you don't really protect anything by sending the solicit. I figured you stick the ineligible incomplete entry in the table and wait for the retransmit of the original packet. Where does this naive approach break down? It breaks down because the control-plane can't handle the relatively small number of punts which must be generated in order to send ND solicits, and without the ability to install incomplete entries into the data-plane, those punts cannot be policed without, by design, discarding some good punts along with the bad punts resulting from DoS traffic. Let me try to restate what you've said to make sure I understand. When the data plane knows what ARP or ND is underway, it can guard against overwhelming the control plane by discarding excessive traffic for the same yet-unresolved destination while allowing packets for new destinations on the lan through to the control plane. Without that knowledge, it can only have one queue causing the data plane to discard packets which would initiate neighbor discovery prior to the control plane seeing them, preventing any solicitation or implementing the logic I described. This doesn't sound particularly hard to me. Most CPE has the control and data planes on the same silicon. A guard at the data plane is pointless in the first place. Just punt the packet up and move on. I think Jeff's focus here is on the kinds of core and TOR switches that are mostly used in datacenters, not so much the CPE end of the world. Still, you've sold me on part of the claim: A /64 is inherently vulnerable to a remote DOS attack that a /120 is not. More accurately, the larger your single subnet address space, the more vulnerable you are to table overflow attacks. A /120 is exactly as vulnerable as an IPv4 /24. A /96 is exactly as vulnerable as an IPv4 /0. With bigger address spaces come new challenges. In the real world, I think this is less of an issue because: a. While the attack surface is large, the benefits of carrying out such an attack are relatively small. b. It's a relatively easy attack to spot, identify, quench, and likely trace. Owen _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
Re: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))
On Jul 14, 2011, at 8:24 PM, Jimmy Hess wrote: On Thu, Jul 14, 2011 at 9:35 PM, Jared Mauch ja...@puck.nether.net wrote: On Jul 14, 2011, at 10:06 PM, Fernando Gont ferna...@gont.com.ar wrote: Anyone on a layer-2 network can do something interesting like flood all f's and kill the lan. Trying to keep the majority of thoughts here for layer-3 originated attacks, even if the target is a layer2 item. - Jared In most cases if you have a DoS attack coming from the same Layer-2 network that a router is attached to, it would mean there was already a serious security incident that occured to give the attacker that special point to attack from. That's one possibility. The other likely possibility is that you are a University. Owen
Re: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))
On Thu, 14 Jul 2011 23:13:03 PDT, Owen DeLong said: On Jul 14, 2011, at 8:24 PM, Jimmy Hess wrote: In most cases if you have a DoS attack coming from the same Layer-2 network that a router is attached to, it would mean there was already a serious security incident that occured to give the attacker that special point to attack from. That's one possibility. The other likely possibility is that you are a University. Nope. Unless you want to add or you are a cable provider, or you are a DSL provider, or you are a to that. (Hint - what percent of students launch DoS attacks that cut themselves off from the net? Compare to what percent of non-student machines out on cable and DSL are botted or pwned) Even if you're a university with resident students, if said students are on the same Layer-2 as anything you actually care about, you have a serious security incident. Student manages to DoS the router out of the dorm and strands 3 floors of dorm without internet is just as interesting as Joe Sixpack manages to DoS the router at the cable head end and strands 3 blocks of Comcast customers without internet, for the *exact same reasons*. If the student is able to play more level-2 games than Joe Sixpack can, you misdesigned your network. pgpiIx2FrZzn7.pgp Description: PGP signature
Re: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))
On Thu, Jul 14, 2011 at 9:47 PM, Owen DeLong o...@delong.com wrote: Very true. This is where Mr. Wheeler's arguments depart from reality. He's right in that the problem can't be truly fixed without some very complicated code added to lots of devices, but, it can be mitigated relatively easily and mitigation really is good enough for most real world purposes. ok,I'll bite, what's the solution?
Re: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))
On 07/11/2011 09:17 PM, Karl Auer wrote: I realise this is not specific implementations as you requested, but it seems to me that the problem is generic enough not to require that. The attack is made possible by the design of the protocol, not any failing of specific implementations. Specific implementations need to describe what they've done about it (mitigation or prevention). Vulnerability to this specific issues has a great deal to do with the implementation. After all, whenever there's a data structure that can potentially grow out of bounds (or hit a limit), it becomes a resource management issue. In this particular case, if the implementation enforces a limit on the number of entries in the INCOMPLETE state, then only nodes that have never communicated with the outside world could be affected by this attack. And if those entries that are in the INCOMPLETE state are pruned periodically (e.g. in a round-robin fashion), chances are that even those new hosts would be able to get into the neighbor cache and hence remain unaffected by this attack. Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))
On Thu, Jul 14, 2011 at 7:29 PM, Fernando Gont ferna...@gont.com.ar wrote: On 07/11/2011 09:17 PM, Karl Auer wrote: Vulnerability to this specific issues has a great deal to do with the implementation. After all, whenever there's a data structure that can Yes In this particular case, if the implementation enforces a limit on the number of entries in the INCOMPLETE state, then only nodes that have never communicated with the outside world could be affected by this attack. And if those entries that are in the INCOMPLETE state are pruned periodically (e.g. in a round-robin fashion), chances are that Not only that but it's possible to differentiate _how_ an entry is added to the table when the table reaches a high water mark it's possible to drop the packet that was attempting to cause a NDP discover, fail to add the INCOMPLETE entry to the table, but _still_ send the outgoing NDP neighbor solicitation, and complete the entry or whitelist the destination if the neighbor advertises itself. That is: if the destination is good, the neighbor will respond to the NDP solicit, even though the neighbor doesn't have an entry in the table. So a small number of packets are lost at initial setup, due to the attack, but further packets are unaffected, So long as the attack does not overwhelm router CPU, and so long as the INCOMPLETE entry high water mark is at a low enough level, so there is still ample space in the table. Even more sophisticated strategies may be available. It should be possible to mitigate this, so long as the attack does not actually originate from a neighbor on the same subnet as a router IP interface on an IPv6 subnet with sufficient number of IPs. even those new hosts would be able to get into the neighbor cache and hence remain unaffected by this attack. Thanks, -- -JH
Re: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))
On Jul 14, 2011, at 6:24 PM, Jimmy Hess wrote: On Thu, Jul 14, 2011 at 7:29 PM, Fernando Gont ferna...@gont.com.ar wrote: On 07/11/2011 09:17 PM, Karl Auer wrote: Vulnerability to this specific issues has a great deal to do with the implementation. After all, whenever there's a data structure that can Yes In this particular case, if the implementation enforces a limit on the number of entries in the INCOMPLETE state, then only nodes that have never communicated with the outside world could be affected by this attack. And if those entries that are in the INCOMPLETE state are pruned periodically (e.g. in a round-robin fashion), chances are that Not only that but it's possible to differentiate _how_ an entry is added to the table when the table reaches a high water mark it's possible to drop the packet that was attempting to cause a NDP discover, fail to add the INCOMPLETE entry to the table, but _still_ send the outgoing NDP neighbor solicitation, and complete the entry or whitelist the destination if the neighbor advertises itself. That is: if the destination is good, the neighbor will respond to the NDP solicit, even though the neighbor doesn't have an entry in the table. So a small number of packets are lost at initial setup, due to the attack, but further packets are unaffected, So long as the attack does not overwhelm router CPU, and so long as the INCOMPLETE entry high water mark is at a low enough level, so there is still ample space in the table. Even more sophisticated strategies may be available. It should be possible to mitigate this, so long as the attack does not actually originate from a neighbor on the same subnet as a router IP interface on an IPv6 subnet with sufficient number of IPs. even those new hosts would be able to get into the neighbor cache and hence remain unaffected by this attack. Thanks, -- -JH Very true. This is where Mr. Wheeler's arguments depart from reality. He's right in that the problem can't be truly fixed without some very complicated code added to lots of devices, but, it can be mitigated relatively easily and mitigation really is good enough for most real world purposes. Owen
Re: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))
On 07/14/2011 10:24 PM, Jimmy Hess wrote: In this particular case, if the implementation enforces a limit on the number of entries in the INCOMPLETE state, then only nodes that have never communicated with the outside world could be affected by this attack. And if those entries that are in the INCOMPLETE state are pruned periodically (e.g. in a round-robin fashion), chances are that Not only that but it's possible to differentiate _how_ an entry is added to the table when the table reaches a high water mark it's possible to drop the packet that was attempting to cause a NDP discover, fail to add the INCOMPLETE entry to the table, but _still_ send the outgoing NDP neighbor solicitation, and complete the entry or whitelist the destination if the neighbor advertises itself. Agreed. I should double-check whether there's room in the current specifications to do this -- however, whether the specs allow this or not is irrelevant. At the point you're being hit with a DoS, you better do something about it (particularly when it's possible, as in this case!) That is: if the destination is good, the neighbor will respond to the NDP solicit, even though the neighbor doesn't have an entry in the table. Modulo that when the high water mark has not been hit, the router should probably *not* create ND cache entries in response to this gratuitous ND advertisements, since otherwise it would open the door to a DoS from local attackers. It should be possible to mitigate this, so long as the attack does not actually originate from a neighbor on the same subnet as a router IP interface on an IPv6 subnet with sufficient number of IPs. Well, unless there's some layer-2 anti-spoofing mitigation in place, with /64 subnets the local attacker typically *will* have enough addresses. Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))
On Jul 14, 2011, at 10:06 PM, Fernando Gont ferna...@gont.com.ar wrote: It should be possible to mitigate this, so long as the attack does not actually originate from a neighbor on the same subnet as a router IP interface on an IPv6 subnet with sufficient number of IPs. Well, unless there's some layer-2 anti-spoofing mitigation in place, with /64 subnets the local attacker typically *will* have enough addresses. Solving a local attack is something I consider different in scope than the current draft being discussed in 6man, v6ops, ipv6@ etc... Anyone on a layer-2 network can do something interesting like flood all f's and kill the lan. Trying to keep the majority of thoughts here for layer-3 originated attacks, even if the target is a layer2 item. - Jared
Re: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))
On 07/14/2011 11:35 PM, Jared Mauch wrote: Well, unless there's some layer-2 anti-spoofing mitigation in place, with /64 subnets the local attacker typically *will* have enough addresses. Solving a local attack Well, I was talking about not *introducing* ;-) one. is something I consider different in scope than the current draft being discussed in 6man, v6ops, ipv6@ etc... Which I-D are you referring to? Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))
http://tools.ietf.org/html/draft-gashinsky-v6nd-enhance-00 Sent from my iThing On Jul 14, 2011, at 10:57 PM, Fernando Gont ferna...@gont.com.ar wrote: On 07/14/2011 11:35 PM, Jared Mauch wrote: Well, unless there's some layer-2 anti-spoofing mitigation in place, with /64 subnets the local attacker typically *will* have enough addresses. Solving a local attack Well, I was talking about not *introducing* ;-) one. is something I consider different in scope than the current draft being discussed in 6man, v6ops, ipv6@ etc... Which I-D are you referring to? Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))
On Thu, Jul 14, 2011 at 9:35 PM, Jared Mauch ja...@puck.nether.net wrote: On Jul 14, 2011, at 10:06 PM, Fernando Gont ferna...@gont.com.ar wrote: Anyone on a layer-2 network can do something interesting like flood all f's and kill the lan. Trying to keep the majority of thoughts here for layer-3 originated attacks, even if the target is a layer2 item. - Jared In most cases if you have a DoS attack coming from the same Layer-2 network that a router is attached to, it would mean there was already a serious security incident that occured to give the attacker that special point to attack from. A similarly hazardous situation exists with IPv4, and it is basically unheard of for IPv4's Layer 2/ARP security weaknesses to be exploited to create a DoS condition, even though they can be (very easily), IPv4 Layer 2 DoS conditions are often due to a malfunction or error than intended attack; more likely, IPv6 Layer 2 security weaknesses will be used to intercept traffic for snooping, or quietly subvert network policy. LAN DoS conditions are noticed quickly, and usually result in physical unplugging of the attacking (or malfunctioning) node. Methods can be designed to protect against spoofed NDP flooding on the LAN that do not require the router's involvement. For IPv4 switched networks there is a technology referred to as 'Dynamic ARP Inspection'. Untrusted IPv6 LAN environments will need to implement SEND or some form of 'Dynamic ND inspection' plus RA-guard. If it comes down to solving a remote DoS issue at the cost of creating a LAN DoS issue that comes down to 'hosts on the LAN having to spoof' I would say that's easily well worth it. -- -JH
Re: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))
On 07/15/2011 12:24 AM, Jimmy Hess wrote: A similarly hazardous situation exists with IPv4, and it is basically unheard of for IPv4's Layer 2/ARP security weaknesses to be exploited to create a DoS condition, even though they can be (very easily), IMO, the situation is different, in that the typical IPv4 subnet size eliminate some of the attack vectors. For example, it would be virtually impossible for an ARP cache to grow without bounds, and consume all kernel memory, because the typical IPv4 subnet size imposes a limit on the number of entries. That is *not* the case with v6. IPv4 Layer 2 DoS conditions are often due to a malfunction or error than intended attack; more likely, IPv6 Layer 2 security weaknesses will be used to intercept traffic for snooping, or quietly subvert network policy. LAN DoS conditions are noticed quickly, and usually result in physical unplugging of the attacking (or malfunctioning) node. Assuming the admin of the possibly-ipv6-enabled-by-default router is IPv6 aware, etc. Methods can be designed to protect against spoofed NDP flooding on the LAN that do not require the router's involvement. Which ones? For IPv4 switched networks there is a technology referred to as 'Dynamic ARP Inspection'. Untrusted IPv6 LAN environments will need to implement SEND or some form of 'Dynamic ND inspection' plus RA-guard. Good luck with deploying SEND. OTOH, forget about current implementations of RA-Guard: * http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-01.txt * http://tools.ietf.org/id/draft-gont-6man-nd-extension-headers-01.txt If it comes down to solving a remote DoS issue at the cost of creating a LAN DoS issue that comes down to 'hosts on the LAN having to spoof' I would say that's easily well worth it. You *can* fix the remote DoS issue, *without* introducing the locally-exploitable one. That's the point. Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))
On Mon, 2011-07-11 at 18:48 -0500, Jimmy Hess wrote: It would be useful to at least have the risk properly described, in terms of what kind of DoS condition could arise on specific implementations. RFC3756 IPv6 Neighbor Discovery (ND) Trust Models and Threats Section 4.3.2 In this attack, the attacking node begins fabricating addresses with the subnet prefix and continuously sending packets to them. The last hop router is obligated to resolve these addresses by sending neighbor solicitation packets. A legitimate host attempting to enter the network may not be able to obtain Neighbor Discovery service from the last hop router as it will be already busy with sending other solicitations. This DoS attack is different from the others in that the attacker may be off-link. The resource being attacked in this case is the conceptual neighbor cache, which will be filled with attempts to resolve IPv6 addresses having a valid prefix but invalid suffix. This is a DoS attack. The above RFC and RFC3971 (SEND) both have good descriptions of a BUNCH of possible attacks. RFC3971 is a bit dismissive IMHO of this particular attack. I realise this is not specific implementations as you requested, but it seems to me that the problem is generic enough not to require that. The attack is made possible by the design of the protocol, not any failing of specific implementations. Specific implementations need to describe what they've done about it (mitigation or prevention). Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 signature.asc Description: This is a digitally signed message part
