Re: NDP DoS attack
* Jared Mauch: Solving a local attack is something I consider different in scope than the current draft being discussed in 6man, v6ops, ipv6@ etc... That's not going to happen because it's a layering violation between the IETF and IEEE. It has not been solved during thirty years of IPv4 over Ethernet. Why would be IPv6 be different? In practice, the IPv4 vs IPv6 difference is that some vendors provide DHCP snooping, private VLANs and unicast flood protection in IPv4 land, which seems to provide a scalable way to build Ethernet networks with address validation---but there is nothing comparable for IPv6 right now, from any vendor. _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
Re: OT: Given what you know now, if you were 21 again...
* Larry Stites: Given what you know now, if you were 21 and just starting into networking / communications industry which areas of study or specialty would you prioritize? Law. _ 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 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
On Jul 17, 2011, at 4:15 PM, Florian Weimer wrote: In practice, the IPv4 vs IPv6 difference is that some vendors provide DHCP snooping, private VLANs and unicast flood protection in IPv4 land, which seems to provide a scalable way to build Ethernet networks with address validation---but there is nothing comparable for IPv6 right now, from any vendor. It seems to me that IPv4 feature parity in terms of layer-2 security features should be prominently featured in upcoming RFPs. --- 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
On Sun, 17 Jul 2011, Florian Weimer wrote: In practice, the IPv4 vs IPv6 difference is that some vendors provide DHCP snooping, private VLANs and unicast flood protection in IPv4 land, which seems to provide a scalable way to build Ethernet networks with address validation---but there is nothing comparable for IPv6 right now, from any vendor. That is not true. Check out work and reports from the IETF SAVI WG. There are actually quite a few implementations out there, being used in production. -- Mikael Abrahamssonemail: swm...@swm.pp.se _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
Re: NDP DoS attack
* Mikael Abrahamsson: On Sun, 17 Jul 2011, Florian Weimer wrote: In practice, the IPv4 vs IPv6 difference is that some vendors provide DHCP snooping, private VLANs and unicast flood protection in IPv4 land, which seems to provide a scalable way to build Ethernet networks with address validation---but there is nothing comparable for IPv6 right now, from any vendor. That is not true. Check out work and reports from the IETF SAVI WG. There are actually quite a few implementations out there, being used in production. Others use tunnels, PPPoE or lots of scripting, so certainly something can be done about it. To my knowledge, SAVI SEND is still at a similar stage. Pointers to vendor documentation would be appreciated if this is not the case. And SAVI SEND is not the full story---it's still missing unicast flood protection. _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
Re: NDP DoS attack
On Sun, 17 Jul 2011, Florian Weimer wrote: Others use tunnels, PPPoE or lots of scripting, so certainly something can be done about it. To my knowledge, SAVI SEND is still at a similar stage. Pointers to vendor documentation would be appreciated if this is not the case. www.ietf.org/proceedings/79/slides/savi-6.pdf -- Mikael Abrahamssonemail: swm...@swm.pp.se _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
Re: NDP DoS attack
* Mikael Abrahamsson: On Sun, 17 Jul 2011, Florian Weimer wrote: Others use tunnels, PPPoE or lots of scripting, so certainly something can be done about it. To my knowledge, SAVI SEND is still at a similar stage. Pointers to vendor documentation would be appreciated if this is not the case. www.ietf.org/proceedings/79/slides/savi-6.pdf Interesting, thnaks. It's not the vendors I would expect, and it's not based on SEND (which is not surprising at all and actually a good thing). Is this actually secure in the sense that it ties addresses to specific ports for both sending and receiving? I'm asking because folks have built similar systems for IPv4 which weren't. The CLI screenshots look good, better than what most folks achieve with IPv4. _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
Re: NDP DoS attack
On Sun, 17 Jul 2011, Florian Weimer wrote: Interesting, thnaks. It's not the vendors I would expect, and it's not based on SEND (which is not surprising at all and actually a good thing). Personally I think SEND is never going to get any traction. Is this actually secure in the sense that it ties addresses to specific ports for both sending and receiving? I'm asking because folks have built similar systems for IPv4 which weren't. The CLI screenshots look good, better than what most folks achieve with IPv4. As far as I know, it's designed to work securely in an ETTH scenario, which implies both sending and receiving (if I understood you correctly). -- Mikael Abrahamssonemail: swm...@swm.pp.se _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
Re: NDP DoS attack
* Mikael Abrahamsson: On Sun, 17 Jul 2011, Florian Weimer wrote: Interesting, thnaks. It's not the vendors I would expect, and it's not based on SEND (which is not surprising at all and actually a good thing). Personally I think SEND is never going to get any traction. Last time, I was told that SEND was the way to go, despite not actually fixing anything. This mess is even worse than SCTP. Is this actually secure in the sense that it ties addresses to specific ports for both sending and receiving? I'm asking because folks have built similar systems for IPv4 which weren't. The CLI screenshots look good, better than what most folks achieve with IPv4. As far as I know, it's designed to work securely in an ETTH scenario, which implies both sending and receiving (if I understood you correctly). And it would also plug the NDP DOS vector because you've got a small set of addresses you need to process. Let's hope this gets buy-in from more vendors (and across the whole switch product lines, please), with full interoperability. _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
[no subject]
_ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)
We all make mistakes in not questioning our own positions, from time to time. You, Jeff, seem to be making that very same mistake. Please keep these points in mind: * Rome wasn't built in a day. The current system didn't come ready-made pre-built with all the bells and whistles you are used to. It grew slowly over time, as we learned what works, what doesn't, and what was missing. Any system that attempts to deal with locator/id separation will assuredly not be built in a day, either. * While you have stated a problem relating to a security consideration – specifically that there is a potential reflection attack that could cause cache thrashing, the solution may not be what you expect. * Yes, you were asked. Even so... Novelty isn't something worth arguing over, except in patent battles. Usefulness is only worth arguing over marginally more. Deployment (or lack thereof) speaks for itself. LISP or ILNP or what-have-you either will or won't be deployed over the long run. * Never is a very long time. Many uses of never have been used relating to the Internet. It is the corollary to Imminent Death of the 'Net: film @ 11. I still have the NANOG tee-shirt with Robert Metcalfe, someone with considerably more notoriety, eating his hat. Eliot _ 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: Anybody can participate in the IETF (Was: Why is IPv6 broken?)
On Sun, Jul 17, 2011 at 11:07 AM, Eliot Lear l...@cisco.com wrote: We all make mistakes in not questioning our own positions, from time to time. You, Jeff, seem to be making that very same mistake. Rome wasn't built in a day. The current system didn't come ready-made pre-built with all the bells and whistles you are used to. It grew slowly over time, as we learned what works, what doesn't, and what was missing. Any system that attempts to deal with locator/id separation will assuredly not be built in a day, either. LISP work has been going on for a long time to still not have any useful discussion on a designed-in, trivial DoS which will affect any ITR and make the work being done to allow ETRs to validate source addresses (or even do loose uRPF) into a DoS vector for ETRs as well. While you have stated a problem relating to a security consideration – specifically that there is a potential reflection attack that could cause cache thrashing, the solution may not be what you expect. I agree, a solution might be available. One has not been presented yet. In my earliest postings to the IETF LISP list, the ones which received zero replies, I suggest a way to significantly improve the cache churn DoS problem. It is not novel, as Darrel Lewis informed me, which means that even already-available research has not been applied to LISP in this area, and the Mapping Service protocol ties the hands of implementors so they *cannot* apply such techniques while still conforming to the specifications. Yes, you were asked. Even so... Novelty isn't something worth arguing over, except in patent battles. Really? Novelty, by definition, advances the state of the art. You may not think it's very important to inform people that LISP is based on essentially the same flow-caching scheme used in the 1990s, but I do. Never is a very long time. Many uses of never have been used relating to the Internet. It is the corollary to Imminent Death of the 'Net: film @ 11. I still have the NANOG tee-shirt with Robert Metcalfe, someone with considerably more notoriety, eating his hat. And yet, I am quite comfortable with the statement that LISP can never scale up to meet the demands of the Internet. Perhaps with fundamental changes to its design, and its advocates giving up some of their current assumptions, some progress could be made. In its current form, though, LISP will never be a useful tool to scale the Internet, and in fact, it cannot meet the demands of today's Internet. Unless, of course, you pretend that the ability to DoS any router with a trivial amount of traffic is not worthy of concern. -- 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
NetFlix Down
There appears to be a login issue at Netflix. Calls to their 1-866-579-7113 number only yields a recording that they are experiencing a higher than normal call volume, try again later. Widespread? Robert D. Scott rob...@ufl.edu Senior Network Engineer 352-273-0113 Phone CNS - Network Services 352-392-2061 CNS Phone Tree University of Florida352-273-0743 FAX Florida Lambda Rail 352-294-3571 FLR NOC Gainesville, FL 32611 321-663-0421 Cell 3216630...@messaging.sprintpcs.com _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
Re: NetFlix Down
I am unable to login as well. 2011/7/17 Scott, Robert D. rob...@ufl.edu There appears to be a login issue at Netflix. Calls to their 1-866-579-7113 number only yields a recording that they are experiencing a higher than normal call volume, try again later. Widespread? Robert D. Scott rob...@ufl.edu Senior Network Engineer 352-273-0113 Phone CNS - Network Services 352-392-2061 CNS Phone Tree University of Florida352-273-0743 FAX Florida Lambda Rail 352-294-3571 FLR NOC Gainesville, FL 32611 321-663-0421 Cell 3216630...@messaging.sprintpcs.com _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
Re: NetFlix Down
Ipad app says Service Temporarily Unavailable at the moment. Netflix claims to be operating about 90% of their services out of aws and the only issue on the aws status page is a vpn end point issue from yesterday. -Original Message- From: Scott, Robert D. rob...@ufl.edu Date: Sun, 17 Jul 2011 22:36:56 To: NANOG ‎[nanog@nanog.org]‎nanog@nanog.org Subject: NetFlix Down There appears to be a login issue at Netflix. Calls to their 1-866-579-7113 number only yields a recording that they are experiencing a higher than normal call volume, try again later. Widespread? Robert D. Scott rob...@ufl.edu Senior Network Engineer 352-273-0113 Phone CNS - Network Services 352-392-2061 CNS Phone Tree University of Florida352-273-0743 FAX Florida Lambda Rail 352-294-3571 FLR NOC Gainesville, FL 32611 321-663-0421 Cell 3216630...@messaging.sprintpcs.com _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
Re: NetFlix Down
Unreachable from eastern Canada as well 2011/7/17 kristopher.do...@gmail.com: Ipad app says Service Temporarily Unavailable at the moment. Netflix claims to be operating about 90% of their services out of aws and the only issue on the aws status page is a vpn end point issue from yesterday. -Original Message- From: Scott, Robert D. rob...@ufl.edu Date: Sun, 17 Jul 2011 22:36:56 To: NANOG ‎[nanog@nanog.org]‎nanog@nanog.org Subject: NetFlix Down There appears to be a login issue at Netflix. Calls to their 1-866-579-7113 number only yields a recording that they are experiencing a higher than normal call volume, try again later. Widespread? Robert D. Scott rob...@ufl.edu Senior Network Engineer 352-273-0113 Phone CNS - Network Services 352-392-2061 CNS Phone Tree University of Florida 352-273-0743 FAX Florida Lambda Rail 352-294-3571 FLR NOC Gainesville, FL 32611 321-663-0421 Cell 3216630...@messaging.sprintpcs.com _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
Re: NetFlix Down
On 7/17/2011 12:36 PM, Scott, Robert D. wrote: There appears to be a login issue at Netflix. Calls to their 1-866-579-7113 number only yields a recording that they are experiencing a higher than normal call volume, try again later. Widespread? Likewise from Hawaii. Guess this'll be another thing added to Chaos Monkey: http://www.codinghorror.com/blog/2011/04/working-with-the-chaos-monkey.html _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
Re: NetFlix Down
On 7/17/2011 6:36 PM, Scott, Robert D. wrote: There appears to be a login issue at Netflix. Streaming works here. Andrew _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
RE: best practices for management nets in IPv6
We our designing a new hosted exchange environment as well as Multi-Tenant Desktop as a Service environment and we are going to use IPv6 public address. Cheers Ryan -Original Message- From: James Harr [mailto:james.h...@gmail.com] Sent: Wednesday, July 13, 2011 11:22 AM To: Joel Maslak Cc: nanog@nanog.org Subject: Re: best practices for management nets in IPv6 I couldn't agree more. If you set up private address space, it's going to come back and make more work for you later. Set up public IPv6 addresses. If you need stateful connection filtering, put in a stateful firewall. If you really really need address obfuscation, you can still do NAT, but NAT from public addresses to public a public address or pool of public addresses. If you ever need to turn off NAT, it's a lot easier than renumbering hundreds of machines and you always have the option of disabling it per-host instead of doing an all-or-nothing transition. On Tue, Jul 12, 2011 at 7:32 PM, Joel Maslak jmas...@antelope.net wrote: Public IPs. At some point you will have to manage something outside your current world or your organization will need to merge/partner/outsource/contract/etc with someone else's network and they might not be keen to route to your ULA space (and might not be more trustworthy than the internet at large anyhow). Think about things like VPN endpoints, video devices, telephones, etc, that may end up on a public network, maybe behind a device you manage. You may just manage routers today, but who knows about tomorrow. Put behind a firewall and use good ingress filtering throughout your network, separating trust zones with distinct subnets. If you are worried about forgetting to enable a firewall, put in a network management system to verify connectivity stays blocked combined with a monitored IDS. -- ^[:wq^M _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
