Subject: RE: [Seamoby] Topic #1: Dos Attack

From: [email-masked]
Date: Tue, 11 Mar 2003 15:53:16 -0500

Jim,

> 
> Eunsoo,
> 
> Now, that's not fair. You and Govind are claiming a DoS 
> attack on the DT draft
> because the MN can make up its address. 

[Govind] I can't speak for Eunsoo, but since my name is mentioned
here, I will respond. You have got my intention wrong here.

It can do that with 
> Dycard too.
 
[Govind]  I did not say that dycard is inherently immune to such
DoS attacks and we don't need to take care of it. 
I never said that MNs cannot send in a slew of packets to the AR.
I also agreed that processing load is a concern anywhere. I just pointed
out that we have considered these attacks and are taking (and have taken) steps 
to minimize the effect of these attacks. 

Whether
> the server is involved or not is immaterial. A stream of 
> packets bombarding the
> router will tie up the router regardless.

[Govind] I don't think anyone prevent this, the best we can do is silently
discard packets at the AR. 

> 
> What is to prevent a random MN from making up IP addresses 
> and sending Dycard
> messages to the AR? The router needs to check the 
> authentication, but that
> doesn't happen until the packet is at the router, and 
> meantime, the router is
> tied up in authentication checking.

[Govind] Noone can prevent the MN from doing that. However, the protocol
can control what the router does on receiving the packets. 
Spoofing IP addresses by MNs may not be too difficult to handle for dycard as 
there are additional checks. But I'll think about this. 
Ofcourse, there is processing needed to make these checks before silently 
discarding the packets. 

> 
> My point is that CARD (regardless of the approach) needs to 
> specify rate
> limiting for the MN to AR messages, and that the AR can 
> selectively drop packets
> so that it can limit such an attack.

[Govind] I have no disagreement about this. Rate limiting is needed in both
approaches. The very fact that we say that dycard handles this in some way is
accepting the fact that this is to be handled. 
The only point that is not clear to me, is that once a MN does 
send multiple RI messages it is clearly a malicious MN, and you can
silently discard the packets from this MN after uniquely identifying this MN. 
Hopefully, with the inbuilt checks dycard will be able to identify such MNs. 

However, a MN that supplies multiple APid messages is not necessarily 
a malicious MN. One cannot have control on how many APids spring up in an AR's neighborhood that are not in the same domain.
 Rate-limiting without taking this into consideration may not be the right approach, IMO.

Thanks,
Govind.
_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 19 Mar 2003 16:17:16 -0800

you can also do rate limiting based on the MAC address of the
MN. not too difficult to implement it.

every known protocol suffers from DoS attacks, where there are
numerous requests sent in a very short time. rate limiting is
the only well known mechanism for handling it.

Vijay

ps: a lot of times, the DoS attack through numberous requests
is not significant attack unless it creates some state at the
node receiving the request.

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 19 Mar 2003 16:17:16 -0800

Vijay