Subject: [Seamoby] Topic #1: Dos Attack

From: "James Kempf" <[email-masked]>
Date: Mon, 10 Mar 2003 12:00:02 -0800

One objection that was raised to having a server provide the list of authentic
access points is that an MN can launch a DoS attack on the server.

If the router uses a softstate cache, the server load will only occur if the MN
presents a new AP id. Now, it is possible that an MN can attack by making up AP
ids and sending them to the router. A properly provisioned server should be able
to handle that if the attacking MN tries to pose as a legitimate one by
regulating its traffic. The server capacity must be large enough to handle the
routers that are using it. If the MN doesn't regulate traffic and it bombards
the router, the router can selectively drop message packets if the message
volume becomes too large. Thus, service degrades but is not denied, until the
sysadmin finds the offending MN and takes it off the air.

Note that the same problem, an MN bombarding a router with packets, can occur
for dycard as well, so it is not exclusive to the server approach.

What am I missing?

            jak

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

---

From: [email-masked]
Date: Mon, 10 Mar 2003 15:34:18 -0500

Hi James:

See comments below:

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Monday, March 10, 2003 3:00 PM
To: [email-masked]
Subject: [Seamoby] Topic #1: Dos Attack

presents a new AP id. 

Hemant -> Agree.

Now, it is possible that an MN can attack by making up AP
ids and sending them to the router. 

Hemant -> Agree.

A properly provisioned server should be able
to handle that if the attacking MN tries to pose as a legitimate one by
regulating its traffic. 

Hemant -> Are you defining legitimate MN as the one whose authenticity has been asserted to router by AAA during connection phase? I think this is right assumption. But, this MN can launch the above attack too. So, MN can be legitimate, still malicious (or erroneously configured/programmed MN).

 The server capacity must be large enough to handle the
routers that are using it. 

Hemant -> Agree.

If the MN doesn't regulate traffic and it bombards
the router, the router can selectively drop message packets if the message
volume becomes too large. 

Hemant -> We need to describe at least MAY method of how selective dropping is achieved. In IPv6, AR identifies MN with CoA. An MN that disconnects and reconnects gets different CoA. Thus, MN can keep disconnecting and reconnecting each time sending a bunch of bogus L2 IDs.

Thus, service degrades but is not denied, until the
sysadmin finds the offending MN and takes it off the air.

Hemant -> Service degradation is a form of DoS. But, we have to live with that.

Hemant -> I think so.

What am I missing?

            jak

---

From: [email-masked]
Date: Mon, 10 Mar 2003 15:34:18 -0500

Hi James:

See comments below:

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Monday, March 10, 2003 3:00 PM
To: [email-masked]
Subject: [Seamoby] Topic #1: Dos Attack

Hemant -> Agree.

Hemant -> Agree.

Hemant -> Agree.

Hemant -> I think so.

What am I missing?

            jak

---

From: [email-masked]
Date: Mon, 10 Mar 2003 15:38:41 -0500

Hi James, 

one addition to this. Even though the MN can also bombard the router with
messages in the dycard approach, the damage is local. In the server-based 
approach, there is communication happening between router and server, affecting
other network elements. 

Dirk

>From: ext [email-masked] [mailto:[email-masked]]
>Sent: Monday, March 10, 2003 3:34 PM
>To: [email-masked]; [email-masked]
>Subject: RE: [Seamoby] Topic #1: Dos Attack
>
>
>Hi James:
>
>See comments below:
>
>Hemant -> Are you defining legitimate MN as the one whose 
>authenticity has been asserted to router by AAA during 
>connection phase? I think this is right assumption. But, this 
>MN can launch the above attack too. So, MN can be legitimate, 
>still malicious (or erroneously configured/programmed MN).
>
>Hemant -> We need to describe at least MAY method of how 
>selective dropping is achieved. In IPv6, AR identifies MN with 
>CoA. An MN that disconnects and reconnects gets different CoA. 
>Thus, MN can keep disconnecting and reconnecting each time 
>sending a bunch of bogus L2 IDs.
>

---

From: [email-masked]
Date: Mon, 10 Mar 2003 15:53:03 -0500

James,
I think the answers to these questions are there in previous threads. Anyways,
here they are again embedded. I think, the fundamental topic is to be discussed before is
whether we need a server at all.

[anip]

[snip] Not necessarily. A MN could be reporting APs not in the same domain. 
This is not a malicious MN. 

[snip]

[Govind] Even when talking about malicious MNs, I don't think this is so simple, 
unless you track MNs that are making requests as what dycard does. Unless as 
Hemant pointed out, it is quite easy to deceive. 

[Govind] In dycard, cache entries are not created because MNs hear the beacons. In the DT
draft the protocol attempts to create cache entries based on
what a MN hears. This is fundamental problem (?). I therefore don't understand the DoS
attack you are referring to w.r.t to dycard. 

What am I missing?

            jak

---

From: [email-masked]
Date: Mon, 10 Mar 2003 16:24:48 -0500

[Govind] Just a clarification, if you are talking about the increase in processing 
load on the AR to handle APid packets then you are right. This is a problem, not only with dycard but, with any  protocol that sends and receives packets and has the possibility of malicious
nodes. Even to selectively drop packets you need to look at the fields of the packet. 
I was talking about the other additional associated problems brought in by the unique handling
 of APid packets by the DT draft. Sorry if I was not clear in my earlier mail.  
_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: [email-masked]
Date: Tue, 11 Mar 2003 11:56:56 -0500

Hi Jim,
The nAR DOES NOT send PNE messages 
just because the MN reports pARs. Clearly if the MN does report more
than one pAR then it is clearly a malicious MN and it can
be filtered out. Also, all MNs are allowed to send dycard messages 
only after they have been authenticated by the network. 
We use a unique, third party verified identity for the MN and
 the number of entries that can be created per MN
can be restricted. So if the limit for the MNs (set by the network)
 have been reached then there are no PNE messages exchanged for RI messages sent
by that particular MN. All subsequent messages  from the MN are silently discarded.  Could you let me know where you see the DoS attack? 

Thanks,
Govind.

> Sent: Tuesday, March 11, 2003 11:36 AM
> To: Eunsoo Shim; Trossen Dirk (NRC/Boston); Chaskar Hemant 
> (NRC/Boston);
> [email-masked]
> Subject: Re: [Seamoby] Topic #1: Dos Attack
> 
> 
> > I don't understand where there is anything in dycard 
> similar to the server
> > of the server approach.
> > The pAR is not a server where all the ARs in the domain 
> should communicate
> > with.
> > The nAR will send PNE to pAR only when its identity was 
> reported by a MN and
> > the nAR does not have a record about the pAR. Once the nAR 
> recognize the pAR
> > as one of its neighbors, the nAR does not have to send PNE 
> to the pAR even
> > if lots of MNs report about the pAR.
> >
> 
> Suppose MN starts making up pAR addresses and bombarding nAR 
> with them? nAR must
> send PNE messages to resolve, causing a DoS attack on nAR, 
> even though the pAR
> don't exist.
> 
> 
>             jak
>

---

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.