Re: overview on defending DDoS attack
On Dec 27, 2011, at 6:47 PM, Joe wrote: is there any overview on current technology or method dealing with DDoS attack ? https://files.me.com/roland.dobbins/prguob https://files.me.com/roland.dobbins/k4zw3x https://files.me.com/roland.dobbins/dweagy https://files.me.com/roland.dobbins/9i8xwl https://files.me.com/roland.dobbins/l53gjr https://files.me.com/roland.dobbins/679xji https://files.me.com/roland.dobbins/8c1cyp --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com The basis of optimism is sheer terror. -- Oscar Wilde
Re: IPv6 RA vs DHCPv6 - The chosen one?
On Tuesday, December 27, 2011 02:23:46 AM Mark Radabaugh wrote: Find me some decent consumer CPE and I would be more than happy to deploy IPv6. So far the choices I have found for consumer routers are pathetic.A fair number of them still have IPv4 issues. It's by no means exhaustive, but is a reasonable start: https://labs.ripe.net/Members/mirjam/ipv6-cpe-survey- updated-january-2011 https://labs.ripe.net/Members/mirjam/ipv6-cpe-surveys Cheers, Mark. signature.asc Description: This is a digitally signed message part.
overview on defending DDoS attack
hi,is there any overview on current technology or method dealing with DDoS attack ? thanks in advance Joe
Re: IPv6 RA vs DHCPv6 - The chosen one?
On Mon, 2011-12-26 at 13:23 -0500, Mark Radabaugh wrote: Find me some decent consumer CPE and I would be more than happy to deploy IPv6. So far the choices I have found for consumer routers are pathetic.A fair number of them still have IPv4 issues. You might find Adrian Kennard's blog to be of interest: http://revk.www.me.uk/2011/11/ipv6-for-consumers-on-dsl-at-last.html Pretty inexpensive, even here in rip-off Britain (~£32-35 inc. VAT @20%) to the point where a 'niche' ISP like AA[1] can actually give them away for free with new lines. Tom [1] http://aa.net.uk
Re: IPv6 RA vs DHCPv6 - The chosen one?
Hi, On 12/23/11 7:48 AM, Ray Soucy wrote: On Thu, Dec 22, 2011 at 3:04 PM, Tomas Podermanski tpo...@cis.vutbr.cz wrote: Well, then how many devices do you have in the network that uses IPv6? Good question, and I applaud you for wanting to verify that people talking about IPv6 have legitimate experience deploying it. I dug into the database I log all IPv6 traffic into. We have 8,509 active hosts using IPv6, that's in comparison to 35,229 on the IPv4 side, so about 24% (mind you, this is only the LAN networks we manage, we provide IPv6 transit to other entities as the regional RE network). At this point over 95% of IPv4 LAN networks have IPv6 available, wireless is still a challenge (which is a big part of the difference between the host numbers you see above). We participate in Google's trusted IPv6 program, so Google announces 's to us for nearly all their services, so a significant amount of bandwidth is actually over IPv6. I would say that Google does make up the majority of IPv6 traffic though; there isn't much else out there announcing 's yet. We have always taken the approach that IPv6 isn't ready to be deployed if you can't do so while maintaining the same standards you have for IPv4 in the areas of manageability, security, availability, and stability. And we literally spent a few years modifying internal systems (and implementing new ones) to support IPv6 before we started making it available. See http://reports.informationweek.com/abstract/19/2233/Network-Infrastructure/strategy-session-ipv6.html for the case I've been making the last few years, or listen to me (and others) talking a little about it on Cisco's Higher Education webcast series http://www.cisco.com/web/strategy/education/us_education/webcasts.html I've watched the webcast and I like it. It's very realistic approach and I especially agree with opinion that deploying IPv6 means going into many compromises. We have been faced with very similar (almost same) troubles that you have been talking about. Do you have implemented first hop security? What will you do when some user runs RA flood attack You can hear me talk a little about that in the Cisco webcast. Right now we maintain a PACL on our switches that filter RA or DHCPv6 server traffic originating from access ports. As you mentioned it doesn't protect against malicious attempts to disrupt services on the network (fragmented packets) but it does add a reasonable level of stability (e.g. prevent Windows ICS) to levels that are similar to IPv4. In addition, we have a process that monitors our routers for new RAs on the network, and alerts us to that (which would let us respond to a malicious RA that got past the PACL). We are doing things just in the same way. Using PACL where is it possible (almost nowhere) and rest of the network we are trying to monitor. In case when an invalid RA appears we tries to repair it. For that we use combination of scapy sripts and home made tools (we were not satisfied with ndpmon, rafixd, ...). My colleague had a talk at that topic that is available http://tv.funet.fi/medar/showRecordingInfo.do?id=/metadata/fi/csc/tapahtumat/2011/gn3/ipv6/Fakerouterdetectionpracticalexperience.xml, slides http://openwiki.uninett.no/_media/geantcampus:2011-gn3na3t4-ipv6-gregr.pdf . Having over 120 subnets monitoring is not the perfect solution. Requires installation of extra probes into each segment (so we do it only for some segments) and can't solve malicious attacks. But is better than nothing - for many subnets it is the only thing we can do. At least it minimizes impact of Microsoft's ICS behavior. We probably haven't see any malicious attack on that. It's quite difficult say it for sure, because is quite difficult to distinguish which RA's are originated on ICS or witch ones are other activity. But remains that monitoring of rogue RA shows to us sometimes a really weird traffic. I believe that is a matter of time when viruses/trojans will start using IPv6 features to perform DNS hijack as we were able to observe it in IPv4 (DNSChanger) a few years ago. Fortunately from a user perspective there is still quite easy solution how to guard against that attack in the IPv6 environment. I think we all know that solution :-) For neighbor table exhaustion, I've written a set of scripts that I can use in a lab environment to perform the attacks against the platforms we use, and test how they fair. There is a pretty wide range of results. Most of the larger platforms that are the ones we would be concerned about actually hit CPU limitations before neighbor table exhaustion is accomplished, mainly because the neighbor discovery process doesn't appear to be implemented in hardware. It doesn't take much to pull off the attack either; a handful of residential connections would do the trick. This isn't an IPv6 problem so much as a vendor implementation problem, though. Like most DoS and DDoS
Re: IPv6 RA vs DHCPv6 - The chosen one?
Much like with IPv4, we capture the DUID at the time of registration and store it in the database. We make use of a web-based registration system that allows users to register computers for network access with a valid ID (that piece is still in development, though). There is still work to be done on DHCPd for IPv6. Along with the DUID we need support for specifying and logging IAID (especially with fixed-address statements). My initial reaction to DUID was one of complete hatred at first, but like most things IPv6, having worked with it a while longer, it's actually quite useful. We just need tools and knowledge to catch up. So far the biggest problem was people creating system images poorly and not deleting DUID, leading to duplicates. Our systems people know better these days and it's a non-issue, though. On a side note, you can build a DHCPd config these days that uses the MAC address as an identifier, and if a DUID is based on that MAC using one of the two methods that do, then it will make the association. It's not ideal, but it is a quick fix to the we only have a list of MAC addresses problem. I've actually been working to start an open source (free software) group dedicated to the development of IPv6 infrastructure systems based on Linux. Hopefully this summer I'll be at a point where we have some useful technology to provide. You can either talk about the challenges of IPv6 deployment, or actively try to find solutions to them for everyone is the general idea. On Tue, Dec 27, 2011 at 4:23 PM, Tomas Podermanski tpo...@cis.vutbr.cz wrote: Hi, On 12/23/11 7:48 AM, Ray Soucy wrote: On Thu, Dec 22, 2011 at 3:04 PM, Tomas Podermanski tpo...@cis.vutbr.cz wrote: Well, then how many devices do you have in the network that uses IPv6? Good question, and I applaud you for wanting to verify that people talking about IPv6 have legitimate experience deploying it. I dug into the database I log all IPv6 traffic into. We have 8,509 active hosts using IPv6, that's in comparison to 35,229 on the IPv4 side, so about 24% (mind you, this is only the LAN networks we manage, we provide IPv6 transit to other entities as the regional RE network). At this point over 95% of IPv4 LAN networks have IPv6 available, wireless is still a challenge (which is a big part of the difference between the host numbers you see above). We participate in Google's trusted IPv6 program, so Google announces 's to us for nearly all their services, so a significant amount of bandwidth is actually over IPv6. I would say that Google does make up the majority of IPv6 traffic though; there isn't much else out there announcing 's yet. We have always taken the approach that IPv6 isn't ready to be deployed if you can't do so while maintaining the same standards you have for IPv4 in the areas of manageability, security, availability, and stability. And we literally spent a few years modifying internal systems (and implementing new ones) to support IPv6 before we started making it available. See http://reports.informationweek.com/abstract/19/2233/Network-Infrastructure/strategy-session-ipv6.html for the case I've been making the last few years, or listen to me (and others) talking a little about it on Cisco's Higher Education webcast series http://www.cisco.com/web/strategy/education/us_education/webcasts.html I've watched the webcast and I like it. It's very realistic approach and I especially agree with opinion that deploying IPv6 means going into many compromises. We have been faced with very similar (almost same) troubles that you have been talking about. Do you have implemented first hop security? What will you do when some user runs RA flood attack You can hear me talk a little about that in the Cisco webcast. Right now we maintain a PACL on our switches that filter RA or DHCPv6 server traffic originating from access ports. As you mentioned it doesn't protect against malicious attempts to disrupt services on the network (fragmented packets) but it does add a reasonable level of stability (e.g. prevent Windows ICS) to levels that are similar to IPv4. In addition, we have a process that monitors our routers for new RAs on the network, and alerts us to that (which would let us respond to a malicious RA that got past the PACL). We are doing things just in the same way. Using PACL where is it possible (almost nowhere) and rest of the network we are trying to monitor. In case when an invalid RA appears we tries to repair it. For that we use combination of scapy sripts and home made tools (we were not satisfied with ndpmon, rafixd, ...). My colleague had a talk at that topic that is available http://tv.funet.fi/medar/showRecordingInfo.do?id=/metadata/fi/csc/tapahtumat/2011/gn3/ipv6/Fakerouterdetectionpracticalexperience.xml, slides http://openwiki.uninett.no/_media/geantcampus:2011-gn3na3t4-ipv6-gregr.pdf . Having over 120 subnets monitoring is not the
Re: IPv6 RA vs DHCPv6 - The chosen one?
On Tue, 27 Dec 2011 22:23:48 +0100, Tomas Podermanski said: I agree with you. Deploying IPv6 is really not easy and not cheep as some IPv6 enthusiasts claims. It's probably as easy and as cheap as IPv4 is. You've just forgotten how expensive and painful it was to solve all the exact same problems on the IPv4 side when you built your IPv4 infrastructure all those years ago. Meanwhile, the IPv6 enthusasts have forgotten how hard it was to deploy their IPv6 infrastructure all those years ago. pgprZAY9KJK9B.pgp Description: PGP signature
Re: IPv6 RA vs DHCPv6 - The chosen one?
On 12/27/11 10:53 PM, Ray Soucy wrote: Much like with IPv4, we capture the DUID at the time of registration and store it in the database. We make use of a web-based registration system that allows users to register computers for network access with a valid ID (that piece is still in development, though). There is still work to be done on DHCPd for IPv6. Along with the DUID we need support for specifying and logging IAID (especially with fixed-address statements). My initial reaction to DUID was one of complete hatred at first, but like most things IPv6, having worked with it a while longer, it's actually quite useful. We just need tools and knowledge to catch up. So far the biggest problem was people creating system images poorly and not deleting DUID, leading to duplicates. Our systems people know better these days and it's a non-issue, though. On a side note, you can build a DHCPd config these days that uses the MAC address as an identifier, and if a DUID is based on that MAC using one of the two methods that do, then it will make the association. It's not ideal, but it is a quick fix to the we only have a list of MAC addresses problem. It was my initial idea to workaround DUID issue. But MAC address in DUID is not necessary the address of a communicating interface. It can be derived from wireless interface when a node is connected via an Ethernet adapter. So I had to leave that idea very soon. In addition, RFC refuses DUID to be treated in that way :-). There is an RFC 6221 that solves that problem, however I haven't seen any implementation yet. Tomas I've actually been working to start an open source (free software) group dedicated to the development of IPv6 infrastructure systems based on Linux. Hopefully this summer I'll be at a point where we have some useful technology to provide. You can either talk about the challenges of IPv6 deployment, or actively try to find solutions to them for everyone is the general idea. On Tue, Dec 27, 2011 at 4:23 PM, Tomas Podermanski tpo...@cis.vutbr.cz wrote: Hi, On 12/23/11 7:48 AM, Ray Soucy wrote: On Thu, Dec 22, 2011 at 3:04 PM, Tomas Podermanski tpo...@cis.vutbr.cz wrote: Well, then how many devices do you have in the network that uses IPv6? Good question, and I applaud you for wanting to verify that people talking about IPv6 have legitimate experience deploying it. I dug into the database I log all IPv6 traffic into. We have 8,509 active hosts using IPv6, that's in comparison to 35,229 on the IPv4 side, so about 24% (mind you, this is only the LAN networks we manage, we provide IPv6 transit to other entities as the regional RE network). At this point over 95% of IPv4 LAN networks have IPv6 available, wireless is still a challenge (which is a big part of the difference between the host numbers you see above). We participate in Google's trusted IPv6 program, so Google announces 's to us for nearly all their services, so a significant amount of bandwidth is actually over IPv6. I would say that Google does make up the majority of IPv6 traffic though; there isn't much else out there announcing 's yet. We have always taken the approach that IPv6 isn't ready to be deployed if you can't do so while maintaining the same standards you have for IPv4 in the areas of manageability, security, availability, and stability. And we literally spent a few years modifying internal systems (and implementing new ones) to support IPv6 before we started making it available. See http://reports.informationweek.com/abstract/19/2233/Network-Infrastructure/strategy-session-ipv6.html for the case I've been making the last few years, or listen to me (and others) talking a little about it on Cisco's Higher Education webcast series http://www.cisco.com/web/strategy/education/us_education/webcasts.html I've watched the webcast and I like it. It's very realistic approach and I especially agree with opinion that deploying IPv6 means going into many compromises. We have been faced with very similar (almost same) troubles that you have been talking about. Do you have implemented first hop security? What will you do when some user runs RA flood attack You can hear me talk a little about that in the Cisco webcast. Right now we maintain a PACL on our switches that filter RA or DHCPv6 server traffic originating from access ports. As you mentioned it doesn't protect against malicious attempts to disrupt services on the network (fragmented packets) but it does add a reasonable level of stability (e.g. prevent Windows ICS) to levels that are similar to IPv4. In addition, we have a process that monitors our routers for new RAs on the network, and alerts us to that (which would let us respond to a malicious RA that got past the PACL). We are doing things just in the same way. Using PACL where is it possible (almost nowhere) and rest of the network we are trying to monitor. In case when
Re: IPv6 RA vs DHCPv6 - The chosen one?
valdis.kletni...@vt.edu wrote: And, if RA is obsoleted, which is a point of discussion, there is no reason to keep so bloated ND only for address resolution. By who? Sources please. A few people on NANOG complaining about RA is pretty far from deprecation of RA. Especially when some of the biggest IPv6 networks out there are still using it pretty heavily. That's not a valid counter argument against people who found problems in certain environment. IPv6, as is, might work well under some environment assumed by IPng/IPv6 WG, a committee. The environment may be large. However, as the committee made so many wrong assumptions such as: All the link layers were similar to PPP, Ethernet or ATM ATM was not broadcast capable but multicast capable Network configuration was mostly stationary Multicast was reliable Scale of multicast was not large ICMP packet too big won't be filtered A site was single homed or, if not, all the global prefixes was working IPv6 does not work well in many environments. In this case, the following statement in RFC1883: If the minimum time for rebooting the node is known (often more than 6 seconds), is the wrong assumption which made RA annoying. Masataka Ohta
Re: subnet prefix length 64 breaks IPv6?
It seems ISIS and OSPFv3 use the link local next-hop in their route advertisements. We discussed that SLAAC doesnt work with prefixes 64 on the ethernet medium (which i believe is quite, if not most, prevalent). If thats the case then how are operators who assign netmasks 64 use ISIS and OSPF, since these protocols will use the link local address? I had assumed that nodes derive their link local address from the Route Advertisements. They derive their least significant 64 bytes from their MACs and the most significant 64 from the prefix announced in the RAs. Glen On Tue, Dec 27, 2011 at 6:25 AM, Glen Kent glen.k...@gmail.com wrote: Sven, also various bgp implementations will send the autoconfigure crap ip as the next-hop instead of the session ip, resulting in all kinds of crap in your route table (if not fixed with nasty hacks on your end ;) which doesn't exactly make it easy to figure out which one belongs to which peer all the more reason not to use that autoconfigure crap ;) As per RFC 2545 BGP announces a global address as the next-hop. Its only in one particular case that it advertises both global and link local addresses. So, i guess, BGP is not broken. Its only RIPng afaik that mandates using a link local address. Glen
Re: IPv6 RA vs DHCPv6 - The chosen one?
On Wed, 28 Dec 2011 07:49:21 +0900, Masataka Ohta said: valdis.kletni...@vt.edu wrote: Especially when some of the biggest IPv6 networks out there are still using it pretty heavily. That's not a valid counter argument against people who found problems in certain environment. IPv6, as is, might work well under some environment assumed by IPng/IPv6 WG, a committee. The environment may be large. IPv6 does not work well in many environments. Feel free to try to deprecate *everything* that doesn't work well in many environments. Heck, SMTP doesn't work well in many environments (it's done in cleartext unless you deploy STARTTLS, it's subject to spamming, etc etc) - but I don't see you leading a charge to deprecate SMTP. Probably because you actually use it, even though it's totally unsuitable for many environments. It's one thing to deprecate something that's obviously a complete failure or has reached historic status - but RA isn't either of those *yet*. In this case, the following statement in RFC1883: If the minimum time for rebooting the node is known (often more than 6 seconds), is the wrong assumption which made RA annoying. Oddly enough, a lot of us are running on networks where assuming this about end user gear is perfectly reasonable. We haven't seen many consumer-grade Windows, Macs, or Linux boxes that are able to reboot in much under 6 seconds. Yes, I know you can do it with careful tuning and throwing SSDs and other hardware at it - doesn't mean it's common. Most of the time, any gains made in boot speed are immediately wiped out with since it boots 10% faster, we can start 10% more stuff... pgpZpJreWOB2O.pgp Description: PGP signature
Re: subnet prefix length 64 breaks IPv6?
On Wed, 28 Dec 2011 04:58:19 +0530, Glen Kent said: I had assumed that nodes derive their link local address from the Route Advertisements. They derive their least significant 64 bytes from their MACs and the most significant 64 from the prefix announced in the RAs. No, on Ethernet-ish networks the link-local is derived from an 'fe80::' and the MAC. pgp0DE6pSdSLz.pgp Description: PGP signature
Re: subnet prefix length 64 breaks IPv6?
On Dec 27, 2011, at 4:28 PM, Glen Kent glen.k...@gmail.com wrote: I had assumed that nodes derive their link local address from the Route Advertisements. They derive their least significant 64 bytes from their MACs and the most significant 64 from the prefix announced in the RAs. No, link local addresses are not derived from RAs. Even a system not connected to a router will have a link local address on each ethernet (I couldn't tell you how link local works on PPP, ATM, etc, without looking it up - but it doesn't require /64 networks).
