Subject: RE: Need your opinion of this.

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Fri, 26 Jul 2002 16:54:56 -0400

Doughan:
  Let me see if I understand the fundamental point of your draft. You want
BGP via communities to be the big MAGNET that catches all the denial of
service attack routes and shoves them through some sink hole router that
will keep statistics and knowledge of the source of the attack and be able
to report it to the operator?
 
Did I summarize it properly?
 
My first reaction, is what kind of overhead will these techniques impose on
the routers and the sink hole one? 
 
Will it be scallable? 
 
Can this be done only on border routers, Router Reflectors? To minimize the
processing load needed?
 
What real life cases have you seen where this mechanism was needed?
 
Have you prototyped this idea and gotten some empirical data?
 
Ben

-----Original Message-----
From: Turk, Doughan A. [mailto:[email-masked]]
Sent: Friday, July 26, 2002 4:09 PM
To: [email-masked]
Cc: Turk, Doughan A.
Subject: Need your opinion of this.

Folks, 
 
I would like to get some discussion started on a draft I wrote. It was
suggested to me to have the draft worked on under this group. I appreciate
any constructive comments and pointers. In summary, the draft could be
classified as an operational one. It is an enhancement of a technique that
already exists but relying more on BGP as a protocol to help in network
security issues.
 
A copy of the draft could be found at
http://www.ietf.org/internet-drafts/draft-turk-ertb-00.txt
<http://www.ietf.org/internet-drafts/draft-turk-ertb-00.txt> 
 
Regards
Doughan Turk
 
   _____  

 <http://www.bell.ca/> Bell Canada Logo

Doughan Turk, M.Eng., CCIE#7274
Bell Canada, IP Engineering
Flr 3, 100 Wynford Dr. 
Toronto M3C 1K4

Voice: (416) 353-0368
Fax: (416) 445-9893
Pager: (416) 685-0590
 <http://www.bell.ca/> Bell Canada

 Cisco Certified Internetwork Expert
<http://www3.sympatico.ca/doughan/ccie_large.gif> 

         "To Engineer and Integrate world class
                              IP Services and Technologies for BCE"

---

From: "Turk, Doughan A." <[email-masked]>
Date: Fri, 26 Jul 2002 20:27:31 -0400

Benjamin,
 
BGP will be used to alter next-hop address for a particular destination
address (representing a customer under attack) on selected Routers. Instead
of using BGP to announce a different next-hop for the destination address
everywhere in your network. we can use communities to make it selective.
once that is achieved, your next hop can be a null interface or a Tunnel
interface where the traffic is then pulled to the sinkhole router. 
 
Based on Attack signature you could do various packet lever filtering ( with
hardware as a constrain),  simply rate limit the flow or send it out through
a shared media (Ethernet) for sniffing after you pull it to a sinkhole
router.
 
As for overheads on routers in the network, there is hardly any since you're
only altering next-hop on border routers or edge routers. MPLS tunnel are
what I used in my lab. as for the sinkhole router, one can invest in a high
performance line card. The sinkhole router should be powerful enough to
handle whatever filtering or policing you deem required to massage the flow.

Scalability is high in my opinion. the route maps on the borders can be a
part of your template. announcing the destination address with the special
community would have to be done on only one router (sinkhole is a good
idea).
 
As for where to place the route maps or policy statements, IMHO, this should
be applied anywhere a large attack can enter from. (I.e Transit links or to
Peers with large number of subscribers) I wouldn't apply it on a customer
interface since a customer is in my reach and can be contacted immediately
in case of an attack initiated by him. Another place to apply it on is at
peering interfaces where an access-list or policing statement might bring
down interface performance. at this point traffic can be pulled in the
sinkhole router for the policies to be applied.
 
This technique can be used in high volume attacks where source based
filtering is not possible because of spoofing or high number of source IP
addresses. In many cases ISP's are forced to kill traffic destined to a
single /32 to relief the rest of the customer network from suffering from
the high volume of traffic. I would also use this in cases of attacks
targeting infrastructure.
 
As for the last question, yes I have built this in a large lab and got the
result I expected.
 
Hope this answers your questions.
 
Regards
DT

-----Original Message-----
From: Abarbanel, Benjamin [mailto:[email-masked]] 
Sent: Friday, July 26, 2002 4:55 PM
To: 'Turk, Doughan A.'; [email-masked]
Subject: RE: Need your opinion of this.

Doughan:

 
Will it be scallable? 

 
 
Ben

-----Original Message-----
From: Turk, Doughan A. [mailto:[email-masked]]
Sent: Friday, July 26, 2002 4:09 PM
To: [email-masked]
Cc: Turk, Doughan A.
Subject: Need your opinion of this.

