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

From: [email-masked]
Date: Thu, 6 Mar 2003 14:02:41 -0500

Hi James,

>> In the context of the DT document, a possible DoS attack does not
>> even consider attacks from outside of the domain directed towards the
>> server as such, but inherently through the protocol 
>operation involving the
>> server. Namely, a malicious MN is contaminating the cache 
>entries of the AP
>> through falsified L2-L3 mapping requests, i.e., through the 
>cache population
>> mechanism that is the basis of the server approach. 
>Firewalls won't help here!
>>
>
>The AR should *never* propagate any MN supplied information 
>back to the server.

If the (MN-)requested L2-L3 mapping does not exist in the AR cache, 
a request is sent to the server to obtain this information (maybe I missed
something in the draft). If the MN does the request for all n ARs in the scope, 
the cache will soon be filled up with all possible ARs in the scope region. But even
more, the MN can also explicitly request L2-L3 mappings of ARs that are not within the region 
(the AR does not know about the region, and it does not know whether or not the supplied 
information is correct, so it has to ask the server). The mapping is requested from the server 
by the AR, the server rejects the request (reason "out of scope region"). Result of this would be
server and AR load, i.e., DoS attack.

Another thought: Since eventually, the AR might get the L2-L3 mappings of all scope region ARs anyway 
(assuming such malicious MN above), why don't we simply push the L2-L3 mappings right from the beginning 
to the AR instead of requesting it on time???? This would bring us very close to a static configuration 
approach though.

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

---

From: "James Kempf" <[email-masked]>
Date: Thu, 6 Mar 2003 11:48:08 -0800

Hi Dirk,

> server and AR load, i.e., DoS attack.

Where's the denial of service? All you've described above is how the router
cache gets populated by all the APs in the region. Properly sizing the router
cache is required, of course.

thought: Since eventually, the AR might get the L2-L3 mappings of all scope
region ARs anyway
> to the AR instead of requesting it on time???? This would bring us very close
to a static configuration

It is static as far as the router is concerned, but not as far as the MN is
concerned. The MN can still dynamically do the CARD. Frankly, I think this might
be necessary anyway to avoid the startup transient.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 6 Mar 2003 11:48:08 -0800

Hi Dirk,

            jak