Subject: RE: [Ieprep] Understanding Congestion

From: "Barry Raveendran Greene" <[email-masked]>
Date: Wed, 18 Dec 2002 07:34:18 -0800

Looks like people need to come up to speed on the realities of uRPF,
Remote Triggered Black Hole Filtering, Sink Holes, and a bunch of other
techniques we're using today.

An - your understanding of uRPF is the FUD understanding - not the
reality. I'm working on an new "uRPF Deployment Experience" whitepaper.
But until then, check out the ISP Security tutorial at:

	ftp://ftp-eng.cisco.com/cons/isp/security/

Barry

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Nguyen, An
> Sent: Wednesday, December 18, 2002 7:23 AM
> To: 'Bill Woodcock'; King, Kimberly S.
> Cc: [email-masked]'
> Subject: RE: [Ieprep] Understanding Congestion
> 
> Bill,
> 
> >-----Original Message-----
> >From: Bill Woodcock [mailto:[email-masked]]
> >Sent: Tuesday, December 17, 2002 4:21 PM
> >To: King, Kimberly S.
> >Cc: [email-masked]'
> >Subject: RE: [Ieprep] Understanding Congestion
> >
> >
> >      On Tue, 17 Dec 2002, King, Kimberly  S. wrote:
> >    > prohibiting denial of service attacks that
> >    > are based on forged source addresses and doing it in a
> >    > scaleable accurate way against address aggregates
> >    > is a different problem than congestion management of
> >    > individual flows or user sessions.
> >
> >Right...  The combination of uRPF, backscatter, and iBGP is used to
sink
> >traffic to a destination /32, regardless of source address.
> >
> 
> My understanding of Unicast Reverse Path Forwarding is that uRPF
provides
> a
> way to do a trace back to make sure the source address is not spoofed
> according to ACL's and route map's. This tool is only good for DoS,
not
> Distributed DoS in my opinion. It has some drawbacks, though:  1. It
does
> not work well on interfaces internal to the network because of its
routing
> asymmetry; and 2. It does not work well on multihomed environments.
> 
> By the way, sinking too much traffic would cause a DoS as well because
you
> spend so much CPU resource on discarding suspicious packets instead of
> forwarding packets.
> 
> I have a question for you: if we have a DDoS of a magnitude , for the
lack
> of better word, of (NIMDA + CODE RED)^n, where n is a large number,
would
> the currently configured IP backbone be ready to withstand it?
> 
> An
> 
> _______________________________________________
> Ieprep mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ieprep
> _______________________________________________
> Ieprep mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ieprep

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: "Nguyen, An" <[email-masked]>
Date: Wed, 18 Dec 2002 10:23:24 -0500

Bill,

>Right...  The combination of uRPF, backscatter, and iBGP is used to sink

My understanding of Unicast Reverse Path Forwarding is that uRPF provides a
way to do a trace back to make sure the source address is not spoofed
according to ACL's and route map's. This tool is only good for DoS, not
Distributed DoS in my opinion. It has some drawbacks, though:  1. It does
not work well on interfaces internal to the network because of its routing
asymmetry; and 2. It does not work well on multihomed environments.

By the way, sinking too much traffic would cause a DoS as well because you
spend so much CPU resource on discarding suspicious packets instead of
forwarding packets.  

I have a question for you: if we have a DDoS of a magnitude , for the lack
of better word, of (NIMDA + CODE RED)^n, where n is a large number, would
the currently configured IP backbone be ready to withstand it?

An

---

From: Bill Woodcock <[email-masked]>
Date: Wed, 18 Dec 2002 08:50:29 -0800 (PST)

On Wed, 18 Dec 2002, Nguyen, An wrote:
    > according to ACL's and route map's.

No, sorry, please either RTFM or pay attention to people's postings.

                                -Bill

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 18 Dec 2002 13:54:28 -0500

On Wednesday, Dec 18, 2002, at 10:23 America/Montreal, Nguyen, An wrote:
> provides a

uRPF only addresses one issue:		Forged Source IP addresses

uRPF does not help with a DoS attack if the attacker is using a 
legitimate
source IP address (or one that is forged, but forged to a valid host IP 
on a
subnet behind the first point that checking of the source address 
happens).

uRPF does not help with a DDoS attack if the attacker is using 
legitimate
source IP addresses (or forged addresses that are forged to a valid 
host IP
on a subnet behind the first point that checking of the source address 
happens).

On any broadcast shared link media using ARP (e.g. Ethernet), it is 
possible
for one host to "steal" another host's IP address -- because ARP is not
authenticated.  IPv6 ND can be authenticated with AH, but the key 
management
is a nightmare to deploy (as with most forms of key management), so 
IPv6 ND
authentication is rarely enabled.

On many CPU-based routers, turning on uRPF features causes the 
forwarding
performance to drop below line rate, so not all operators enable this 
feature;
even operators who do deploy this feature often do so very selectively,
rather than all over the place.

uRPF also assumes that the local understanding of the BGP topology is 
correct,
legitimate, and that other ASs are only advertising prefixes that they 
are
authorised to advertise.  Right now, there is no way to authenticate 
any of
that.  (This is also one of the reasons that S-BGP is not actually 
deployable
right now, btw.)

> spend so much CPU resource on discarding suspicious packets instead of

True only if the router uses CPU for discarding packets.  Many routers
(e.g. ours and some of our competitors') implement packet filtering in
an ASIC.  This means that ACLs are free and have zero adverse impact on
the system behaviour.  The tradeoff with an ASIC is that one can't add
new features as quickly as one can add them in software.  If a product
has all the features one needs implemented in dedicated hardware (e.g. 
ASIC),
the product will generally be a better choice than products that don't 
have
such dedicated hardware support.

> the currently configured IP backbone be ready to withstand it?

The correctly configured hardware-based core routers had a relatively 
easy time
handling past DDOS attacks.  Correctly configured CPU-based core 
routers had a
a very difficult time handling past DDOS attacks.

Clever operators experimentally verify router behaviour under a wide 
range
of operating conditions (including adverse conditions) before buying 
routers.

Ran
[email-masked]