Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt

From: [email-masked]
Date: Thu, 6 Mar 2003 18:15:55 -0500

Hi Guys:

Some clarification on possibility of DoS in current DT draft. The following DoS attacks are possible in the current protocol:

+ MN sending bogus L2 ids to current AR. This in turn means that current AR makes request to CARD server to resolve it. Server returns error condition (no such mapping or mapping out of scope ID).

+ Limiting requests per MN is not possible to avoid the above. MN may keep disconnecting and connecting back frequently, each time sending a set of bogus L2 IDs. In each reconnection, MN may acquire a different CoA, and hence, current AR cannot keep track of which MN is sending how many L2 IDs over a period of time.

+ Scope ID is simple mechanism to limit cache contamination from domain scale to region scale. However, it is easily possible that malicious node would make the cache at current AR always filled up will all ARs in scope ID.

+ If additional mechanisms are introduced such as tagging cache entries with MN identifier (as asserted by AAA when access was granted), DoS can be managed however. Then scope ID wont be necessary, IMHO. 

Hemant

-----Original Message-----
From: ext [email-masked]
[mailto:[email-masked]]
Sent: Thursday, March 06, 2003 3:01 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt

Jim,

Please read what I wrote again.

"Should not propagate *from* the MN *to* the server." Please point out to me
where in the draft it says that. Fetching *from* the server is the other way
around.

[Govind] The MN sends an L2 id. It is not there in the cache.
Note the AR has no way of determining whether this is a genuine AP.
If the entry to the AP is not in the cache it is sent over to the server.
 Server responds with the mapping or probably a error
based. Doesn't the MN have direct control of what goes to the server?
Thats what I meant. Hope it is clear now. This is what I understood. The DT
draft has acknowledged that this is a problem and proposes the scope-id as
one solution for this. Look at section 6.2.

-Govind.
_______________________________________________
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: Thu, 6 Mar 2003 16:33:31 -0800

> Some clarification on possibility of DoS in current DT draft. The following
DoS attacks are possible in the current protocol:
>
> + MN sending bogus L2 ids to current AR. This in turn means that current AR
makes request to CARD server to resolve it. Server returns error condition (no
such mapping or mapping out of scope ID).
>
> + Limiting requests per MN is not possible to avoid the above. MN may keep
disconnecting and connecting back frequently, each time sending a set of bogus
L2 IDs. In each reconnection, MN may acquire a different CoA, and hence, current
AR cannot keep track of which MN is sending how many L2 IDs over a period of
time.

Rate limiting isn't done on any particular MN, it is done on *all* CARD
requests. If the default limits defined in the protocol are gone over, the
router starts dropping CARD requests, regardless of what IP address they have on
them. Service begins to degrade, but it is not denied.

Meanwhile, legitimate users begin to notice, get a sysadmin, and find the
villian.

> + Scope ID is simple mechanism to limit cache contamination from domain scale
to region scale. However, it is easily possible that malicious node would make
the cache at current AR always filled up will all ARs in scope ID.

So?

> + If additional mechanisms are introduced such as tagging cache entries with
MN identifier (as asserted by AAA when access was granted), DoS can be managed
however. Then scope ID wont be necessary, IMHO.

Why should the router care where the information came from? Regardless, it will
check against the database. Otherwise, anybody could advertise an AP.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 6 Mar 2003 16:33:31 -0800

So?

            jak

---

From: "Eunsoo Shim" <[email-masked]>
Date: Fri, 7 Mar 2003 07:12:08 -0800

James,

My comments are inline.

----- Original Message -----
From: "James Kempf" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, March 06, 2003 4:33 PM
Subject: Re: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt

> them. Service begins to degrade, but it is not denied.

[eunsoo] If the server cannot answer all CARD requests after the limit, the
whole network is affected by that. Why do we want this while there is an
alternative?

> Meanwhile, legitimate users begin to notice, get a sysadmin, and find the
[eunsoo] This should be the last resort. We should prevent or minimize this
kind of situation from the protocol design stage. Dycard has an advantag
regarding this.

> the cache at current AR always filled up will all ARs in scope ID.
[eunsoo] I gave you an example of the negative impact of this situation in
the past. In short, it means the cache is not useful for most of other CARD
applications except L2-L3 mapping.

Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Fri, 7 Mar 2003 07:12:08 -0800

James,

My comments are inline.

----- Original Message -----
From: "James Kempf" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, March 06, 2003 4:33 PM
Subject: Re: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt

Eunsoo

---

From: "James Kempf" <[email-masked]>
Date: Fri, 7 Mar 2003 08:53:48 -0800

> kind of situation from the protocol design stage. Dycard has an advantag

If you mean dycard, I don't see the alternative as any better. An MN can still
bombard the router with requests.

> applications except L2-L3 mapping.

You've missed my point.

If the cache is large enough to hold all the entries in the domain, what does it
matter if  all the entries in the domain are in the cache?

            jak

---

From: "James Kempf" <[email-masked]>
Date: Fri, 7 Mar 2003 08:53:48 -0800

You've missed my point.

            jak

---

From: "Eunsoo Shim" <[email-masked]>
Date: Fri, 7 Mar 2003 12:09:39 -0800

James,

My comments are inline.

----- Original Message -----
From: "James Kempf" <[email-masked]>
To: "Eunsoo Shim" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, March 07, 2003 8:53 AM
Subject: Re: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt

> bombard the router with requests.
[eunsoo] You should distinguish two things: cache contamination and DoS
attack.
Cache contamination is a problem that should be prevented with our best. The
problem of the server approach is that it opens a wide door for easy cache
contamination.

DoS attack: In any protocol, a client can send lots of request to a server.
In our case, a client can send lots of L2-L3 mapping inquires. You cannot
prevent MN from sending inquiries unless you can shutdown MN remotely. So
what is the difference? The server approach makes the situation worse by
affecting the cental server. That is, a malicious attack can affect the
whole network. In Dycard case, the attacker can only affect the current AR.
So the impact is local. Also look-up of local memory is much smaller job
than doing the same thing and then generating and sending an inquiry message
to the CARD server. So the attacker should have much more capability to do
DoS attack on Dycard than the server approach.

> > > > + Scope ID is simple mechanism to limit cache contamination from
domain
> > scale
> > > to region scale. However, it is easily possible that malicious node
would
> > make

[eunsoo] It seems to me that you are considering L2-L3 mapping as the only
application of CARD. Please recheck the issue draft which describes various
applications of CARD. If the cache is filled with lots of false entries, all
those applications won't be possible except L2-L3 mapping.

I don't think you are really proposing such a large cache size. Anyway, now
we have to add also capability information of each AP or AR to each entry.
So how much memory do you want to allocate at each AR for the entries? And
why do we want to do this when there is an alternative?

Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Fri, 7 Mar 2003 12:09:39 -0800

James,

My comments are inline.

----- Original Message -----
From: "James Kempf" <[email-masked]>
To: "Eunsoo Shim" <[email-masked]>; <[email-masked]>;

domain
would

Eunsoo