Re: Hijacked Network Ranges
On Monday, February 06, 2012 03:06:24 PM Christopher Morrow wrote: do you have customers with 10k long prefix lists? it gets hard when the lists get long, or the data is for downstream folks of your customer. Good that someone's checking though, I'd love to see this part automated. No, we don't have customers with 10,000-long prefix lists, but we have planned to implement automation (either using the IRR Toolset or home-grown solutions) to make this possible as a means to scaling, should that time arise. As it is now, throwing NOC staff at the problem for the volumes we have works well enough. But this is, by no means, a panacea as we scale up. Heck, one must even worry whether a some router configurations can take that many lines. But there are other ways around that. RPKI doesn't necessarily mean that the router knows anything about certificates in the short-term. I think there's a time when 'the resource certification system' (which is really, today, the rpki) holds cert/roa data that you could use to filter what the IRR tells you for a customer. You could even do this in any automated manner! Well, given validation information will be available within a network, one may use it in non-obvious ways to implement policy. The time between the previous and next paragraphs though is when all isp's will need to beat the drums with their customers saying: Hey, you REALLY need to get that shit into the 'resource certification system' (rpki), NOW. (because shortly we'll stop accepting your invalid routes... and then the interwebs won't be able to find you, and we'll all be sad.) Well, we have all seen how doing this with DNSSEC, IPv6 and 4-byte ASN's worked out. We need to understand that different operators and different customers will have varying reasons as to why they can't yet do the right thing. There is abundant evidence of this with other similar initiatives. Adoption will have to be incremental. During that time, the Internet must not break. sure... it's not working so well though :( Not for lack of having some kind of solution. What we have today may not be the best, most scalable option, but it is one nonetheless. Automating it (like what RPSL does) is how you can make it scale to some extent, but it's still the same solution. We can't just sit around waiting for RPKI. There will be some reason why some of us can't deploy it, while someone else is thinking up its successor. Rinse, repeat. Mark. signature.asc Description: This is a digitally signed message part.
Re: Hijacked Network Ranges
That and rely on external telemetry (argus and friends..) On Mon, Feb 6, 2012 at 1:29 PM, Mark Tinka mti...@globaltransit.net wrote: Well, given validation information will be available within a network, one may use it in non-obvious ways to implement policy. -- Suresh Ramasubramanian (ops.li...@gmail.com)
Re: Hijacked Network Ranges
With regards to RPKI, I'd like to point out what is possible now, and what the maturity is of the implementations. All RIRs have a system up an running. As John Curran pointed out in an earlier message, ARIN will have a production system up this year, but right now you can already gain experience with their testbed: https://www.arin.net/resources/rpki.html If you create your ROAs there, there are actually quite some parties who will already validate this information. Of course, basing an actual routing decision on this is a second step; for that we'll need more and better quality data. As it stands there are about 1400 IPv4 and 300 IPv6 announcements that have a ROA associated with them. There are some public test beds up that will give a valid route a higher pref, and an invalid one a lower pref. So create a ROA for your announcements, and then watch it show up on actual RPKI-capable Cisco and Juniper routers: EuroTransit have made their instance of the RIPE NCC RPKI Validator public, so you can easily verify the validity of your announcement here by searching for it: http://rpki01.fra2.de.euro-transit.net:8080/bgp-preview Then you can log in on a public Juniper here: 193.34.50.25, 193.34.50.26 telnet username: rpki password: testbed Try commands such as: - show validation session detail - show validation statistics - show validation database - show route protocol bgp 204.127.128.0/17 - show route protocol bgp validation-state valid You can also log into a public Cisco here: rpki-rtr.ripe.net telnet username: ripe no password Try commands such as: - sh ip bgp rpki table - sh ip bgp rpki server - sh ip bgp 93.175.146.0/24 - sh ip bgp ipv6 unicast rpki table - sh ip bgp ipv6 unicast 2001:630::/32 Both routers are configured along these lines: https://www.ripe.net/certification/router-configuration and talk to the RIPE NCC RPKI Validator service available here: https://www.ripe.net/certification/tools-and-resources Try it out, and give feedback! Cheers, Alex P.S. RFCs 6480-6493 have been published. A big thank you goes out to all the people who made that possible. On 6 Feb 2012, at 08:59, Mark Tinka wrote: On Monday, February 06, 2012 03:06:24 PM Christopher Morrow wrote: do you have customers with 10k long prefix lists? it gets hard when the lists get long, or the data is for downstream folks of your customer. Good that someone's checking though, I'd love to see this part automated. No, we don't have customers with 10,000-long prefix lists, but we have planned to implement automation (either using the IRR Toolset or home-grown solutions) to make this possible as a means to scaling, should that time arise. As it is now, throwing NOC staff at the problem for the volumes we have works well enough. But this is, by no means, a panacea as we scale up. Heck, one must even worry whether a some router configurations can take that many lines. But there are other ways around that. RPKI doesn't necessarily mean that the router knows anything about certificates in the short-term. I think there's a time when 'the resource certification system' (which is really, today, the rpki) holds cert/roa data that you could use to filter what the IRR tells you for a customer. You could even do this in any automated manner! Well, given validation information will be available within a network, one may use it in non-obvious ways to implement policy. The time between the previous and next paragraphs though is when all isp's will need to beat the drums with their customers saying: Hey, you REALLY need to get that shit into the 'resource certification system' (rpki), NOW. (because shortly we'll stop accepting your invalid routes... and then the interwebs won't be able to find you, and we'll all be sad.) Well, we have all seen how doing this with DNSSEC, IPv6 and 4-byte ASN's worked out. We need to understand that different operators and different customers will have varying reasons as to why they can't yet do the right thing. There is abundant evidence of this with other similar initiatives. Adoption will have to be incremental. During that time, the Internet must not break. sure... it's not working so well though :( Not for lack of having some kind of solution. What we have today may not be the best, most scalable option, but it is one nonetheless. Automating it (like what RPSL does) is how you can make it scale to some extent, but it's still the same solution. We can't just sit around waiting for RPKI. There will be some reason why some of us can't deploy it, while someone else is thinking up its successor. Rinse, repeat. Mark.
Re: Optimal IPv6 router
With IPv6 growing, if we were to design a native IPv6 router, with IPv4 functionality thrown in, then is it possible to design a more optimal IPv6 router, than what exists today? OK, I'll bite. What would qualify as a native IPv6 router? Is this another concept as silly as hardware vs software based routers? Join them and create a router where IPv6 is ASIC-forwarded and IPv4 gets to use a CPU. Market perspectives for such a product are very shy, but would fit the description. Rubens
Re: ISP access in Hebron, KY
Level 3 might be available. I'm pretty sure TWTC is though -- they're one of the bigger players in Dayton. David. On Sun, Feb 5, 2012 at 3:21 PM, Eric Gauthier e...@roxanne.org wrote: Hello, We're looking for DIA in the 20 - 50mbps range for a warehouse we have in Hebron, KY. CinBell has been a bit slow to respond to our DS3 requets, so I'm wondering who else in town has their own facilities (also wondering who might be a good for a backup circuit)? Thanks! Eric :)
Re: Hijacked Network Ranges
On Monday, February 06, 2012 06:47:23 PM Alex Band wrote: With regards to RPKI, I'd like to point out what is possible now, and what the maturity is of the implementations. All RIRs have a system up an running. As John Curran pointed out in an earlier message, ARIN will have a production system up this year, but right now you can already gain experience with their testbed: https://www.arin.net/resources/rpki.html This is great, Alex! Thanks. Mark. signature.asc Description: This is a digitally signed message part.
Re: UDP port 80 DDoS attack
The point is well taken that cloud scrubbing can be an essential component of mitigating a volumetric flood. However, it is important to note that DDOS attacks do not only consist of volumetric floods. Current attacks often incorporate a multi-vectored attack campaign including a combination of low and slow and application layer attacks on upper layer protocols, ie. DNS HTTP(s). These campaigns are designed to fly under the triggers of other flow based analysis (cloud scrubbing) protections in place today. As with any security protection a layered approach is required in order to protect the perimeter from DDOS. In addition to the previous recommendations of ACL, uRPF, RTBH, CoPP, inspection of the full stack is required.The best protection today includes a detector capable of inspecting the full stack and signaling back to the cloud scrubbing station to swing the route if the attack becomes volumetric. The premise device should have technique in order to challenge the source and counter the attack with intelligence.I'm aware of two vendors offering some of these capabilities today, Radware and Arbor. -- From: Keegan Holley keegan.hol...@sungard.com Sent: Sunday, February 05, 2012 8:37 PM To: Dobbins, Roland rdobb...@arbor.net Cc: NANOG Group nanog@nanog.org Subject: Re: UDP port 80 DDoS attack 2012/2/5 Dobbins, Roland rdobb...@arbor.net On Feb 6, 2012, at 8:10 AM, Keegan Holley wrote: An entire power point just to recommend ACL's, uRPF, CPP, DHCP snooping, and RTBH? Actually, no, that isn't the focus of the preso. The first four will not work against a DDOS attack This is incorrect - suggest you read the preso. The ACL's are configured on the routers belonging to the victim AS which will not save their access pipe if it's overrun unless I'm missing something. uRPF may help with spoofed traffic, but sometimes causes problems with multi-homing and is often more harmful than helpful depending on the network design. and the last one just kills the patient so he does not infect other patients. S/RTBH - as opposed to D/RTBH - doesn't kill the patient. Again, suggest you read the preso. Source RTBH often falls victim to rapidly changing or spoofed source IPs. It also isn't as widely supported as it should be. I never said DDOS was hopeless, there just aren't a wealth of defenses against it.
RE: Optimal IPv6 router
With IPv6 growing, if we were to design a native IPv6 router, with IPv4 functionality thrown in, then is it possible to design a more optimal IPv6 router, than what exists today? OK, I'll bite. What would qualify as a native IPv6 router? Is this another concept as silly as hardware vs software based routers? Join them and create a router where IPv6 is ASIC-forwarded and IPv4 gets to use a CPU. Market perspectives for such a product are very shy, but would fit the description. And where half the useful features just don't support IPv6. Make it support draft-ietf-mpls-ldp-ipv6 and we're away :) -- Leigh Porter __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __
Re: Optimal IPv6 router
In a message written on Mon, Feb 06, 2012 at 08:34:26AM +0100, Daniel Roesen wrote: itself is completely AFI-agnostic - see e.g. IOS/IOS-XE [can't comment on XR]). IOS-XR is fully AFI-agnostic, as far as I can tell. It also updated the CLI to be consistently ipv4 ... or ipv6 ... with similar syntax. I think also that all of the platforms on which IOS-XR runs (GSR, CRS-1/3, ASR9000) can all run full line rate IPv6 in hardware, with features. While much of the IOS-XR vrs JunOS is personal preference, IOS-XR has one very cool feature. You can pass parameters in route policy. Many networks maintain slightly different versions of policies like peer-in/peer-out due to various load balancing or preference needs, with a 5-15 stanza policy repeated over and over. When you have to update one of the stanzas in all policies it becomes a big mess. In IOS-XR, you can write a generic policy and then call with with parameters: route-policy generic-out($routeCommunity) ... ! Do all the common things if community matches-any $routeCommunity then accept endif drop end-policy community-set send-to-private-peers 1234:5678 end-set route-policy private-peer-out apply generic-out(send-to-private-peers) end-policy community-set send-to-public-peers 1234:4321 end-set route-policy public-peer-out apply generic-out(send-to-public-peers) end-policy With a little bit of careful thought you can really collapse down the policy to be much shorter, easier to understand, and have almost no cut-and-paste in it, which should reduce errors when updating in the future. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpCM08UgJpzt.pgp Description: PGP signature
Re: Optimal IPv6 router
On Mon, Feb 6, 2012 at 1:04 PM, Daniel Roesen d...@cluenet.de wrote: On Sun, Feb 05, 2012 at 09:07:57PM -0500, valdis.kletni...@vt.edu wrote: OK, I'll bite. What would qualify as a native IPv6 router? Perhaps those which were designed with IPv4+IPv6 in mind from day 1, both in hardware and software - like Juniper/JUNOS. In contrast to other Not just that. I had meant that the HW is optimized for IPv6 and also as a side effect does IPv4. This router could be designed assuming that you'll have more IPv6 traffic to forward than IPv4. the gear where IPv6 was always an aftermath, which shows in both hardware (limits of performance, functionality and scaling) as well as software (every feature gets implemented twice, even if the feature itself is completely AFI-agnostic - see e.g. IOS/IOS-XE [can't comment on XR]). Yes, thats what i had in mind. One example that comes to my mind is that a few existing routers cant do line rate routing for IPv6 traffic as long as the netmask is 65. Also routers have a limited TCAM size for storing routes with masks 64. These routers were primarily designed for IPv4 and also support IPv6. I was wondering what we could optimize on if we only design an IPv6 router (assume an extreme case where it does not even support IPv4). Glen Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Re: Optimal IPv6 router
On 2/6/12 06:48 , Glen Kent wrote: One example that comes to my mind is that a few existing routers cant do line rate routing for IPv6 traffic as long as the netmask is 65. I'm sorry that's bs. It's trivial to partition a cam in order to do /128s in a single lookup. that's actually the worst case scenario, a more efficient packing will result in lower power consumption and memory use. potentially that results in multiple lookups which in no way implies you're not going to meet your pps target. Also routers have a limited TCAM size for storing routes with masks 64. These routers were primarily designed for IPv4 and also support IPv6. All routers don't use tcams for fib lookups. M T MX devices do not use cams for fib for example. limited cam partitioning schemes exist in ip4 as well, big cams have a cost power wise, and bom wise, parititioning them in a way that meets the developers view of the distribution of route lengths can be beneficial and be used to build products suitable for lots of roles but probably not being a internet core router. standard juniper ex8200 line cards for example are just peachy for a datacenter but not so much for a internet core device and the bom feature set and price reflect that. I was wondering what we could optimize on if we only design an IPv6 router (assume an extreme case where it does not even support IPv4). right now if I take a platform that uses a large CAM like a force 10 e1200i ej line card, I can adjust the cam allocation to do basically nothing but ipv6, given the default balance between ipv4 and ipv6 doing so more that doubles the number of ipv6 routes I can expect to hold. Glen Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Re: Hijacked Network Ranges
--- mti...@globaltransit.net wrote: From: Mark Tinka mti...@globaltransit.net A big fail to our community, for up to this day, not implementing basic routing and forwarding filters that would do away with all this cruft in the first place. Clearly the Youtube/Pakistan/PCCW incident has long been forgotten. --- I know of folks in charge of BGP enabled networks (with downstream BGP customers as well) that have never heard of the Youtube/Pakistan/PCCW incident and don't care if they put extra routes in the table and I doubt that is an isolated situation. Further, I doubt it will change unless they're forced to care by technology somehow. An unfortunate situation for sure... scott
2012.02.06 NANOG54 monday morning session notes are up
I posted my notes from this morning's session at http://kestrel3.netflight.com/2012.02.06-nanog54-morning-session.txt in case people find them to be useful. Thanks! Matt
Switch and router
Hello There is big congestion between router and switch I read some documents about flowcontral Do I disable or adjust flowcontral at the same? Can flowcontral solve the congestion issue? How can I adjust flowcontral in cisco router and HP switch? Thank you so much
Re: Switch and router
Hi Forget flow control, because you will use buffer and at the someone will not understant pause frame. Another issue is : with pause frame you block all the traffic from the outbound port ... So very dangerous. Best way : big pipe. Regards Fabien Envoyé de mon iPad Le 6 févr. 2012 à 22:41, Ann Kwok annkwo...@gmail.com a écrit : Hello There is big congestion between router and switch I read some documents about flowcontral Do I disable or adjust flowcontral at the same? Can flowcontral solve the congestion issue? How can I adjust flowcontral in cisco router and HP switch? Thank you so much
Re: 2012.02.06 NANOG54 monday morning session notes are up
Matthew Petach (mpetach) writes: I posted my notes from this morning's session at http://kestrel3.netflight.com/2012.02.06-nanog54-morning-session.txt in case people find them to be useful. For those of us not attenting, this is invaluable. Thanks a lot for this work, Matt. Cheers, Phil
Any Covad / MegaPath folks around?
Hi, Looks like the Connect portal has been down for hours. Can someone from Covad / MegaPath ping me off-list? Thanks! Sincerely, Bobby Glover Director of Information Services South Valley Internet
2012.02.06 NANOG54 day1 afternoon session notes
My notes from the second half of today's NANOG 54 talks are now up at http://kestrel3.netflight.com/2012.02.06-nanog54-afternoon-session.txt for those catching up remotely before the videos get posted up. Off to the Beer and Gear now. ^_^ Thanks! Matt
Re: UDP port 80 DDoS attack
On Mon, Feb 6, 2012 at 8:43 PM, Sven Olaf Kamphuis s...@cb3rob.net wrote: there is a fix for it, it's called putting a fuckton of ram in -most- routers on the internet and keeping statistics for each destination ip:destination port:outgoing interface so that none of them individually can (entirely/procentually compared to other traffic) flood the outgoing interface on that router... end result, if enough routers are structured like that, is that ddos attacks will be come completely useless. There are two obvious problems with your approach. First, adding the policers you suggest, at the scale needed, is a little harder than you imagine. It's not a simple matter of the cost of RAM but also power/heat density per port. Second, if you re-engineer every router on the Internet to prevent an interface from being congested by malicious flow(s) destined for one particular destination IP:port, then DDoS attacks will simply target multiple ports or multiple destination IP addresses that are likely to traverse a link they are able to congest. If you want to dramatically increase the cost of routers in order to solve the problem of DDoS with one deft (and expensive) move, you have to imagine that the people behind DDoS attacks aren't complete idiots, and will actually spend some time thinking about how to defeat your system. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts
Re: Optimal IPv6 router
You can do the same with Junos (calling a 'generic' policy as a sub-routine). Sent from my iPhone On Feb 6, 2012, at 6:18, Leo Bicknell bickn...@ufp.org wrote: In a message written on Mon, Feb 06, 2012 at 08:34:26AM +0100, Daniel Roesen wrote: itself is completely AFI-agnostic - see e.g. IOS/IOS-XE [can't comment on XR]). IOS-XR is fully AFI-agnostic, as far as I can tell. It also updated the CLI to be consistently ipv4 ... or ipv6 ... with similar syntax. I think also that all of the platforms on which IOS-XR runs (GSR, CRS-1/3, ASR9000) can all run full line rate IPv6 in hardware, with features. While much of the IOS-XR vrs JunOS is personal preference, IOS-XR has one very cool feature. You can pass parameters in route policy. Many networks maintain slightly different versions of policies like peer-in/peer-out due to various load balancing or preference needs, with a 5-15 stanza policy repeated over and over. When you have to update one of the stanzas in all policies it becomes a big mess. In IOS-XR, you can write a generic policy and then call with with parameters: route-policy generic-out($routeCommunity) ... ! Do all the common things if community matches-any $routeCommunity then accept endif drop end-policy community-set send-to-private-peers 1234:5678 end-set route-policy private-peer-out apply generic-out(send-to-private-peers) end-policy community-set send-to-public-peers 1234:4321 end-set route-policy public-peer-out apply generic-out(send-to-public-peers) end-policy With a little bit of careful thought you can really collapse down the policy to be much shorter, easier to understand, and have almost no cut-and-paste in it, which should reduce errors when updating in the future. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
Re: UDP port 80 DDoS attack
2012/2/6 Jeff Wheeler j...@inconcepts.biz On Mon, Feb 6, 2012 at 8:43 PM, Sven Olaf Kamphuis s...@cb3rob.net wrote: there is a fix for it, it's called putting a fuckton of ram in -most- routers on the internet and keeping statistics for each destination ip:destination port:outgoing interface so that none of them individually can (entirely/procentually compared to other traffic) flood the outgoing interface on that router... end result, if enough routers are structured like that, is that ddos attacks will be come completely useless. There are two obvious problems with your approach. First, adding the policers you suggest, at the scale needed, is a little harder than you imagine. It's not a simple matter of the cost of RAM but also power/heat density per port. Since when are policers implemented in ram? You're talking FPGA if you want to be able to make forwarding/filtering decisions assuming it's possible which it isn't you're 1 million dollar boxes suddenly become hundred million dollar boxes. Then there's v6 info.. Second, if you re-engineer every router on the Internet to prevent an interface from being congested by malicious flow(s) destined for one particular destination IP:port, then DDoS attacks will simply target multiple ports or multiple destination IP addresses that are likely to traverse a link they are able to congest. Not to mention that the routers themselves become an attack vector. This cache will have a finite limit because there's no such thing as an infinite amount of cache among other flaws. When that limit is reached it will do something no one want's it to do and that will become the new DDOS attack. If you want to dramatically increase the cost of routers in order to solve the problem of DDoS with one deft (and expensive) move, you have to imagine that the people behind DDoS attacks aren't complete idiots, and will actually spend some time thinking about how to defeat your system. Not to mention cost? You're not going to get a tier I ISP to upgrade to this new super router (assuming it's possible to build such a things) without an act of congress or at least the FCC. They won't even spend enough on fiber to bring broadband into rural areas.
Re: Optimal IPv6 router
On Mon, Feb 06, 2012 at 08:23:20PM -0800, Rafael Rodriguez wrote: You can do the same with Junos (calling a 'generic' policy as a sub-routine). You cannot pass parameters. Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
DOS ATTACK ON BGP , LPTS ??
Hi , What is the best way to mitigate DOS attack against the bgp process of a router , is LPTS on IOS-XR enough ? Rgds Peter
Re: DOS ATTACK ON BGP , LPTS ??
On Feb 7, 2012, at 1:37 PM, Peter Ehiwe wrote: What is the best way to mitigate DOS attack against the bgp process of a router , iACLs and CoPP: https://files.me.com/roland.dobbins/prguob --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com The basis of optimism is sheer terror. -- Oscar Wilde
