Subject: [Ieprep] Ieprep - Looking for a colleague...

From: "Anzivino, Anthony" <[email-masked]>
Date: Wed, 18 Dec 2002 15:29:58 -0500

Has anyone seen Dennis Berg, Perry Fergus, or Gabor Luka on this forum?
Just when you think you're done with GETS, it comes back in another
instantiation...

Sorry for the disruption....

Tony (x-telcordia GETS PM 1990s)
Anthony (Tony) Anzivino, PMP 
Professional Services - Program Manager 
Sonus Networks 
978-204-9156 (cell) 978-589-8654 (office)
Yahoo IM "anthony_anzivino"                     [email-masked] 

-----Original Message-----
From: RJ Atkinson [mailto:[email-masked]]
Sent: Wednesday, December 18, 2002 1:54 PM
To: Nguyen, An
Cc: [email-masked]'
Subject: Re: [Ieprep] Understanding Congestion

On Wednesday, Dec 18, 2002, at 10:23 America/Montreal, Nguyen, An wrote:
> 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.

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.)

> 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.

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.

> 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?

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]

_______________________________________________
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: "Anzivino, Anthony" <[email-masked]>
Date: Thu, 19 Dec 2002 07:16:51 -0500

Thanks everyone....

found all three thanks to you....

Cheers, Tony

-----Original Message-----
From: Cochran, Shawn P [mailto:[email-masked]]
Sent: Wednesday, December 18, 2002 9:17 PM
To: Anzivino, Anthony
Subject: RE: [Ieprep] Ieprep - Looking for a colleague...

I think Gabor left the NCS about a year ago. May be wrong.

-----Original Message-----
From: RJ Atkinson [mailto:[email-masked]]
Sent: Wednesday, December 18, 2002 1:54 PM
To: Nguyen, An
Cc: [email-masked]'
Subject: Re: [Ieprep] Understanding Congestion

Ran
[email-masked]

*****
"The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential, proprietary, and/or
privileged material. Any review, retransmission, dissemination or other use
of, or taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from all
computers."
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep