Subject: RE: [SeaMoby] Topic #3: Cache contamination

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Sun, 16 Mar 2003 11:40:43 -0600

Eunsoo,
Please find my inline reply. 
Regards,
Ajoy 

-----Original Message-----
From: Eunsoo Shim [mailto:[email-masked]]
Sent: Saturday, March 15, 2003 12:50 PM
To: Singh Ajoy-ASINGH1; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [SeaMoby] Topic #3: Cache contamination

Ajoy,

The role of the server in the server approach is currently storing all L2-L3
mapping entries and providing them at the request by ARs.

AJOY-> This is the subset of CARD function. 

You may say the program of the CARD server can be also running in the AAA
server but two servers are very different in terms of functionality and
involved protocols. 

AJOY-> This is not what I meant. I meant that CARD functionality 
can integrated with AAA server. Given that inter-AR authorization 
is key requirement of CARD, this may be good point to discuss. 

Dycard does not exclude existence of an AAA server at
all.

AJOY-> Are you saying that dycard will use AAA server 
for providing inter-AR authorization? If yes, could 
you please explain us how this will be done.  

I think the security requirements for CARD regarding AR authorization is
quite similar to that of IP routing protocols.  There are already
proposed/implemented solutions for IP routing protocol security.

AJOY-> Not really. The security requirements of CARD should 
be more stringent than inter-domain or intra-domain routing 
protocol. In CARD, any random MN is able to initiate the 
process of L2->L3 mapping as well as capability discovery. 
In dycard the mobile node provides the IP address of the AR 
with which the current AR is required to communicate to obtain 
the L2->L3 mapping as well as capabilities. The dycard MN can 
provide an IP address of a malicious CAR which may be any node 
on the Internet. If somehow the security of AR-CAR is compromised, 
this will cause the current AR to have bogus L2->L3 mapping as 
well invalid capabilities. This will have serious impact on 
the handoff performance of subsequent mobile nodes. The 
routing protocol does not initiate routing table update 
based upon trigger from a random mobile node and am 
not sure how the security requirement of routing 
protocol is comparable with CARD. 

We had a separate thread for the need of the server for CARD. It was being
summarized and so far there was no compelling reason to have a server for
CARD. If you want to propose the server as the AAA server, please can you do
it in that thread?

AJOY-> I have already stated this in my earlier email. The DT
draft also mentions about this. I guess we can discuss this during 
Seamoby presentation. Also, I am very interested to hear from 
other members of WG who are not co-authors of dycard. 

Eunsoo

----- Original Message -----
From: "Singh Ajoy-ASINGH1" <[email-masked]>
To: <[email-masked]>; "Singh Ajoy-ASINGH1" <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Saturday, March 15, 2003 7:08 AM
Subject: RE: [SeaMoby] Topic #3: Cache contamination

> I think the security requirement of CARD is not same
> as that of FMIP. In CARD, the routers have to mutually
> authorize each other for validating and updating
> the L3->L3 mapping and capabilities based upon indication
> from a random MN which will eventually impact the other mobile
> nodes in the long run. Whereas in the fast handoff,
> this only impacts the mobile node in handoff. So, we need to
> better understand how such authorization will work in context of
> CARD especially  dyCard. What are the possible tools available
> for enabling such inter-AR authorization of dyCard ARs? In server based
> approach I do see server (e.g.,AAA) playing such a role.
>
> Regards,
> Ajoy
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, March 14, 2003 6:21 PM
> To: Ajoy Singh; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [SeaMoby] Topic #3: Cache contamination
>
>
> Security of all handoff schemes depends upon existence of inter-AR SA.
BCPs
> should be used for this - take cues from routing, policy framework, FMIP
and
> CT. - Hemant
>
> -----Original Message-----
> From: ext Singh Ajoy-ASINGH1 [mailto:[email-masked]]
> Sent: Friday, March 14, 2003 6:13 PM
> To: 'Robert Chalmers'; Singh Ajoy-ASINGH1
> Cc: 'Eunsoo Shim'; [email-masked]
> Subject: RE: [SeaMoby] Topic #3: Cache contamination
>
>
> -----Original Message-----
> From: Robert Chalmers [mailto:[email-masked]]
> Sent: Friday, March 14, 2003 2:18 PM
> To: Singh Ajoy-ASINGH1
> Cc: 'Eunsoo Shim'; [email-masked]
> Subject: Re: [SeaMoby] Topic #3: Cache contamination
>
>
> Singh Ajoy-ASINGH1 wrote:
>
> <snip>
> > AJOY-> BTW, I have a cache contamination question about dycard. Let us
> > assume that
> > a fake MN has some collaboration with fake router which is
> > also connected to the internet and the fake MN sends
> > a message  to the current AR indicating that fake router
> > is the valid CAR ?  How the dycard assures that it
> > does create an entry in its local cache?
> >
> It is clearly stated in the draft that the two routers must mutually
> authenticate one another with the explicit authorization to perform
> CARD. Are you assuming that this fake AR can in some way authenticate
> and authorize itself with respect to the attacked AR? If not, the
> question is moot. If so, then I would question your
> authentication/authorization scheme.
>
> AJOY-> You have rightly pointed out that security of
> dycard scheme would depend upon how routers authorize and
> authenticate each other. BTW, what is the proposed
> scheme for mutual authentication and authorization?
> Do you believe manual configuration of SA is enough?
>
>
>
>
> --
> /****************************************************************
>
>  Robert Chalmers
>  UCSB Computer Science Doctoral Candidate
>  Network and Multimedia Systems Lab (NMSL)
>
>  "My heart is in the code, but my soul lies in the process"
>
>  | [email-masked] || http://www.cs.ucsb.edu/~robertc/ |
>
> *****************************************************************/
> _______________________________________________
> 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: "Eunsoo Shim" <[email-masked]>
Date: Sun, 16 Mar 2003 14:33:03 -0800

Ajoy,

My comments are inline.

> AJOY-> This is the subset of CARD function.
[eunsoo] CARD does not require all L2-L3 mapping entries in a central
server. Such a central server is what DT proposed and we had discussion
about why we need a server for CARD. There was no compelling reason yet.

> is key requirement of CARD, this may be good point to discuss.
[eunsoo] Unless there is a compelling reason to have a central server for
CARD, it does not matter where we can put the server.

> you please explain us how this will be done.
[eunsoo] I think Dycard can be integrated with many ways of inter-AR
authorization. The current Dycard draft does not propose any specific method
yet.

> protocol is comparable with CARD.
[eunsoo]
No matter what triggers the inter-AR authorization process, still it is two
ARs who are involved and responsible for checking authorization of each
other. MN cannot have influence on it. So it is not correct to say CARD has
more strict security requirements regarding inter-AR authorization because
MN provides the trigger.
You cannot say corruption of the IP routing tables in the routers are less
serious than the curruption of the cache (CAR table) of the edge ARs.

Also now you are say bogus L2-L3 mapping entries can cause serious
consequences. I pointed out repeatedly that the server approach cannot
prevent MN from providing a L2 address of an AP which is a GAAP and thus the
cache (the CAR table at the AR) will be contaminated. What do you think of
the seriousness of this problem?

> other members of WG who are not co-authors of dycard.

[eunsoo] If we want to use an AAA server for inter-AR authorization, what we
need is a AAA server but not a server that stores all the L2-L3 mapping
entries statically and provide them at the request of the ARs.

Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Sun, 16 Mar 2003 14:33:03 -0800

Ajoy,

My comments are inline.

[eunsoo]

Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Sun, 16 Mar 2003 14:39:12 -0800

> other members of WG who are not co-authors of dycard.

I am also very interested to hear from other members of WG about the DT
proposal who are not members of the DT and are not affiliated to them.
There were many issues raised about the DT proposal such as cache
contamination and even the fundamental need of the central server.
I have not heard convincing explanations from the DT members as well as any
supporting opinion from non-DT members yet.
I'd appreciate if anyone provides one.

Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Sun, 16 Mar 2003 14:39:12 -0800

Eunsoo