Subject: RE: Should SEND deal with Remote ND DoS attack ?

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 3 Dec 2002 10:13:15 -0800

> 
> > (unless it's being abused by an application attempting
> > to send packets to arbitrary on-link destinations)
> 
> Bingo.  And in many cases I suspect it's very easy to trigger 
> that sort of thing.
> 
I am not sure whether there is an easy fix to this problem or not
without affecting the normal behavior. Are you saying that SEND
should care about this or not ?

-mohan

> 				  - Bill
> --------------------------------------------------------------------
> To unsubscribe from this list, send email with "UNSUBSCRIBE" 
> in the body to <[email-masked]>.
> Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
> --------------------------------------------------------------------
> 
--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 4 Dec 2002 10:10:56 -0800

> 
> 
> I added the following pieces of text to the draft:
> 
>     In a way, this problem is fairly similar to the TCP SYN flooding
>     problem.  Rate limitating Neighbor Solicitations, restricting the
>     amount of state reserved for unresolved soliciations, and clever
>     cache management should be applied.
> 
There are implementations that already implement a destination cache
(includes
off-link and on-link as described in rfc2461) which already has some
techniques
to limit such DoS attacks. So, extending this to neighbor cache should
not
be that difficult. I am assuming that the above text indicates that no
other special solution will be developed by SEND WG and the above is
sufficient.

>     It should be noted that both hosts and routers need to worry about
>     this problem.  The router case was discussed above.  
> Hosts are also
>     vulnerable since the neighbor discovery process can potentially be
>     abused by an application that is tricked into sending packets to
>     arbitrary on-link destinations.
> 
> Satisfied?
> 
Sounds good to me.

> -----
> 
> Now back to the process question:
> 
>    1. Should SEND address this or should we kick this back to IPV6?
> 
SEND.

>    2. If SEND should address this, should it be addressed
>         a) in the psreq draft, and eventually in the
>            Informational RFC that results,

This would be sufficient.

>         b) in a separate Standards track draft/RFC?
>         c) somewhere else?
> 

> --Pekka Nikander
-mohan