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

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.

> -----Original Message-----
> From: ext James Kempf [mailto:[email-masked]]
> 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
> 
> _______________________________________________
> Seamoby mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/seamoby
> 
_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: "James Kempf" <[email-masked]>
Date: Tue, 11 Mar 2003 09:27:32 -0800

Suppose MN starts making up its own IP address too.

            jak

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Tuesday, March 11, 2003 8:56 AM
Subject: RE: [Seamoby] Topic #1: Dos Attack

> by that particular MN. All subsequent messages  from the MN are silently
discarded.  Could you let me know where you see the DoS attack?

---

From: "James Kempf" <[email-masked]>
Date: Tue, 11 Mar 2003 09:27:32 -0800

jak

---

From: "Eunsoo Shim" <[email-masked]>
Date: Tue, 11 Mar 2003 13:45:23 -0800

> Suppose MN starts making up its own IP address too.

[eunsoo] First, MN is allowed to send a report per handoff, that is, it is
allowed only one report after it arrived to the nAR because there is only
one pAR. Also MN should be authenticated to participate in the discovery
process in Dycard. Let's say we assume MN can disguise itself with a new IP
address. How often could MN do it going through binding expiration or
revokation and reauthentication? It would be rarely possible for a MN to do
DoS attack on Dycard that way.

Eunsoo

> >  have been reached then there are no PNE messages exchanged for RI
messages
> sent

---

From: "Eunsoo Shim" <[email-masked]>
Date: Tue, 11 Mar 2003 13:45:23 -0800

Eunsoo

messages

---

From: "Eunsoo Shim" <[email-masked]>
Date: Tue, 11 Mar 2003 14:15:30 -0800

> DoS attack on Dycard that way.
[eunsoo] The above statement is for MIPv4. If MIPv6 runs, AR does not get
binding request from MN. In the case, we need to put limit on the number of
reports from MN. Since we expect one report per handoff, we can put very
strict limit such as 1 report per 10 seconds. I explained the difference
between Dycard and the server approach in a previous email about this.

Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Tue, 11 Mar 2003 14:15:30 -0800

Eunsoo

---

From: "James Kempf" <[email-masked]>
Date: Tue, 11 Mar 2003 11:57:29 -0800

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. It can do that with Dycard too. Whether
the server is involved or not is immaterial. A stream of packets bombarding the
router will tie up the router regardless.

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.

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.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 11 Mar 2003 11:57:29 -0800

Eunsoo,

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 11 Mar 2003 12:00:43 -0800

Ok.

I think the protocol needs a limit in any event. In MIPv4, the MN could as well
bombard the FA.

            jak

----- Original Message -----
From: "Eunsoo Shim" <[email-masked]>
To: "Eunsoo Shim" <[email-masked]>; "James Kempf"
<[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, March 11, 2003 2:15 PM
Subject: Re: [Seamoby] Topic #1: Dos Attack

---

From: "James Kempf" <[email-masked]>
Date: Tue, 11 Mar 2003 12:00:43 -0800

Ok.

            jak

---

From: "Eunsoo Shim" <[email-masked]>
Date: Tue, 11 Mar 2003 15:36:58 -0800

> router will tie up the router regardless.
[eunsoo] I did say that we could not prevent MN from sending lots of
messages to AR. It is the same for any kind of signaling protocol. The
question is how the AR can handle them and what's the impact on AR. The
difference between Dycard and the server approach is that the impact stops
at the receiving AR for Dycard and the impact goes up to the central server
and thus the whole network is affected in the server approach.

> tied up in authentication checking.
[eunsoo] Sure. What I was talking about was that there would be no
overwhelming messages from nAR to pAR because of lots of reports from MN in
Dycard. All the attacking traffic is filtered out by the receiving AR.

> so that it can limit such an attack.

[eunsoo] In Dycard, it is necessary for MIPv6. Binding history check-up can
replace such rate limiting for MIPv4 in Dycard. In the server approach, it
is always necessary.

Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Tue, 11 Mar 2003 15:36:58 -0800

Eunsoo