Folks, 

 
Regards
Doughan Turk
 
  _____  

Voice: (416) 353-0368
Fax: (416) 445-9893
Pager: (416) 685-0590

---

From: "Turk, Doughan A." <[email-masked]>
Date: Sat, 27 Jul 2002 14:59:46 -0400

Sri,
 
The draft is not addressing a box or a protocol security. I am using BGP
capabilities to assist in fighting DoS attacks. The reason why BGP is a
protocol suitable for this job is it's many attributes like "communities".
Since routing is the driver of traffic why not develop ways to use routing
protocols to assist in fighting attacks.
 
Regards
DT

-----Original Message-----
From: PamSri [mailto:[email-masked]] 
Sent: Saturday, July 27, 2002 11:19 AM
To: Turk, Doughan A.
Cc: [email-masked]
Subject: RE: Need your opinion of this.

Hi Turk , 

            Here are a few more questions : 

1. Is DoS a problem specific to BGP or the box ? 

2. So do we provide this kind of solution to all the routing protocols.

3. Here's what i think : DoS, Anti-Spoofing, Firewalls etc.. can be
catagorized as IP Services. Do we want to bring these concepts into IP
routing ? 

4. There are vendors who provide these IP Services along with routing by
clearly making a distinction between these two concepts. 

Regards, 

sri 

 "Turk, Doughan A." wrote: 

The draft does not suggest a way of verifying reverse path or validating
source address. My comment was just an answer to Sri's questions. BGP is the
only routing protocol I can think of with the capabilities to do what the
draft suggests. More information about the draft can be found at
http://www.ietf.org/internet-drafts/draft-turk-ertb-00.txt

DT

-----Original Message-----
From: Justin Fletcher [mailto:[email-masked]] 
Sent: Friday, July 26, 2002 9:11 PM
To: Turk, Doughan A.
Cc: [email-masked]
Subject: RE: Need your opinion of this.

On Fri, 2002-07-26 at 18:24, Turk, Doughan A. wrote:
> I am using BGP to help stopping DoS and DDoS traffic. BGP can send 
> updates quickly and route-maps can translate communities to stop 
> traffic destined to a certain destination. TCP is not the issue here. 
> Attackers usually relay on the fact that most routers out there do 
> destination based routing without checking the validity of the source 
> address in case it is spoofed.
> 
> DT
> 

Is BGP the place to do this? Note this section from RFC1812:

5.3.8 Source Address Validation

A router SHOULD IMPLEMENT the ability to filter traffic based on a
comparison of the source address of a packet and the forwarding table
for a logical interface on which the packet was received. If this
filtering is enabled, the router MUST silently discard a packet if
the interface on which the packet was received is not the interface
on which a packet would be forwarded to reach the address contained
in the source address. In simpler terms, if a router wouldn't route
a packet containing this address through a particular interface, it
shouldn't believe the address if it appears as a source address in a
packet read from this interface.

--
Justin Fletcher
Proficient Networks, Inc.

  _____  

Do You Yahoo!?
Yahoo! Health <http://health.yahoo.com/>  - Feel better, live better

---

From: "Turk, Doughan A." <[email-masked]>
Date: Sat, 27 Jul 2002 15:16:36 -0400

Tandel,

no-advertise is used to avoid the advertisement of a prefix to all peers
including iBGP. The one that stops a prefix from going out to eBGP neighbors
is the no-export or no-export-subconfed. To keep things in prospective, a
router should not crash because of attack traffic transiting through it.
Routing protocols take precedence over regular traffic in my understanding.
Even if an attack is so big in volume it will never exceed your link
capacity and therefore your upstream provider will be dropping all excess
traffic. 

To clarify one thing, When you identify a destination address as a target
you do not stamp the entire network with the special community. Lets for
example take a case of a customer with a /24 of which one host /32 is under
attack at this point you announce the /32 in addition to the /24 where the
/32 has the special community but the /24 gets advertised normally.

Regards
DT

-----Original Message-----
From: TANDEL Sebastien [mailto:[email-masked]] 
Sent: Saturday, July 27, 2002 10:08 AM
To: Turk, Doughan A.
Subject: Re: Need your opinion of this.

Hello,

   It's just a question about the use of the community...
   If I have understood your method, when you overwrite the community with
the well-known community no-advertise, it's to avoid the advertisement of
this community in the others eBGP sessions.

   So why don't you use the extended communities ?
   (IMHO) There are two reasons to use the extended communities and not the
community. With the extended community, you can set the non transitive bit.
This has two consequences:

   	1) this community is not advertised to other eBGP sessions
   	2) While there is an attack and if there is a drop session with
           the BGP router (by which the attack traffic goes through) in
           session with the border router (i.e. R1) which recognizes the
           regular community, the prefix under attack will not be
           advertised anymore by R1.
           So there is two cases :
   		a) this prefix is not reachable anymore. In this cases
                   there is a black hole (of course this is the case for
                   an attack routed to a network for an analysis, but
                   there will be no more analysis).
   		b) this prefix can be reach but by another route. And in
                   this case, you have to restart an other operation like
                   described in your draft on another border router.
   	   But if you are using the extended community with the non
           transitive bit set, this prefix will always be advertised in
           any cases and without the community value.

----------------------------
Tandel Sébastien
2ème licence en informatique
F.U.N.D.P.
[email-masked]
----------------------------

On Fri, 26 Jul 2002, Turk, Doughan A. wrote:

> suggested to me to have the draft worked on under this group. I 
> appreciate any constructive comments and pointers. In summary, the 
> draft could be classified as an operational one. It is an enhancement 
> of a technique that already exists but relying more on BGP as a 
> protocol to help in network security issues.
>

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Mon, 29 Jul 2002 10:06:14 -0400

Doughan:

Since some of the traffic that is trapped with the DoS traffic is going to
be
redirected to the sinkhole router. would that cause those poor cutomers to
loose thier communications?

What if the sinkhole router was smart enough to filter through the good
packets from the bad, could it then redirect the good packets back to their
intended destination? 

If so, that implies the sinkhole routers have alot more cycles to handle all
the load that will be imposed on them by this service.

Is source and destination address the only things needed to filter good
packets from bad ones?

My instinct tells me it is better to stop DoS traffic before it enters the
cloud on the border router, then try to manage it at some redirected
sinkhole router. 

Communities attribute although they tend to converge on some Next Hop would
tend to propagate the traffic through the cloud and thereby cause more
loading conditions on the intermediary routers.

Ben

> Sent: Friday, July 26, 2002 9:24 PM
> To: PamSri
> Cc: [email-masked]
> I am using BGP to help stopping DoS and DDoS traffic. BGP can 
> send updates
> quickly and route-maps can translate communities to stop 
> traffic destined to
> a certain destination. TCP is not the issue here. Attackers 
> usually relay on
> the fact that most routers out there do destination based 
> routing without
> checking the validity of the source address in case it is spoofed.
> 
> DT
> 
> Sent: Friday, July 26, 2002 9:08 PM
> To: Turk, Doughan A.
>          Just started to read through your doc. I have
> a question :
> BGP is an application from the perspective of TCP. Why
> do you see the need for provding such security at the 
> application level than
> TCP ? Do you think the security features in TCP as inadequate 
> ? It would be
> really a good idea to provide security at the underlying 
> layers than at this
> layer. 
> 
> sri
> 
> --- "Turk, Doughan A." <[email-masked]> wrote:
> > Benjamin,
> >  
> > interface since a customer is in my reach and can be contacted 
> > immediately in case of an attack initiated by him. Another place
> > to apply it on is at
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - Feel better, live better
> http://health.yahoo.com
> 
>

---

From: "Turk, Doughan A." <[email-masked]>
Date: Tue, 30 Jul 2002 17:05:15 -0400

Jeff, comments inline

> suggested to me to have the draft worked on under this group.

Although this is BGP, this seems more of something along the lines of
operations.  But I'm not going to debate that strongly.

*** As far as I know this technique could not be done using other routing
protocols. It is totally related to BGP ***

> I appreciate
> classified as an operational one. It is an enhancement of a technique 
> that already exists but relying more on BGP as a protocol to help in 
> network security issues.

Did I see this as a presentation at a NANOG, or was that a UU-Net/Worldcom
presentation?  This sounds very familiar.

*** As explained in the draft, this is an enhancement to a technique which
in this case is something you saw in Nanog. The new technique builds on the
existing one. The technique adds a way to pull traffic into a tunnel, please
refer to the draft for more information.***

In any case, the technique seems to be pretty solid.  My biggest
observations about the draft:

1. Your sink addresses are always mentioned as RFC 1918.  Sure, you can do
this, but why not some prefix within your own network? 2. A little more talk
about filtering the internal control communities at the edges may be
warranted in the security considerations section.

*** In an ISP environment you would most likely see RFC 1918 routes
statically sent to a null interface on many routers especially edge routers.
On a Juniper box I believe this is the default behavior and you need not to
add any static routes. Therefore riding on the back on an existing common
practice make sense. 

Thanks for the comments
DT

---

From: "Turk, Doughan A." <[email-masked]>
Date: Tue, 30 Jul 2002 17:17:19 -0400

Andrew,

