RE: Blackholes and IXs and Completing the Attack.
"Well then they wouldn't be peering with this route reflector " Well then, the utility is probably close to 0, isn't it? I doubt most of the sources of DDOS traffic, especially those without ingress source filtering, are going to peer with your route reflector. What's their economic incentive to expend the engineering time to do so? I sincerely doubt that any backbone provider will filter at a /32. That means they have to check EVERY PACKET AT FULL IP DEST against your AS advertised routes. Since most backbone routers build circuits at the /18 and above mask on MPLS, just to keep up with traffic, I sincerely doubt they are going to expend the CPU, and potentially RAM, never mind prefix table entries (you know, those things we're running out of) to have a full table of every host that every hoster says is being DDOSed. In this case, there's a clear economic cost, for no economic benefit (they do actually make money delivering that DDOS traffic). A better approach would be to move your DDOS target and all the rest of its co-subnet hosts into a different /24, update the DNS RRs, and cease advertising that /24. If you really want to be nice, they don't need to renumber, you just need to stop advertising the target subnet, change the DNS RR's and NAT at your borders, if you control DNS and IP. The added benefit of this is that you can swap them back when the DDOs is over, and they get to stay up while it's happening. All you need to do this is some spare, never to be allocated, IP space. Works with the existing infrastructure, doesn't require an "Internet God", and in general, is likely to be more effective in the real world. That whole "rough consensus and running code" ethos of the IETF thing, as opposed to the "Cathedral" mentality of the ITU (and ICANNt), which your approach would imply. You control which routes you advertise, after all. Plus, AT&T's legal beagles don't get to send you a dunning notice when their patent gets granted. > -Original Message- > From: Ben Butler [mailto:[EMAIL PROTECTED] > Sent: Saturday, February 02, 2008 2:42 PM > To: Tomas L. Byrnes; nanog@merit.edu > Subject: RE: Blackholes and IXs and Completing the Attack. > > "If you're trying to do it on a /32 basis, I doubt you'd > find too many border router operators interested in accepting > a route that small, but I may be wrong." > > Well then they wouldn't be peering with this route reflector > in the first place. > > -Original Message- > From: Tomas L. Byrnes [mailto:[EMAIL PROTECTED] > Sent: 02 February 2008 20:39 > To: Ben Butler; Paul Vixie; nanog@merit.edu > Subject: RE: Blackholes and IXs and Completing the Attack. > > You could achieve the exact same result simply by not > advertising the network to your peers, or by advertising a > bogus route (prefixing a known bogon AS for the addresses you > want null-routed). I realize you would have to > subnet/deaggregate your netblocks, and therefore could wind > up with a prefix-length issue for peers who won't accept > routes longer than a certain mask, in some cases, but if you > are already being DDOSed, this should represent SOME improvement. > > If you're trying to do it on a /32 basis, I doubt you'd find > too many border router operators interested in accepting a > route that small, but I may be wrong. > > The bigger issue with all these approaches is that they run > afoul of a patent applied for by AT&T: > > http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HI TOFF&p=1&u > =%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=P G01&s1=200 > 60031575&OS=20060031575&RS=20060031575 > > USPTO App Number 20060031575 > > > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf > > Of Ben Butler > > Sent: Saturday, February 02, 2008 12:17 PM > > To: Paul Vixie; nanog@merit.edu > > Subject: RE: Blackholes and IXs and Completing the Attack. > > > > > > Hi, > > > > I was not proposing he Null routing of the attack source in > the other > > ISPs network but the destination in my network being Null > routed as a > > destination from your network out. > > > > This has no danger to the other network as it is my network that is > > going to be my IP space that is blackholed in your network, and the > > space blackholed is going to be an address that is being knocked of > > the air anyway under DoS and we are trying to minimise collateral > > damage. I cant see where the risk to the large NSP is - given that > > the route reflector will only reflect /32s that > legitimately originate > > > (as a destination not a source) in the AS announcing them as please > > blackhole. > > > > For complete clarity: AS13005 announces 213.170.128.0/19 > and has its > > route object in RIPE as being announced by AS13005. > > My router at IX - BENIX say - announces 213.170.128.1/32 to > the router > > > reflector their, the announcement from my IX assigned address > > 21
Re: Blackholes and IXs and Completing the Attack.
I see your point, but I think maintaining the box for the control session would also require a decent amount of work. Presumably, since you must all adhere to some quasi-standard to communicate with the control peer, you could probably also agree on creating a standard BGP community (ie. 64666:666 & no-export) to use and just skip the middle man. Granted, I am kind of new as well, and I assume if the solution were that simple more people would be using it. On Feb 2, 2008 9:07 PM, Ben Butler <[EMAIL PROTECTED]> wrote: > Hi, > > Agreed, but when you have >100 peers that is still a fair bit of work. I > know technically how to do it and am doing this with transits but then there > are only seven of those. It is not a question of how or can, but should / > is it valuable / constructive? > > The starting point in the thought process having just done it for transits > was right ok, now how do we sensibly scale this to apply it at IXes without > everyone having to run round contacting everyone else and to see if there > was an easier way of doing things, hence the suggestion. Plus it keeps > things nice a separated, your IX peering sessions announce just the main > prefixes, the session to the "blackhole reflector" can be in a separate > peer-group and you only send the /32s to the reflector. You don't have to > worry about who uses which communities as each member that chooses to peer > with the reflector is able to apply an inbound routemaps of their own > choosing to any prefixes they receive from this reflector at each individual > IX. > > Given that an ISP has elected to Complete the attack on a host that is > being DoSed, for whatever reason, and they have chosen to send blackhole > announcements to transit the logical extension seems to be to automate the > sending of them to IXs to try to further cut down on traffic. This seems > like a easy way, internally you just community tag on the trigger box for > where you want the announcement to go, transit, internal, customers, IX > all,1 2 not 3 - whatever - and BGP sends it out. Easy, and a single system > to send out all updates when you choose to and easy to remove when you want > to take it out again. > > If you subscribe to completing the attack as a strategy, then the > suggestion seemed like an easy way of rolling it out to the next logical > point after transit. > > Kind Regards > > Ben > >
Re: Jeanette Symons (1962-2008) a commerical Internet Pioneer
hh no! info on where to send, e.g. brother george's current address etc, please? randy
Re: Blackholes and IXs and Completing the Attack.
On Feb 2, 2008 11:40 PM, Tomas L. Byrnes <[EMAIL PROTECTED]> wrote: > ATT has no reason to pull their application, what needs to happen is > that the publisher of the prior art contact the USPTO. > > If ATT willingly failed to note the prior art in their app, that may be > a problem, but it isn't their duty to report ALL prior art, just the > stuff they know about. > sweetness, hopefully Wayne or Verizon (they have lots of lawyers) or Juniper will ping USPTO... or not, I suppose I don't care directly anymore :) > IANAL, but I have filed some patents, and reviewed a bunch more. > > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Morrow > > Sent: Saturday, February 02, 2008 12:58 PM > > To: Tomas L. Byrnes > > Cc: Ben Butler; Paul Vixie; nanog@merit.edu > > Subject: Re: Blackholes and IXs and Completing the Attack. > > > > > On Feb 2, 2008 3:39 PM, Tomas L. Byrnes <[EMAIL PROTECTED]> wrote: > > > > > The bigger issue with all these approaches is that they run > > afoul of a > > > patent applied for by AT&T: > > > > > > > > http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1 > > > &u > > > > > =%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PG01&s1=2 > > > 00 > > > 60031575&OS=20060031575&RS=20060031575 > > > > > > USPTO App Number 20060031575 > > > > Somene from ATT may want to consider pulling this patent > > application since it seems to fail on prior art... > > > > http://www.nanog.org/mtg-0410/soricelli.html > > > > presented by a juniper employee (Joe Soricelli ) and Wayne > > Gustavus from Verizon. IANAL though... > > >
Jeanette Symons (1962-2008) a commerical Internet Pioneer
It was with great sadness that I read about the un-timely death of my friend and colleague Jeanette in a plane crash in Maine. Jeanette died flying, which was one of the activities she loved to do. I meet her before she started flying and when she moved back to California she took up flying. We would be talking on the phone and she would say that it was VFR and she needed to go. VFR - Visual Flight Rules for flying without instruments which was all she was rated for at the time. I meet Jeanette at Hayes Microcomputer Products where we were working on a project together. People would think that we were brother and sister since we both had curly back hair and looked alike. When she wanted to move back to California, which she missed, I introduced her to Rob Ryan the head of Haye's West coast operations. When she was in Georgia we would eat Chinese, made by my wife, at my place. When we were in California we would eat Sushi at several of her favorite places in Western San Francisco and Oakland. Jeanette, Rob, Jay Duncanson and Steve Speckenbach left Hayes to start Ascend Communications and developed the TNT central site dial up modem, ISDN and Ethernet switch that handled most of the dial up Internet traffic for years. Ascend was purchased by Lucent and she and Mori started Zhone Technologies. Her new venture was started because her children wanted to blog with their friends and she was worried about them being on line. Jeanette will be missed. John Lee
RE: Blackholes and IXs and Completing the Attack.
ATT has no reason to pull their application, what needs to happen is that the publisher of the prior art contact the USPTO. If ATT willingly failed to note the prior art in their app, that may be a problem, but it isn't their duty to report ALL prior art, just the stuff they know about. IANAL, but I have filed some patents, and reviewed a bunch more. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Morrow > Sent: Saturday, February 02, 2008 12:58 PM > To: Tomas L. Byrnes > Cc: Ben Butler; Paul Vixie; nanog@merit.edu > Subject: Re: Blackholes and IXs and Completing the Attack. > > On Feb 2, 2008 3:39 PM, Tomas L. Byrnes <[EMAIL PROTECTED]> wrote: > > > The bigger issue with all these approaches is that they run > afoul of a > > patent applied for by AT&T: > > > > > http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1 > > &u > > > =%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PG01&s1=2 > > 00 > > 60031575&OS=20060031575&RS=20060031575 > > > > USPTO App Number 20060031575 > > Somene from ATT may want to consider pulling this patent > application since it seems to fail on prior art... > > http://www.nanog.org/mtg-0410/soricelli.html > > presented by a juniper employee (Joe Soricelli ) and Wayne > Gustavus from Verizon. IANAL though... >
Re: IPv6 Connectivity Saga (part n+1)
On Feb 2, 2008 6:24 PM, Thomas Kühne <[EMAIL PROTECTED]> wrote: > > Another factor is that with IPv4, you need to be pragmatic, because if > > you don't, you have no connectivity. With IPv6, you can impose > > arbitrary restrictions as much as you want, because IPv4 makes sure > > there is always fallback connectivity anyway. > > Maybe, but the most frequently encountered errors were time outs and > those usually degrade performance drastically. one might also consider that there may not be v4 conectivity in all cases, so if you offer up a please make sure the services on the relevant /A are consistent/available. -Chris
Re: Blackholes and IXs and Completing the Attack.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Roland Dobbins <[EMAIL PROTECTED]> wrote: >On Feb 3, 2008, at 4:50 AM, Paul Ferguson wrote: > >> We (Trend Micro) do something similar to this -- a black-hole BGP >> feed of known botnet C&Cs, such that the C&C channel is effectively >> black-holed. > >What's the trigger (pardon the pun, heh) and process for removing IPs from the blackhole list post-cleanup, in Trend's case? > We have a team that does the vetting/validation and when the C&Cs are taken down (or "decommissioned") they are removed from the feed. >Is there a notification mechanism so that folks who may not subscribe to Trend's service but who are unwittingly hosting a botnet C&C are made aware of same? > Well, we try to notify the owners of the identified hosts, but it is not always successful... and sometimes the sheer churn is prohibitive. - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFHpTu1q1pz9mNUZTMRAu+CAJ94j6AgqZgrMQ6b8HoPLyy4zBRcNgCfejWn dAE2T+i2MtvpAJ2PNJmdTpc= =N+iF -END PGP SIGNATURE- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
FW: Blackholes and IXs and Completing the Attack.
Hi, Agreed, but when you have >100 peers that is still a fair bit of work. I know technically how to do it and am doing this with transits but then there are only seven of those. It is not a question of how or can, but should / is it valuable / constructive? The starting point in the thought process having just done it for transits was right ok, now how do we sensibly scale this to apply it at IXes without everyone having to run round contacting everyone else and to see if there was an easier way of doing things, hence the suggestion. Plus it keeps things nice and separated, your IX peering sessions announce just the main prefixes, the session to the "blackhole reflector" can be in a separate peer-group and you only send the /32s to the reflector. You don't have to worry about who uses which communities as each member that chooses to peer with the reflector is able to apply an inbound routemap of their own choosing to any prefixes they receive from this reflector at each individual IX. Given that an ISP has elected to Complete the attack on a host that is being DoSed, for whatever reason, and they have chosen to send blackhole announcements to transit the logical extension seems to be to automate the sending of them to IXs to try to further cut down on traffic. I guess the alernative is that if your IX interconnect is getting hammered the only other option is to admin down all the sesions over the IX and let all the traffic flow into transit and let them blackhole it. But this also seems like there might be a better way that was less disruptive. And this seems like a easy way, internally you just community tag on the trigger box for where you want the announcement to go, transit, internal, customers, IX all,1 2 not 3 - whatever - and BGP sends it out. Easy, and a single system to send out all updates when you choose to and easy to remove when you want to take it out again. If you subscribe to completing the attack as a strategy, then the suggestion seemed like an easy way of rolling it out to the next logical point after transit. Kind Regards Ben From: Rick Astley [mailto:[EMAIL PROTECTED] Sent: 03 February 2008 01:02 To: Ben Butler Cc: nanog@merit.edu Subject: Re: Blackholes and IXs and Completing the Attack. While I am not sure I fully understand your suggestion, I don't think it would be that hard to set up manually. Sure it would require asking the individual peers for their black hole communities, but of they don't have one they are unlikely to honor the infrastructure you describe anyway. Assume your network is set up to discard packets marked with community 13005:666 Get a list of your peers blackhole communities, when you announce the route from a location on your network, tag it with community 13005:666 but also :777, :888 etc. for the individual peers from the source. This prevents you from having to update multiple policies in multiple locations for each attack. As long as they accept the /32 announced to them with their black hole community, they should discard the traffic without sending it to you. Not all peers will have a blackhole community, but you need some way to know when the attack is over to know when to withdraw the route, and they are useful for this. If you are real lazy, on the router you announce the black hole from, add an export policy that says from community 13005:666, then community add :777, :888 etc. This way you only need to: 1. Update one policy in one place when peers change 2. Announce the route from one location adding one community to it.
Re: Blackholes and IXs and Completing the Attack.
On Feb 3, 2008, at 4:50 AM, Paul Ferguson wrote: We (Trend Micro) do something similar to this -- a black-hole BGP feed of known botnet C&Cs, such that the C&C channel is effectively black-holed. What's the trigger (pardon the pun, heh) and process for removing IPs from the blackhole list post-cleanup, in Trend's case? Is there a notification mechanism so that folks who may not subscribe to Trend's service but who are unwittingly hosting a botnet C&C are made aware of same? --- Roland Dobbins <[EMAIL PROTECTED]> // 408.527.6376 voice Culture eats strategy for breakfast. -- Ford Motor Company
Re: Blackholes and IXs and Completing the Attack.
While I am not sure I fully understand your suggestion, I don't think it would be that hard to set up manually. Sure it would require asking the individual peers for their black hole communities, but of they don't have one they are unlikely to honor the infrastructure you describe anyway. Assume your network is set up to discard packets marked with community 13005:666 Get a list of your peers blackhole communities, when you announce the route from a location on your network, tag it with community 13005:666 but also :777, :888 etc. for the individual peers from the source. This prevents you from having to update multiple policies in multiple locations for each attack. As long as they accept the /32 announced to them with their black hole community, they should discard the traffic without sending it to you. Not all peers will have a blackhole community, but you need some way to know when the attack is over to know when to withdraw the route, and they are useful for this. If you are real lazy, on the router you announce the black hole from, add an export policy that says from community 13005:666, then community add :777, :888 etc. This way you only need to: 1. Update one policy in one place when peers change 2. Announce the route from one location adding one community to it.
Re: IPv6 Connectivity Saga (part n+1)
Thomas Kühne wrote: On Saturday February 2 2008, Iljitsch van Beijnum wrote: On 2 feb 2008, at 11:42, Thomas Kühne wrote: I took a DMOZ[1] dump What's a DMOZ dump? DMOZ: http://www.dmoz.org/about.html # The Open Directory Project is the largest, most comprehensive human-edited # directory of the Web. It is constructed and maintained by a vast, global # community of volunteer editors. A DMOZ dump is the complete data set including directory structure, links and descriptions. I've use this source because other lists are either too small or contain a lot of spam. I'd like to hear more about the methods that led to your summary, and, if possible, take a look at the raw data. It sounds to me like you took the dump file and parsed it so that all of the URLs could be sorted by domain. Did you then do DNS lookups on each domain name (or hostname?) and see how many had records? Did you also look at NS records (I am assuming you did)? I understand what TLDs and NSes are, but I don't quite know what you mean when you say things like "thus a cross check via TLDs' NS." As for raw data, at the very least, it would be useful to get a list of the resources that have some form of IPv6 brokenness, so that those of us who would actually like to provide our information resources over both IPv4 and IPv6 can get to work on fixing it. I personally am concerned that there are some islands of poor v6 connectivity out there that are having problems reaching v6 resources, even though other parts of the v6 world are able to reach those resources just fine. Because we may only be able to test from "good" v6 locations, we can't see what's wrong at the "bad" v6 locations. michael
Re: IPv6 Connectivity Saga (part n+1)
On Saturday February 2 2008, Iljitsch van Beijnum wrote: > On 2 feb 2008, at 11:42, Thomas Kühne wrote: > > I took a DMOZ[1] dump > > What's a DMOZ dump? DMOZ: http://www.dmoz.org/about.html # The Open Directory Project is the largest, most comprehensive human-edited # directory of the Web. It is constructed and maintained by a vast, global # community of volunteer editors. A DMOZ dump is the complete data set including directory structure, links and descriptions. I've use this source because other lists are either too small or contain a lot of spam. > > IPv6 failure rates of 4.3% (TLD) and 6.1% (NS) > > What does TLD and NS mean? TLD: Top Level Domain (e.g. .com, .us. org) NS: Name Server - in this case Domain Name Server (DNS) > > 43 : broadcast address > > ? Sorry, the same error message is also triggered by some firewalls. > Another factor is that with IPv4, you need to be pragmatic, because if > you don't, you have no connectivity. With IPv6, you can impose > arbitrary restrictions as much as you want, because IPv4 makes sure > there is always fallback connectivity anyway. Maybe, but the most frequently encountered errors were time outs and those usually degrade performance drastically. Thomas
RE: Blackholes and IXs and Completing the Attack.
"If you're trying to do it on a /32 basis, I doubt you'd find too many
border router operators interested in accepting a route that small, but
I may be wrong."
Well then they wouldn't be peering with this route reflector in the
first place.
-Original Message-
From: Tomas L. Byrnes [mailto:[EMAIL PROTECTED]
Sent: 02 February 2008 20:39
To: Ben Butler; Paul Vixie; nanog@merit.edu
Subject: RE: Blackholes and IXs and Completing the Attack.
You could achieve the exact same result simply by not advertising the
network to your peers, or by advertising a bogus route (prefixing a
known bogon AS for the addresses you want null-routed). I realize you
would have to subnet/deaggregate your netblocks, and therefore could
wind up with a prefix-length issue for peers who won't accept routes
longer than a certain mask, in some cases, but if you are already being
DDOSed, this should represent SOME improvement.
If you're trying to do it on a /32 basis, I doubt you'd find too many
border router operators interested in accepting a route that small, but
I may be wrong.
The bigger issue with all these approaches is that they run afoul of a
patent applied for by AT&T:
http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u
=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PG01&s1=200
60031575&OS=20060031575&RS=20060031575
USPTO App Number 20060031575
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Ben Butler
> Sent: Saturday, February 02, 2008 12:17 PM
> To: Paul Vixie; nanog@merit.edu
> Subject: RE: Blackholes and IXs and Completing the Attack.
>
>
> Hi,
>
> I was not proposing he Null routing of the attack source in the other
> ISPs network but the destination in my network being Null routed as a
> destination from your network out.
>
> This has no danger to the other network as it is my network that is
> going to be my IP space that is blackholed in your network, and the
> space blackholed is going to be an address that is being knocked of
> the air anyway under DoS and we are trying to minimise collateral
> damage. I cant see where the risk to the large NSP is - given that
> the route reflector will only reflect /32s that legitimately originate
> (as a destination not a source) in the AS announcing them as please
> blackhole.
>
> For complete clarity: AS13005 announces 213.170.128.0/19 and has its
> route object in RIPE as being announced by AS13005.
> My router at IX - BENIX say - announces 213.170.128.1/32 to the router
> reflector their, the announcement from my IX assigned address
> 212.121.34.30 is known to be my router on the exchange, and I am
> announcing a /32 from my AS for a route object registered as being
> announced by my AS - so the reflector accepts my announcement and
> reflects it to any other members that choose to peer with this
> reflector - effectively this is a please blackhole this destination in
> AS13005 - the other members that receive this announcement can then
> deal with it in anyway they see fit from ignoring it to setting
> next-hop 192.0.2.1 -> Null0.
>
> The effect of this would be that any BotNet controlled hosts in the
> other member network would now be able to drop any attack traffic in
> their network on destination at their customer aggregation routers.
>
> I think you might have thought I was suggesting we blackhole sources
> in other peoples networks - this is definatly not what I was saying.
>
> So, given we all now understand each other - why is no one doing the
> above?
>
> At the end of the day if an IX member doesn't want the announcements
> don't peer with the blackhole reflector, simple, and it will get Null
> routed as soon as it hits my edge router at the IX - it would just
> seem more sensible to enable people to block the traffic before it
> traverses the IX and further back in their own networks.
>
> So?
>
> Ben
>
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Paul Vixie
> Sent: 02 February 2008 17:32
> To: nanog@merit.edu
> Subject: Re: Blackholes and IXs and Completing the Attack.
>
>
> [EMAIL PROTECTED] ("Ben Butler") writes:
>
> > ...
> > This hopefully will ensure a relatively protected router
> that is only
> > accessible from the edge routers we want and also secured to only
> > accept filtered announcements for black holing and in consequence
> > enable the system to be trusted similar to Team Cymaru.
> > ...
>
> This sounds like another attempt to separate the Internet's control
> plane from its data plane, and most such attempts do succeed and are
> helpful (like NSP OOB, or like enterprise-level anycast of DNS).
> However, I'm not sure that remote triggered blackholes are a good
> direction, worthy of the protection you're proposing, for three
> reasons.
>
> First, because large NSP's simply cannot afford the risk associated
> with letting a third party, a
RE: Blackholes and IXs and Completing the Attack.
Hi, "i explained why this is bad -- it lowers the attacker's costs in what amounts to an economics war. they can get a web site taken down by its own provider just by attacking it. they need fewer resources for their attack once they know the provider's going to blackhole the victim." I thought the cold war nuclear arms race had shown up to be truly MAD. Who is paying for this ever escalating capacity of infrastructure as a way to survive large DoS attacks. Smaller attacks can be absorbed, but I really cant see a strategy of endlessly upgrading network router and WAN infrastructure to ensure enough head room ideal capacity is a particularly economically sensible approach to the problem. Ben -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Vixie Sent: 02 February 2008 21:37 To: Ben Butler Cc: nanog@merit.edu Subject: Re: Blackholes and IXs and Completing the Attack. > I was not proposing he Null routing of the attack source in the other > ISPs network but the destination in my network being Null routed as a > destination from your network out. i explained why this is bad -- it lowers the attacker's costs in what amounts to an economics war. they can get a web site taken down by its own provider just by attacking it. they need fewer resources for their attack once they know the provider's going to blackhole the victim. > This has no danger to the other network as it is my network that is > going to be my IP space that is blackholed in your network, and the > space blackholed is going to be an address that is being knocked of > the air anyway under DoS and we are trying to minimise collateral damage. your collateral damage is of precious little interest to someone else's backbone staff, unless they can route-filter the potential announcements so that you are unable to also remotely blackhole addresses you don't advertise. i explained this as an insurance/ISO9000 problem. > I think you might have thought I was suggesting we blackhole sources > in other peoples networks - this is definatly not what I was saying. i explained why this would be a more sensible approach, but STILL unworkable. > So, given we all now understand each other - why is no one doing the above? now that we've rehashed what we both said, i think we're done here.
RE: Blackholes and IXs and Completing the Attack.
"destination-based blackhole routing for mitigation *effectively completes the attack*, which is often times undesirable. Inter-domain source-based blackhole routing is pretty much a non-option." That is why I put Completing the Attack in my subject line - and didnt attempt to sujest this as an approach for source based filtering. "If you do implement something like this you may wish to scope advertisement only to adjacent ASes via NO_EXPORT or the like, to scope both more-specific propagation, and to ensure that some lack of consistent drop community semantic interpretation doesn't hose something." It is upto the receiving AS what they do with the announcement and whether they advertise it to their BGP customers or not - they shouldnt be announcing to anyone else anyway. I would sugest they dont, but I wouldnt presume. Advertisments to transits do not get propigated outside their AS. "I suppose if folks rely on it for native peering then it might be reasonable." This is envisage to be used between members of the same Internet Exchange only. Where there are so many peers the overhead of trying to do this on a peer peer basis / agreeing comunities is going to be a pain in the arse. And that this gives an easier way to get to the goal - we do after all trust the IX operator to run the critical bit of infrastrucutre which is the exchange. Kind Regards Ben -Original Message- From: Danny McPherson [mailto:[EMAIL PROTECTED] Sent: 02 February 2008 20:49 To: Ben Butler Cc: NANOG NANOG Subject: Re: Blackholes and IXs and Completing the Attack. On Feb 2, 2008, at 1:16 PM, Ben Butler wrote: > > So, given we all now understand each other - why is no one doing the > above? Some folks are doing this, just not via some third-party route servers. For example, either via customer peering sessions, or other BGP interconnections between peers. E.g.: http://www.nanog.org/mtg-0402/morrow.html I'm not sure it's ideal to employ third-party route servers for this purpose, as it only increases the attacks/error surface. I suppose if folks rely on it for native peering then it might be reasonable. > At the end of the day if an IX member doesn't want the announcements > don't peer with the blackhole reflector, simple, and it will get Null > routed as soon as it hits my edge router at the IX - it would just > seem more sensible to enable people to block the traffic before it > traverses the IX and further back in their own networks. Yes, helping to ease effects of collateral damage from large-scale attacks by conveying drop policies to upstream ASes for prefixes which you originate. And perhaps as significant, being able to allow the target AS to remove those policies dynamically, rather than having to contact each upstream AS that appears to have imposed them manually out-of-band. I think Paul's comments were more regarding the fact that destination-based blackhole routing for mitigation *effectively completes the attack*, which is often times undesirable. Inter-domain source-based blackhole routing is pretty much a non-option. One other offshoot is that advertised more-specifics are going to further contribute to routing AND forwarding table bloat, and a single new prefixes might result in 10+ new paths in the iBGP RIBs. If you do implement something like this you may wish to scope advertisement only to adjacent ASes via NO_EXPORT or the like, to scope both more-specific propagation, and to ensure that some lack of consistent drop community semantic interpretation doesn't hose something. Also, if you impose this as a standard attack response mechanism recall that you lose visibility of attack scales, and knowing just when to resume normal forwarding policies is a bit more complex. As such, your policy sets may want to provide hooks that enable selective prefix advertise/withdraw drop policies so that it can be applied or removed incrementally. -danny
RE: Blackholes and IXs and Completing the Attack.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- "Ben Butler" <[EMAIL PROTECTED]> wrote: >The effect of this would be that any BotNet controlled hosts in the >other member network would now be able to drop any attack traffic in >their network on destination at their customer aggregation routers. > >I think you might have thought I was suggesting we blackhole sources in >other peoples networks - this is definatly not what I was saying. > >So, given we all now understand each other - why is no one doing the >above? We (Trend Micro) do something similar to this -- a black-hole BGP feed of known botnet C&Cs, such that the C&C channel is effectively black-holed. At least that way, people can deal with cleaning up the end-systems in their own way, at their own pace, while the amount of malicious activity is effectively "crippled". - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFHpOWyq1pz9mNUZTMRAhtLAJwLNH9Ie+mE0106NlY6Qdy43uag1gCgv7wq le4yfSlaa2kUHtchC2X+bbQ= =4P1g -END PGP SIGNATURE- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Re: Blackholes and IXs and Completing the Attack.
> I was not proposing he Null routing of the attack source in the other > ISPs network but the destination in my network being Null routed as a > destination from your network out. i explained why this is bad -- it lowers the attacker's costs in what amounts to an economics war. they can get a web site taken down by its own provider just by attacking it. they need fewer resources for their attack once they know the provider's going to blackhole the victim. > This has no danger to the other network as it is my network that is > going to be my IP space that is blackholed in your network, and the > space blackholed is going to be an address that is being knocked of the > air anyway under DoS and we are trying to minimise collateral damage. your collateral damage is of precious little interest to someone else's backbone staff, unless they can route-filter the potential announcements so that you are unable to also remotely blackhole addresses you don't advertise. i explained this as an insurance/ISO9000 problem. > I think you might have thought I was suggesting we blackhole sources in > other peoples networks - this is definatly not what I was saying. i explained why this would be a more sensible approach, but STILL unworkable. > So, given we all now understand each other - why is no one doing the above? now that we've rehashed what we both said, i think we're done here.
Re: Blackholes and IXs and Completing the Attack.
On Feb 2, 2008 3:39 PM, Tomas L. Byrnes <[EMAIL PROTECTED]> wrote: > The bigger issue with all these approaches is that they run afoul of a > patent applied for by AT&T: > > http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u > =%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PG01&s1=200 > 60031575&OS=20060031575&RS=20060031575 > > USPTO App Number 20060031575 Somene from ATT may want to consider pulling this patent application since it seems to fail on prior art... http://www.nanog.org/mtg-0410/soricelli.html presented by a juniper employee (Joe Soricelli ) and Wayne Gustavus from Verizon. IANAL though...
Re: Blackholes and IXs and Completing the Attack.
On Feb 2, 2008, at 1:16 PM, Ben Butler wrote: So, given we all now understand each other - why is no one doing the above? Some folks are doing this, just not via some third-party route servers. For example, either via customer peering sessions, or other BGP interconnections between peers. E.g.: http://www.nanog.org/mtg-0402/morrow.html I'm not sure it's ideal to employ third-party route servers for this purpose, as it only increases the attacks/error surface. I suppose if folks rely on it for native peering then it might be reasonable. At the end of the day if an IX member doesn't want the announcements don't peer with the blackhole reflector, simple, and it will get Null routed as soon as it hits my edge router at the IX - it would just seem more sensible to enable people to block the traffic before it traverses the IX and further back in their own networks. Yes, helping to ease effects of collateral damage from large-scale attacks by conveying drop policies to upstream ASes for prefixes which you originate. And perhaps as significant, being able to allow the target AS to remove those policies dynamically, rather than having to contact each upstream AS that appears to have imposed them manually out-of-band. I think Paul's comments were more regarding the fact that destination-based blackhole routing for mitigation *effectively completes the attack*, which is often times undesirable. Inter-domain source-based blackhole routing is pretty much a non-option. One other offshoot is that advertised more-specifics are going to further contribute to routing AND forwarding table bloat, and a single new prefixes might result in 10+ new paths in the iBGP RIBs. If you do implement something like this you may wish to scope advertisement only to adjacent ASes via NO_EXPORT or the like, to scope both more-specific propagation, and to ensure that some lack of consistent drop community semantic interpretation doesn't hose something. Also, if you impose this as a standard attack response mechanism recall that you lose visibility of attack scales, and knowing just when to resume normal forwarding policies is a bit more complex. As such, your policy sets may want to provide hooks that enable selective prefix advertise/withdraw drop policies so that it can be applied or removed incrementally. -danny
RE: Blackholes and IXs and Completing the Attack.
You could achieve the exact same result simply by not advertising the
network to your peers, or by advertising a bogus route (prefixing a
known bogon AS for the addresses you want null-routed). I realize you
would have to subnet/deaggregate your netblocks, and therefore could
wind up with a prefix-length issue for peers who won't accept routes
longer than a certain mask, in some cases, but if you are already being
DDOSed, this should represent SOME improvement.
If you're trying to do it on a /32 basis, I doubt you'd find too many
border router operators interested in accepting a route that small, but
I may be wrong.
The bigger issue with all these approaches is that they run afoul of a
patent applied for by AT&T:
http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u
=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PG01&s1=200
60031575&OS=20060031575&RS=20060031575
USPTO App Number 20060031575
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Ben Butler
> Sent: Saturday, February 02, 2008 12:17 PM
> To: Paul Vixie; nanog@merit.edu
> Subject: RE: Blackholes and IXs and Completing the Attack.
>
>
> Hi,
>
> I was not proposing he Null routing of the attack source in
> the other ISPs network but the destination in my network
> being Null routed as a destination from your network out.
>
> This has no danger to the other network as it is my network
> that is going to be my IP space that is blackholed in your
> network, and the space blackholed is going to be an address
> that is being knocked of the air anyway under DoS and we are
> trying to minimise collateral damage. I cant see where the
> risk to the large NSP is - given that the route reflector
> will only reflect /32s that legitimately originate (as a
> destination not a source) in the AS announcing them as please
> blackhole.
>
> For complete clarity: AS13005 announces 213.170.128.0/19 and
> has its route object in RIPE as being announced by AS13005.
> My router at IX - BENIX say - announces 213.170.128.1/32 to
> the router reflector their, the announcement from my IX
> assigned address 212.121.34.30 is known to be my router on
> the exchange, and I am announcing a /32 from my AS for a
> route object registered as being announced by my AS - so the
> reflector accepts my announcement and reflects it to any
> other members that choose to peer with this reflector -
> effectively this is a please blackhole this destination in
> AS13005 - the other members that receive this announcement
> can then deal with it in anyway they see fit from ignoring it
> to setting next-hop 192.0.2.1 -> Null0.
>
> The effect of this would be that any BotNet controlled hosts
> in the other member network would now be able to drop any
> attack traffic in their network on destination at their
> customer aggregation routers.
>
> I think you might have thought I was suggesting we blackhole
> sources in other peoples networks - this is definatly not
> what I was saying.
>
> So, given we all now understand each other - why is no one
> doing the above?
>
> At the end of the day if an IX member doesn't want the
> announcements don't peer with the blackhole reflector,
> simple, and it will get Null routed as soon as it hits my
> edge router at the IX - it would just seem more sensible to
> enable people to block the traffic before it traverses the IX
> and further back in their own networks.
>
> So?
>
> Ben
>
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Paul Vixie
> Sent: 02 February 2008 17:32
> To: nanog@merit.edu
> Subject: Re: Blackholes and IXs and Completing the Attack.
>
>
> [EMAIL PROTECTED] ("Ben Butler") writes:
>
> > ...
> > This hopefully will ensure a relatively protected router
> that is only
> > accessible from the edge routers we want and also secured to only
> > accept filtered announcements for black holing and in consequence
> > enable the system to be trusted similar to Team Cymaru.
> > ...
>
> This sounds like another attempt to separate the Internet's
> control plane from its data plane, and most such attempts do
> succeed and are helpful (like NSP OOB, or like
> enterprise-level anycast of DNS).
> However, I'm not sure that remote triggered blackholes are a
> good direction, worthy of the protection you're proposing,
> for three reasons.
>
> First, because large NSP's simply cannot afford the risk
> associated with letting a third party, automatically and
> without controls or audits, decide in real time what sources
> or destinations shall become unreachable. With all respect
> (which is a lot) for spamhaus and cymru and even MAPS (which
> I had a hand in, back in the day), feeding BGP null-routes to
> a multinational backbone is a privilege that ISO9000 and
> SarBox and liability insurance providers don't usually want to extend.
>
> Second, because ma
Re: Sicily to Egypt undersea cable disruption
On Sat, 2 Feb 2008, Roland Dobbins wrote: There are always corner-cases like the Tamil Tiger incident, and people don't always act rationally even in the context of their own perceived (as opposed to actual) self-interest, but I just don't see any terrorist groups nor any governments involved in some kind of cable-cutting plot, as it's diametrically opposed to their commonality of interests (i.e., the terrorist groups want the comms to stay up so that they can make use of them, and the governments want the comms to stay up so that they can monitor the terrorist group comms). History is sometimes a useful subject. May I suggest the book "The Invisible Weapon: Telecommunications and International Politics 1851-1945" by Daniel Headrick. Let's cut all the cables is an old idea, and has been tried before. As usual, things didn't go as planned. Treaties exist because it was in everyone's self-interest to create the treaty. If any international terrorist or government espionage groups are reading NANOG: Hello. Please don't cut our cables. Thanks.
RE: Blackholes and IXs and Completing the Attack.
Hi,
I was not proposing he Null routing of the attack source in the other
ISPs network but the destination in my network being Null routed as a
destination from your network out.
This has no danger to the other network as it is my network that is
going to be my IP space that is blackholed in your network, and the
space blackholed is going to be an address that is being knocked of the
air anyway under DoS and we are trying to minimise collateral damage. I
cant see where the risk to the large NSP is - given that the route
reflector will only reflect /32s that legitimately originate (as a
destination not a source) in the AS announcing them as please blackhole.
For complete clarity: AS13005 announces 213.170.128.0/19 and has its
route object in RIPE as being announced by AS13005. My router at IX -
BENIX say - announces 213.170.128.1/32 to the router reflector their,
the announcement from my IX assigned address 212.121.34.30 is known to
be my router on the exchange, and I am announcing a /32 from my AS for a
route object registered as being announced by my AS - so the reflector
accepts my announcement and reflects it to any other members that choose
to peer with this reflector - effectively this is a please blackhole
this destination in AS13005 - the other members that receive this
announcement can then deal with it in anyway they see fit from ignoring
it to setting next-hop 192.0.2.1 -> Null0.
The effect of this would be that any BotNet controlled hosts in the
other member network would now be able to drop any attack traffic in
their network on destination at their customer aggregation routers.
I think you might have thought I was suggesting we blackhole sources in
other peoples networks - this is definatly not what I was saying.
So, given we all now understand each other - why is no one doing the
above?
At the end of the day if an IX member doesn't want the announcements
don't peer with the blackhole reflector, simple, and it will get Null
routed as soon as it hits my edge router at the IX - it would just seem
more sensible to enable people to block the traffic before it traverses
the IX and further back in their own networks.
So?
Ben
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Paul Vixie
Sent: 02 February 2008 17:32
To: nanog@merit.edu
Subject: Re: Blackholes and IXs and Completing the Attack.
[EMAIL PROTECTED] ("Ben Butler") writes:
> ...
> This hopefully will ensure a relatively protected router that is only
> accessible from the edge routers we want and also secured to only
> accept filtered announcements for black holing and in consequence
> enable the system to be trusted similar to Team Cymaru.
> ...
This sounds like another attempt to separate the Internet's control
plane from its data plane, and most such attempts do succeed and are
helpful (like NSP OOB, or like enterprise-level anycast of DNS).
However, I'm not sure that remote triggered blackholes are a good
direction, worthy of the protection you're proposing, for three reasons.
First, because large NSP's simply cannot afford the risk associated with
letting a third party, automatically and without controls or audits,
decide in real time what sources or destinations shall become
unreachable. With all respect (which is a lot) for spamhaus and cymru
and even MAPS (which I had a hand in, back in the day), feeding BGP
null-routes to a multinational backbone is a privilege that ISO9000 and
SarBox and liability insurance providers don't usually want to extend.
Second, because many backbone routers in use today can't do policy
routing routing (which is in this case dropping packets because their
source address, not their destination address, has a particular
community associated with it) at line speed. Note, this is many-not-all
-- I'm perfectly aware that lots of backbone routers can do this but not
everybody has them or can afford them and those who have them tend to be
the multinational NSPs discussed earlier.
To prevent our DDoS protection reflexes from lowering an attacker's cost
(by automatically blackholing victims to protect the nonvictims), we
have to be able to blackhole the abusive traffic by source, not by
destination.
Third, because many OPNs (other people's networks) still don't filter on
source address on their customer-facing edge, and thus allow
spoofed-source traffic to exit toward "the core" or toward a victim's
NSP who cannot filter by source due to path ambiguities inherent in "the
core", any wide scale implementation of this, even if we could get
trusted automation of it at scale and even if everybody had
policy-routing-at-like-speed, would just push the attackers toward
spoofed-source. That means a huge amount of work and money for the
world, without changing the endgame for attackers and victims at all.
(See BCP38 and SAC004 for prior rants on this controversial topic.)
RE: Another cablecut - sri lanka to suez Re: Sicily to Egypt undersea cable disruption
Gentlemen,
This is my last comment on this subject.
Paranoia is not a virtue. And security establishments are notorious for
exaggerating threats (Soviet Union's economy and hence ability to wage war was
half of what the CIA estimated). They are interest groups just like the rest of
us ... They pursue their self interest as General Eisenhower noted about a
certain's military establishment.
:)
If you know the undersea cable industry, you know that several cables can be
down at the same time without malice playing a role...
Last year both undersea cables into Pakistan were severed. The two cables were
laid within several feet of each other along a stretch of shallow water.
When a ship sank, it crushed both cables.
In December of 2006, three Irish sea cables went dead. One was cut in twenty
feet of water. One was cut on land and a third damaged in the middle of the
Irish sea.
It happens all the time.
Terrorists are clearly looking for more high profile events than disrupting
unmanned undersea cable systems. It doesn't make for great television shots ...
It is really to get shots of an undersea severed cable ...
Have a good weekend.
Regards,
Roderick S. Beck
Director of European Sales
Hibernia Atlantic
1, Passage du Chantier, 75012 Paris
http://www.hiberniaatlantic.com
Wireless: 1-212-444-8829.
Landline: 33-1-4346-3209.
French Wireless: 33-6-14-33-48-97.
AOL Messenger: GlobalBandwidth
[EMAIL PROTECTED]
[EMAIL PROTECTED]
``Unthinking respect for authority is the greatest enemy of truth.'' Albert
Einstein.
-Original Message-
From: [EMAIL PROTECTED] on behalf of Robert Bonomi
Sent: Sat 2/2/2008 7:20 PM
To: nanog@merit.edu
Subject: Re: Another cablecut - sri lanka to suez Re: Sicily to Egypt undersea
cable disruption
> Date: Fri, 1 Feb 2008 14:21:00 -0800
> From: "Scott Francis" <[EMAIL PROTECTED]>
> Subject: Re: Another cablecut - sri lanka to suez Re: Sicily to Egypt
> undersea cable disruption
>
>
> On Feb 1, 2008 6:37 AM, Suresh Ramasubramanian <[EMAIL PROTECTED]> wrote:
> >
> > http://www.marketwatch.com/news/story/third-undersea-cable-reportedly-cut/story.aspx?guid={1AAB2A79-E983-4E0E-BC39-68A120DC16D9}
> >
> > "We had another cut today between Dubai and Muscat three hours back.
> > The cable was about 80G capacity, it had telephone, Internet data,
> > everything," one Flag official, who declined to be named, told Zawya
> > Dow Jones.
> > The cable, known as Falcon, delivers services to countries in the
> > Mediterranean and Gulf region, he added.
>
> this (3 undersea cables in about a week, serving the same geographic
> area, with two of the cuts happening on the same day!) is leaving the
> realm of improbability and approaching the realm of conspiracy ...
"Never ascribe to malice that which can be explained by incompetence"
comes to mind.
Re: Another cablecut - sri lanka to suez Re: Sicily to Egypt undersea cable disruption
> Date: Fri, 1 Feb 2008 14:21:00 -0800
> From: "Scott Francis" <[EMAIL PROTECTED]>
> Subject: Re: Another cablecut - sri lanka to suez Re: Sicily to Egypt
> undersea cable disruption
>
>
> On Feb 1, 2008 6:37 AM, Suresh Ramasubramanian <[EMAIL PROTECTED]> wrote:
> >
> > http://www.marketwatch.com/news/story/third-undersea-cable-reportedly-cut/story.aspx?guid={1AAB2A79-E983-4E0E-BC39-68A120DC16D9}
> >
> > "We had another cut today between Dubai and Muscat three hours back.
> > The cable was about 80G capacity, it had telephone, Internet data,
> > everything," one Flag official, who declined to be named, told Zawya
> > Dow Jones.
> > The cable, known as Falcon, delivers services to countries in the
> > Mediterranean and Gulf region, he added.
>
> this (3 undersea cables in about a week, serving the same geographic
> area, with two of the cuts happening on the same day!) is leaving the
> realm of improbability and approaching the realm of conspiracy ...
"Never ascribe to malice that which can be explained by incompetence"
comes to mind.
Re: Another cablecut - sri lanka to suez Re: Sicily to Egypt undersea cable disruption
$quoted_author = "Scott Francis" ; > > maybe there's a lot more overlap in shipping lanes and cable runs than > I thought ... In confined waters like the Suez, Red Sea et. al. there is a lot of overlap. Which makes three cables cuts in that area during bad weather not such a stretch of the imagination. Open waters like trans-Atlantic and trans-Pacific have less overlap with shipping lanes but still need to cross fishing areas etc.etc. But you'd be a little more suspicious if those sites had a similar cluster of cuts unless there was something in common (i.e. same landing station, cuts close to shore). cheers marty -- "Life's Little Mysteries. Noel Hunter of Chippendale is one of many to be confused, and amused, by the pair of professionally produced No Regrets street signs near the corner of Greens Road and Albion Avenue, Paddington. Printed in the same style as No Standing signs, their proximity to the College of Fine Arts may give a clue to their origins. Whatever, having regrets while between the signs is subject to a $144 fine from the NSW Dept of Second Thoughts." [1] [1] - http://www.smh.com.au/articles/2004/03/31/1080544560873.html
RE: Another cablecut - sri lanka to suez Re: Sicily to Egypt undersea cable disruption
Really? What cable is that?! -Original Message- From: Rubens Kuhl Jr. <[EMAIL PROTECTED]> Sent: 02 February 2008 11:33 To: nanog@merit.edu Subject: Re: Another cablecut - sri lanka to suez Re: Sicily to Egypt undersea cable disruption > "NEW YORK (AP) -- The lines that tie the globe together by carrying > phone calls and Internet traffic are just two-thirds of an inch thick > where they lie on the ocean floor." And AFAIK not all kilometers of cables lie on the ocean floor; if the ocean has high depth on a given part of the cable route, the cable simply floats on the water on that run. It's just a matter of having enough pressure to lift it up. Rubens
Re: Blackholes and IXs and Completing the Attack.
[EMAIL PROTECTED] ("Ben Butler") writes:
> ...
> This hopefully will ensure a relatively protected router that is only
> accessible from the edge routers we want and also secured to only accept
> filtered announcements for black holing and in consequence enable the
> system to be trusted similar to Team Cymaru.
> ...
This sounds like another attempt to separate the Internet's control plane
from its data plane, and most such attempts do succeed and are helpful
(like NSP OOB, or like enterprise-level anycast of DNS). However, I'm not
sure that remote triggered blackholes are a good direction, worthy of the
protection you're proposing, for three reasons.
First, because large NSP's simply cannot afford the risk associated with
letting a third party, automatically and without controls or audits, decide
in real time what sources or destinations shall become unreachable. With
all respect (which is a lot) for spamhaus and cymru and even MAPS (which I
had a hand in, back in the day), feeding BGP null-routes to a multinational
backbone is a privilege that ISO9000 and SarBox and liability insurance
providers don't usually want to extend.
Second, because many backbone routers in use today can't do policy routing
routing (which is in this case dropping packets because their source address,
not their destination address, has a particular community associated with it)
at line speed. Note, this is many-not-all -- I'm perfectly aware that lots
of backbone routers can do this but not everybody has them or can afford them
and those who have them tend to be the multinational NSPs discussed earlier.
To prevent our DDoS protection reflexes from lowering an attacker's cost (by
automatically blackholing victims to protect the nonvictims), we have to be
able to blackhole the abusive traffic by source, not by destination.
Third, because many OPNs (other people's networks) still don't filter on
source address on their customer-facing edge, and thus allow spoofed-source
traffic to exit toward "the core" or toward a victim's NSP who cannot filter
by source due to path ambiguities inherent in "the core", any wide scale
implementation of this, even if we could get trusted automation of it at
scale and even if everybody had policy-routing-at-like-speed, would just push
the attackers toward spoofed-source. That means a huge amount of work and
money for the world, without changing the endgame for attackers and victims
at all. (See BCP38 and SAC004 for prior rants on this controversial topic.)
Re: IPv6 Connectivity Saga (part n+1)
On 2 feb 2008, at 11:42, Thomas Kühne wrote: I took a DMOZ[1] dump What's a DMOZ dump? 33.4% of all services that advertised IPv6 failed to deliver or in other words the IPv6 failure rate is ten times the NS failure rate. "failing to deliver" is not necessarily a failure condition, in my opinion. IPv6 failure rates of 4.3% (TLD) and 6.1% (NS) What does TLD and NS mean? About 4 days later I did a more detailed check of the hosts with broken IPv6: 1624 : hosts total 827 : connection timed out That would be bad. 382 : no route to host Not quite as bad, but also not good. 249 : connection refused Although it would be better to avoid this condition, I wouldn't count it as a failure. This typically happens when a host has an IPv6 address in the DNS, but a service isn't reachable over IPv6. Since reasonable implementations will retry over IPv4 after a round trip, this doesn't cause any real trouble. 43 : broadcast address ? 22 : IPv6 assignments reclaimed (3ffe::/16) Which shows that installing IPv6 (or anything, really) is pretty much "install and forget", which goes to the "use it or lose it" doctrine: only services that are actually used will remain operational. Issues(cases not marked with a star) do tend to arise but why are fundamental issues like "connection timed out", "no route to host" and "connection refused" so frequent? Like I said: if something isn't used, it doesn't get fixed if it doesn't work. Interestingly, if something new is set up incorrectly and then someone comes along who wants to use the new option, and it doesn't work, the blame is laid at the person who decided to use the new option, rather than the person who offered a service over it but didn't make sure it worked correctly. I've been downloading files from the FTP servers of the five RIRs a few times a week for several years now. I haven't kept track of it, but it seems that it's gotten harder to reach these FTP servers over IPv6 the past year or so. This could very well have something to do with IPv6 becoming more mainstream, so it's no longer some experimental thing that can be enabled without trouble, but a production service that must be firewalled. This seems to be the source of much trouble, especially with ARIN, which I can't successfully reach over IPv6 anymore, probably because of a routing issue between their and my ISPs. But before that, I had path MTU problems towards them on several occasions. Another factor is that with IPv4, you need to be pragmatic, because if you don't, you have no connectivity. With IPv6, you can impose arbitrary restrictions as much as you want, because IPv4 makes sure there is always fallback connectivity anyway.
Re: Another cablecut - sri lanka to suez Re: Sicily to Egypt undersea cable disruption
And AFAIK not all kilometers of cables lie on the ocean floor; if the ocean has high depth on a given part of the cable route, the cable simply floats on the water on that run. It's just a matter of having enough pressure to lift it up. and for the difficult parts, they pump helium in and get it above flight paths. randy
Re: Another cablecut - sri lanka to suez Re: Sicily to Egypt undersea cable disruption
> "NEW YORK (AP) -- The lines that tie the globe together by carrying > phone calls and Internet traffic are just two-thirds of an inch thick > where they lie on the ocean floor." And AFAIK not all kilometers of cables lie on the ocean floor; if the ocean has high depth on a given part of the cable route, the cable simply floats on the water on that run. It's just a matter of having enough pressure to lift it up. Rubens
IPv6 Connectivity Saga (part n+1)
I took a DMOZ[1] dump, extracted all unique domain-name port combinations and checked their IPv6 connectivity. 3 388 012 : 100.000% : total 3 260 296 : 96.230% : IPv4 only 122 560 : 3.620% : bad NS 3 372 : 0.100% : IPv6 working 1 694 : 0.050% : broken or "fake" IPv6 broken: TCP connect failed fake: IPv6 mapped IPv4 addresses (e.g. :::1.2.3.4) 33.4% of all services that advertised IPv6 failed to deliver or in other words the IPv6 failure rate is ten times the NS failure rate. Seems high, thus a cross check via TLDs' NS: 270 : 100.0% : TLD total (excluding the IDN tests) 268 : 99.3% : IPv4 working 2 : 0.7% : IPv4 broken (HM and KP) 177 : 65.6% : IPv6 working 8 : 3.0% : IPv6 broken 1910 : 100.0% : NS total 1500 : 78.5% : IPv4 only 31 : 1.6% : IPv4 broken 356 : 19.1% : IPv6 working 23 : 1.2% : IPv6 broken IPv6 failure rates of 4.3% (TLD) and 6.1% (NS) is lower than the above 33.4% but are still significantly higher than the IPv4 failure rates of 0.7% (TLD) and 1.6% (NS). TLD root-NSs usually are managed by dedicated infrastructure organisations thus better trouble shooting than the DMOZ listed ones get is expected and suggests the above 33.4% failure rate isn't some kind of sampling artifact. About 4 days later I did a more detailed check of the hosts with broken IPv6: 1624 : hosts total 827 : connection timed out 382 : no route to host 249 : connection refused 95 : network unreachable 54 : SixXS never received a route announcement for that block 43 : broadcast address 30 : * IPv4 in IPv6 22 : IPv6 assignments reclaimed (3ffe::/16) 16 : * no IPv6 (::) 12 : * IPv4 only 10 : * IPv6 working 4 : IPv6 never assigned 4 : local (fe80::/10) 2 : local (::1) 2 : broken NS Issues(cases not marked with a star) do tend to arise but why are fundamental issues like "connection timed out", "no route to host" and "connection refused" so frequent? (testing was done from 2a01:4d0:102::31) Thomas [1] http://www.dmoz.org/help/getdata.html
