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

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Sun, 16 Mar 2003 13:52:36 -0600

Eunsoo,
Please find my inline reply. 
Regards,
Ajoy 

-----Original Message-----
From: Eunsoo Shim [mailto:[email-masked]]
Sent: Sunday, March 16, 2003 4:33 PM
To: Singh Ajoy-ASINGH1; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [SeaMoby] Topic #3: Cache contamination

Ajoy,

My comments are inline.

>
> 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.
>
[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.

> 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.
>
[eunsoo] Unless there is a compelling reason to have a central server for
CARD, it does not matter where we can put the server.

AJOY-> I am not talking about introducing any additional server though. 
I am just talking about re-using the existing server functionality 
in an access network. 

> 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.
>
[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.

AJOY-> List few inter-AR authorization protocols that can be used. 
You have not answered my question yet. 

> 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.
>
[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. 

AJOY-> The current AR believes the information provided by MN 
and acts upon that. So, I am not sure why you say that MN 
does not have any influence over it.  

So it is not correct to say CARD has
more strict security requirements regarding inter-AR authorization because
MN provides the trigger.

AJOY-> Why not? 

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?

AJOY-> I do not agree with this statement. Let us discuss scope-id 
approach offline or doing IETF presentation. I have already indicated 
this in my earlier email to Dirk. 

> 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] 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.

AJOY-> If we need AAA sever then why not discuss about piggybacking 
some additional function required by the CARD over it. I do not 
see any reason to make CARD complicated protocol as being proposed
in dycard. 

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

---

From: "Eunsoo Shim" <[email-masked]>
Date: Sun, 16 Mar 2003 15:10:44 -0800

Ajoy,

My comments are inline.

> You have not answered my question yet.

[eunsoo] A very simple solution is using shared secret key for intra-domain
authorization check. This is just one example.

> does not have any influence over it.
[eunsoo] The current AR does not believe the information provided by MN as
it is. It takes the information as an input and verifies it. It is the
difference between the server approach and Dycard. The server approach does
not verify it. It really believes it. But in Dycard, the previous AR and the
current AR cooperate to verify the information. Once the information is
given to the MN, MN is not involved in the verification process at all. Of
course, MN is not involed in the inter-AR authorization process at all
either.

> more strict security requirements regarding inter-AR authorization because
[eunsoo] My comment in the above explains this.

> this in my earlier email to Dirk.
[eunsoo] Not everyone can attend the meeting. As far as I understand, the
mailing list is the primary tool of discussion for the IETF. So I expect
online discussion is not stopped.
Also I repeatedly asked how the server approach can prevent cache
contamination. No one answered it yet. If you are planning to answer it in
the IETF meeting, I'd appreciate your answering it also in the mailing list.

> see any reason to make CARD complicated protocol as being proposed

[eunsoo] Again, it should be presented first why we need a server for CARD.

Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Sun, 16 Mar 2003 15:10:44 -0800

Ajoy,

My comments are inline.

Eunsoo

---

From: "James Kempf" <[email-masked]>
Date: Sun, 16 Mar 2003 20:04:27 -0800

Ajoy,

> You have not answered my question yet. 

This could be IPsec AH with ISAKMP/IKE to set up the key distribution. 

        jak

---

From: "James Kempf" <[email-masked]>
Date: Sun, 16 Mar 2003 20:04:27 -0800

Ajoy,

        jak