1) Abuse is not a possibility. While this technique adds no more risk to the
one you get from a fat finger. In the route map match statements you would
add a match for AS-path ^$ this will guarantee that no eBGP peer can
compromise your set up. If you are worried about some one in operations to
miss use it, then the technique adds no more risk.

2) We need a route that is statically sent to a null interface on your edge
routers, You can surely your any of your public IP space is they are of
abandons but logic says RFC 1918 should not be routed out side of your AS
and therefore many ISPs have already in place a set of static routes to drop
those routes. Again, Juniper does that be default in what they call Martian
I believe. ** Juniper folks, correct me if I'm wrong**

3) I'm using routing to effectively acts as an basic ACL to drop traffic. I
can't comment on whether or not this should be on this WG.

Thanks for your comments
DT

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]

Sent: Tuesday, July 30, 2002 1:20 PM
To: Turk, Doughan A.
Cc: [email-masked]
Subject: Re: Need your opinion of this.

Hi Doughan,

Going through the draft, a couple of thoughts came up:

1) Why use BGP communities?  It seems like that just exposes the network to
the possibility of abuse of those communities.  The NOC or Security group
can just log into the router in question, and apply the NH statement.

2) Why use RFC 1918?  One could also use public space.

3) This probably belongs in ops, not routing, but that is an admin detail.

Andrew

On Fri, Jul 26, 2002 at 04:09:19PM -0400, Turk, Doughan A. wrote:
> Delivered-To: [email-masked]
> Delivered-To: [email-masked]
> Delivered-To: [email-masked]
> X-Server-Uuid: b85f21a3-cfd1-11d3-8401-00104bf46ab7
> From: "Turk, Doughan A." <[email-masked]>
> To: [email-masked]
> Cc: "Turk, Doughan A." <[email-masked]>
> Date: Fri, 26 Jul 2002 16:09:19 -0400
> X-Mailer: Internet Mail Service (5.5.2653.19)
> X-WSS-ID: 115F73FE134713-01-01
> Precedence: bulk
> X-OriginalArrivalTime: 26 Jul 2002 20:10:58.0281 (UTC) 
> FILETIME=[8E32D590:01C234E0]
> 
> Folks,
>

---

From: "Turk, Doughan A." <[email-masked]>
Date: Tue, 30 Jul 2002 17:47:46 -0400

Comments inline

-----Original Message-----
From: Abarbanel, Benjamin [mailto:[email-masked]] 
Sent: Monday, July 29, 2002 10:06 AM
To: 'Turk, Doughan A.'; PamSri
Cc: [email-masked]
Subject: RE: Need your opinion of this.

Doughan:

Since some of the traffic that is trapped with the DoS traffic is going to
be redirected to the sinkhole router. would that cause those poor cutomers
to loose thier communications? 
*** Not at all, I'm not tampering with routing tables here***

What if the sinkhole router was smart enough to filter through the good
packets from the bad, could it then redirect the good packets back to their
intended destination? 
*** this is exactly what the draft is all about. Since the BGP community
only triggers a local routing change to the router that has the hooks for
this comm. The traffic slides through an MPLS tunnel for example. After your
smart sinkhole device cleans the traffic, you could have a default statement
on the sinkhole pointing to any interface to connected to your network, even
the same physical interface the tunnel was built on. This will guarantee
that traffic goes back to your customer. Since out side of the edge router
with the community hooks, no change to the legitimate next hop is done, it
is not an issue.***

*** choosing a powerful interface on the sinkhole router is completely your
choice, if you know what are the limits of that interface, you could limit
your ACLs or Policing statement not to compromise the sinkhole router.
Investing in a good sinkhole router can save you money of other parts of
your network.***

*** This is out of the scope of this draft and totally depends on the
circumstance. But to comment on this, I would say what if the attacker is
doing a great job in randomizing his source/ports how can one filter the
traffic. You need to find a distinguishing signature for the attack traffic.
This might or might not be an easy or possible task.***

*** See there are too parts to this draft, one that does exactly what you
are suggesting and this is at the beginning of the draft, and the other take
traffic through a tunnel for further analysis or treatment.***

*** Communities are used in many places and for different reasons, I can't
see a network outage cause by adding an extra comm. value to a prefix.***

Appreciate you input :-)
DT

Ben

> > once that is achieved, your next hop can be a null interface or a 
> > Tunnel interface where the traffic is then pulled to the
> > sinkhole router.
> >  
> > performance line card. The sinkhole router should be powerful enough 
> > to handle whatever filtering or policing you deem
> > required to massage the flow.
> > 
> >  
> > community would have to be done on only one router (sinkhole is a 
> > good idea).
> >  
> Yahoo! Health - Feel better, live better http://health.yahoo.com
> 
>