RE: Blackholes and IXs and Completing the Attack.

["Tomas L. Byrnes" <tomb () byrneit net>]

IANAL, but my understanding of patents is that anyone can patent any
innovative combination of existing things, if it produces a new effect
or is used in a new way. According to the patent lawyers I've worked
with, that is, in fact, the most common type of patent. As an example,
Watt's steam engine combined a piston, a balance beam, a wheel, and a
crank, all of which existed before, but his invention was patented.

The ATT patent is on black-holing using BGP null routing to mitigate
DDOS.

As far as your proposal goes, perhaps I had misunderstood. My
understanding was that you wanted everyone in the Internet to accept
routes from an AS that was intended to be black-holed. Those routes
would be hosts (/32) that were, in fact, placed in the route server by
some trusted community (presumably hosters). The benefit of this would
be to eliminate the collateral damage to other customers of the hosters
caused by traffic targeting the DDOS target also denying service to
them. 

If I have misunderstood, then I'm sorry, but my responses were based on
the following assumptions:

1: The routes to be black-holed would all be /32s

2: The routes to be black-holed would have to be, in order to be
effective, accepted by routers that carried the vast majority of the
Internet's traffic, since you want to drop DDOS traffic as close to its
source as possible. In my mind that would, at the very least include all
the routers at major aggregation and peering points. 

3: Backbone routers can't reasonably filter on a bunch of /32s and also
forward traffic at wire speed.

4: It would be much harder to get all the ingress networks, which
include all sorts of small local and regional ISPs, to join such a
scheme than it would be to get larger ISPS to do so, assuming item 3
above is not true.

5: When one /32 is under DDOS, the rest of the hosts served by the same
links are also effectively DOSed, ergo renumbering them out of the DOSed
space, while painful, might be less painful than continuing to deal with
the DOS.

6: You control what routes you advertise, and therefore can,
effectively, make any prefix as short as or shorter than the shortest
prefix accepted by your peers go dark, simply by stopping advertising
it.

7: The increase in route prefixes caused by disaggregating would,
assuming that there were multiple DDOS targets at any one time, not be
materially larger than that caused by accepting a bunch of /32s, and may
well be less.

8: Disaggregation can be done now, with the tools currently available,
and requires no additional hardware, software, or legal agreements.

It seems that you are saying that you're just asking your immediate
peers to accept this private AS from you, to black-hole traffic to that
AS locally, and not propagate the routes to their peers. That's
completely different than what I thought you were talking about, which
was some sort of Internet-wide black-hole AS that everyone was supposed
to peer with. What you and your immediate peers do is between you and
them, and I could see this as working quite well on that basis. All it's
doing, however, is absorbing the DDOS one step upstream, which is
probably a place that can do so more easily, and clearly is doing so any
time the DDOS is getting through.

In any event, as I pointed out, null routing via BGP to defend against
DDOS is Patent Pending ATT, so unless you can get the patent not to
issue, building a network based on it runs the risk of the patent troll.

I've said my piece on this. Where I've made errors or misspoken, I'm
happy to stand corrected. If I've offended anyone, I'm sorry. 

Best wishes to all. May your packets flow, your sessions connect, and
your pagers remain silent.

> -----Original Message-----
> From: Ben Butler [mailto:ben.butler () c2internet net] 
> Sent: Sunday, February 03, 2008 5:31 AM
> To: Tomas L. Byrnes; nanog () merit edu
> Subject: RE: Blackholes and IXs and Completing the Attack.
>
> Hi,
>
> I am no lawyer, but I question whether ATT can patent 
> anything that uses the existing technology and commands 
> implemented in BGP.  The idea that you can patent a persons 
> intent in advertising a prefix in BGP seems somewhat bizarre. 
>  Surely a patent relates to the use of a new bit of 
> technology that they have developed.
>
> Btw, I think I might be a good idea to do all sort of things, 
> that doesn't mean I can file legally enforceable patents in 
> case someone in the future shares my point of view.
>
>
> With regards to:
>
> "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."
>
> I just think you don't get it. Apart from the impracticality 
> of renumbering all the other non-effected hosts in the same 
> /24 and all the associated DNS records and the amount of time 
> that is going to take.
> Plus then announce another /24 for the renumbered hosts. You 
> are are saying that I should de-aggregate the /19 
> announcement into components so that I can stop advertising 
> the original /24 - because your worried about route table 
> prefix pollution!!!!
>
> If I blackhole a /32 to my transits, it does not appear in 
> your routing table.  If I blackhole a /32 to one of my peers 
> and you are not even at the same IX, then there is no change 
> of it appearing in your route table either.  Conversely you 
> seem to be suggesting I announce a bunch of prefixes to everyone?
>
> Kind Regards
>
> Ben
>
> -----Original Message-----
> From: Tomas L. Byrnes [mailto:tomb () byrneit net]
> Sent: 03 February 2008 07:54
> To: Ben Butler; nanog () merit edu
> Subject: 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:ben.butler () c2internet net]
> > 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:tomb () byrneit net]
> > 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: owner-nanog () merit edu [mailto:owner-nanog () merit edu]
> > 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: owner-nanog () merit edu [mailto:owner-nanog () merit edu]
> > On Behalf
> > > Of Paul Vixie
> > > Sent: 02 February 2008 17:32
> > > To: nanog () merit edu
> > > Subject: Re: Blackholes and IXs and Completing the Attack.
> > >
> > >
> > > ben.butler () c2internet net ("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.)
> > >