Subject: [SeaMoby] Topic #3: Cache contamination

From: "Eunsoo Shim" <[email-masked]>
Date: Wed, 12 Mar 2003 13:08:00 -0800

Hi,

Since we don't have much time until the IETF meeting next week, I think it
would be better to check important points in the mailing list before
off-line discussion for a short time during the meeting.
As always pointed out, security is a big concern.
It was pointed out there was no way to prevent cache contamination in the
server approach. Scope-ID was claimed as a solution but it was not really
explained in my understanding.
I look forward to an explanation of how cache contamination can be prevented
in the server approach.
Regards,

Eunsoo

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

---

From: [email-masked]
Date: Thu, 13 Mar 2003 16:59:45 -0500

Bogus entries in cache also means that AR indulges in inter-AR capability and update exchange with bogus ARs, and hence, it has bearing on router processing overhead. I do not know if this matters a lot as there are no numbers available on frequency and size of those capability updates. - Hemant

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Thursday, March 13, 2003 4:47 PM
To: Eunsoo Shim; [email-masked]
Subject: Re: [SeaMoby] Topic #3: Cache contamination

Cache contamination is only an issue if it results in an MN getting a wrong
mapping, where a wrong mapping means that the MN presents the AR with an AP
address for an AP that it is hearing, and it gets back an presumptive AR address
that is not a GAAR (Geographically Adjacent AR) or that is not a valid AR. If a
legitimate MN always presents an AP address that it is hearing, then the AP is a
GAAP (Geographically Adjacent AP). If the source of the mapping information
(either interrouter ala dycard or backend database ala DT draft) always returns
a correct AP to AR mapping, then the MN cannot possibly get a mapping back for a
router that is not a GAAR or a valid AR.

The issue of nonGAAR mappings consuming cache space can be handled by aging out
cache entries. If the probability that a cache entry is dropped depends on the
number of MNs that report the AP, then attacks will be quickly flushed. For
example, suppose that the probability that a cache entry gets dropped at time T
is equal to 1/n, where n is the number of MNs reporting the AP at time T-1. Then
if a single MN mounts an attack, its bogus cache entry is flushed every time.
Thus, the cache need only be sized slightly large than the expected number of
GAAP to GAAR entries.

In short, a properly specified cache timeout algorithm, together with an
authoritative source of AP to AR mappings should handle it.

            jak

---

From: [email-masked]
Date: Thu, 13 Mar 2003 18:43:38 -0500

> I'm not sure I understand the attack.
> 
> If an attacker sends a completely bogus AP, the AR compares 
> against the AAPL
> (Authorized AP List) and rejects. 
> If an attacker sends an AP that is not bogus but is not a 
> GAAP, then it will
> pass the AAPL test but it will remain in the cache for one 
> iteration and be
> flushed aftewards.
[Govind] This is assuming a particular cache replacement policy and assumes
the server approach. I think we should first settle whether the server is needed
or not before coming to cache contamination and other cache related issues. 
However, if we are not going to do that, then we should propose how any
scheme involving protecting the cache works in either of the proposed solutions.
> 
> So, I don't see how interrouter capability and update 
> exchange are affected.
[Govind]  First thoughts about this cache replacement policy. I will think about this replacement
policy more later.. Its been a long day already, so sorry if I'm wrong :)

If the number of malicious MNs increase, then wouldn't you have an increase of the number
of entries? Also, they might not be removed from the cache. More such entries and more
the unnecessary capability messages. Note, if we are using the server scheme, each MN has
the possibility of reporting a large number of such non-GAAPs. Consider this scenario,
10 malicious MNs each report say 100 genuine non-GAAPs. Also assume that
each AP is assigned to a different AR. Further assume that
you have a limit of 100 reports per MN.  In your scheme, the chance
of it being not removed is (1-1/10)  = 0.9. There is a 90% chance that 100 cache entries of
non GAARs are in the cache after each flush. So the current AR will communicate
unnecessarily with 100 non CARs. Depending on the size and frequency of capabilities
exchanged you do have an unnecessary burden on the ARs. You will never be able
to detect this and yet keep exchanging messages between non-CARs.

Another point, by flipping a coin as you suggest
based on the number of MNs reporting, and removing the cache entry, you have a non-zero probability
of (1 - 1/ n_{good MNs} ) that the cache entry is removed. This policy therefore has the chance that you
keep relying on the server, thus increasing the average response time. 
Instead with a better scheme to reduce the possibility of incorrect cache entries along with lifetimes
 to remove bad entries may be a better approach. I'm not saying that this is a bad
cache replacement scheme yet but I'll think about this tomorrow.

-Govind.

---

From: [email-masked]
Date: Fri, 14 Mar 2003 10:19:21 -0500

James,

[snip]
> Why do you say it assumes the server approach? The AAPL could 
> be programmed into
> the router through a Web page. It doesn't have to come from a 
> server. Something
> like the AAPL will even be needed in Dycard, else how does a 
> router know that an
> access point connected to it is authorized?
> 
[Govind] This is because the cache population schemes are different in the schemes. Therefore,
the effectiveness of any cache contamination scheme is different.

[snip]
> Right, the assumption here is that the probability of an 
> attack decreases
> according to the number of MNs involved. Remember, for an MN 
> to even get on the
> link, it must be auth/authz-ed. So, multiple MNs means a 
> bunch of the operator's
> authorized customers decided to get together and attack. 
> Maybe not such a
> completely outlandish idea these days, but a much lower 
> probablity event than
> one lone customer who is having a bad day and decides to 
> cause some mischief.

[Govind] I agree that the probability of more than one malicious user is lesser than one malicious user. 
However, if this is an inherent deficiency in a scheme that protects the protocol, 
then I believe in no time will more there be more than one hacker trying to bring down the system. 

> 
> >Also, they might not be removed from the cache. More such 
> entries and more
> > the unnecessary capability messages. Note, if we are using 
> the server scheme,
> each MN has
> > the possibility of reporting a large number of such non-GAAPs.
> 
> Why do you assume the server scheme? The cache state would 
> need to be timed out
> for Dycard as well.
> 
[Govind] Because you have talked about adding cache entries based on APs 
sent in by the MN.

> >Consider this scenario,
> > 10 malicious MNs each report say 100 genuine non-GAAPs.
> 
> If I, as an operator, have 10 malicious customers, then I'm 
> pretty bad off.
> After that attack, they get their service cancelled forthwith.
[Govind] There is no way you can recognize the fact that they are
doing something malicious as they are reporting APs that 
are valid and authorized.

> OK, so its a hundred. How big is a cache entry? Let's be 
> conservative and say
> it's 1K (actually, it's probably a lot smaller). that's still 
> only 100K. Given
> Moore's law, that costs nothing.
[Govind] You have no control on what the cache size is yet. This depends on 
what capabilities are transferred, and their respective sizes. But
cache size is not the attack, increase in inter-AR communication
and subsequent processing is the problem.

> 
> The point is, it's not a million. The attack becomes less 
> probable and easier to
> detect the more entries.
> 
[Govind] My point is even a 100 depending what capabilities are
is a lot of unnecessary processing. Remember, the ARs are not there just for CARD
They are involved in other work too.

> It is all a matter of matching the threat. The highest 
> probability threat, in
> this case, is a single MN having a bad day and deciding to 
> try some mischief.
> Now if an average MN reports, say 2 or three APs and suddenly 
> the router starts
> to get a report of 100, it knows something is amiss. 
[Govind] The number of legal APs (including those from other domains) that a 
MN reports depends on the size of  the "cell" as well as the population of APs of
 other operators. By making
an unnecessary restriction on the number of APs we are just compromising
the protocol needlessly.

If 10 
> MNs each start
> reporting 100, it's time to call the Department of Homeland 
> Security. :-)

[Govind] Since you can't control the number of legal  APs around, any ratelimiting
has to be set to a resonably high number (whatever that may be). Otherwise, 
you stand a chance of MNs just reporting APs out of your domain and the network
rejecting the its own AP info sent in by the MN. Thats why I said initially that
ratelimiting in the server based scheme is more difficult.

[Govind]
> Sure. There are always false positives. But typically any one 
> GAAP will be seen
> by more than one MN. And, there are other ways to reduce the 
> probability of
> flushing good entries, for example, using a weighed moving 
> average of reports.
[Govind] Clearly this fails as the number of malicious MNs increase.

-Govind

---

From: [email-masked]
Date: Fri, 14 Mar 2003 10:36:48 -0500

I just realized that there is one more implication of cache contamination, its on the wireless bandwidth. When there is non-GAAR in cache and MN reports an AP associated with non-GAAR, its capabilities are downloaded to MN, though MN is never going to be handed off to non-GAAR. - Hemant 

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Thursday, March 13, 2003 6:44 PM
To: [email-masked]; Chaskar Hemant (NRC/Boston); [email-masked]; [email-masked]
Subject: RE: [SeaMoby] Topic #3: Cache contamination

-Govind.

---

From: [email-masked]
Date: Fri, 14 Mar 2003 13:03:17 -0500

Jim,
> Govind,
> 
> I'm not convinced Dycard would do any better.
[Govind] 
 The discussion in this thread had nothing to do with dycard.
It was discussing the cache management 
scheme you had proposed w.r.t to its applicability as a cache management
 scheme for the DT draft. I was merely pointing out that it has significant problems when
used in conjunction with the DT draft as it is now.

> 
> As the number of malicious MNs increases, the number of PNE 
> messages will
> increase. Thus, the load on the routers increases in any 
> event.

[Govind] I think you should read some of the old threads, where I have
pointed out how this can be handled. In short, we restrict entries per MN,
identified by its identity. Second, if an MN sends more than one RI message
it is clearly malicious and not the case with a MN sending more than one
APids as I have pointed out in my example in a previous email.  Note, 
I am not saying that you don't have to handle case of cache contamination
in dycard, I am just saying it can be handled differently and even the scheme 
that you proposed may work better with dycard than with the DT scheme, but
I haven't analysed it yet. The simple logic in dycard, using my previous example,
 is that if you have 10 colluding 
malicious MNs you would be able to create at max [10* (limit on entries per MN)] in the cache by
sending RIs. 
In our simulations, if you have a large number of MNs (which is there anyways) in the
system, limiting to just one entry per MN is quite good. 
The MNs would have to be able to show that they handed over from non-CARs.
This is quite difficult to achieve rather than how you populate caches in the
DT scheme, IMO. I think we are going in circles, as this was pointed out previously too. If  you read
the draft carefully and you don't think this has been explained well then we are willing to
address that and make it clearer.

 If there are
> several millions of malicious MNs bombarding the router with 
> RM messages, the
> backhaul will fill with PNE messages as far as I can tell. 

[Govind] RM messages don't launch PNEs. 

I 
> assume Dycard is
> using a cache for confirmed APs also, so that no PNE message 
> would be sent if
> the RM resulted in a hit with a known, good GAAP. Or am I 
> misunderstanding how
> Dycard works?

[Govind] I think you have a misunderstanding on how dycard works.
 PNE messages are sent
based on new AR reports in RI messages, provided the limit is not reached for the
reporting MN. PNEs have nothing to do with APs.

> 
> You mentioned previously you had done a simulation on this. 
> Could you or another
> of the Dyhard Dycard Team provide some information about what 
> the numbers look
> like, or a URL to a published paper?

[Govind]  A paper is under review. I don't think I can make a decision on my own to put it on
a webpage. 

-Govind.

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Fri, 14 Mar 2003 13:25:55 -0600

Eunsoo,
> The first topic is the main thing of this thread. I think the server
> approach cannot filter out false information or prevent cache
contamination.
> I think Dycard can make cache contamination very difficult.
>

AJOY->Why not ? I am confused here.  Could you please explain why do you 
think so?  

Regards,
Ajoy

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Fri, 14 Mar 2003 13:53:42 -0600

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

> AJOY->Why not ? I am confused here.  Could you please explain why do you

In the server approach, MN sends the L2 address of an AP to the current AR.
Then the AR retrieves the L2-L3 mapping entry from the server and puts it in
its cache. There is no check whether MN received the beacon of the AP
within the
coverage area of the current AR. So MN can send L2 address of any AP which
is registered in the server and thus the cache of the AR can contain all the
L2-L3 mapping entries even though some of them are not of CARs of the
current AR.

AJOY-> What is the probability that a malicious MN will send fake AP 
id which is also stored in the server ? I am really having hard 
time imagining any real scenario like this. 

Obviously scope-id is not helpful in verifying the information from MN.

AJOY-> Scope id is used to avoid the cache overflow problem. I do 
not see  how this can cause any cache overflow if the router cache is 
appropriately sized to store entries for all the routers belonging to the
scope. 

Now please can you explain how this can be prevented in the server approach?

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?

Eunsoo

---

From: [email-masked]
Date: Fri, 14 Mar 2003 14:56:59 -0500

James,

> I am trying to understand Dycard, as, I presume, are others in the
> WG. If you and the rest of your team want it or features of it to be included in
> the protocol (which is why, I presume, you are arguing so strongly against the
> DT draft) then you need to help us understand it. It is not helpful or
> constructive to criticize someone else's work without providing a alternative.
> From my reading of the Dycard draft, there may be some useful features in it, we
> need to have the working group understand those.

[Govind] First, its not my team. Second, I am not speaking for others who
co-authored dycard.

While I agree with you in essense, I think it is unfair to expect us to explain everything
when the draft is available for everyone to read. We read the DT draft and raised questions based on
our study. If those who are interested, read our draft and asks us questions exactly 
as how we handle things and ask us to prove the efficiency of our scheme, we will be more than happy
to do so as it helps improve our ideas too. If something is not upto standards of
the WG we will attempt to rectify those issues. If something is unclear and pointed clarifications
are asked from us we can go forward and clarify things. Instead, same questions are being asked 
again and again, and we seem to go around in circles all the time. I would think similar
effort must be made to understand dycard too by people who wish to critique us .

> 
> So why can't the server scheme limit the number of entries 
> per MN? Limiting the
> number of entries per MN has nothing to do with the back end, 
> where the router
> finds out what is an authorized GAAP, which is where Dycard 
> and the server
> scheme differ as I understand it. It has to do with the front 
> end, where the
> router decides what to do with an incoming message.

[Govind] Overall I agree. 
The main point is in the server scheme you are using APids
sent by the MNs as the means of populating the cache. Since you can't restrict
the number of APids it will hear from outside your domain. You have to 
consider it while setting the limit in rate limiting.
Other than that I believe that tagging the MN with its identity is a nice way
to restrict the number of cache entries created by the MN. 
> I see from the draft that it is the RI message that launches 
> PNE, my bad. Now,
> please tell me why an MN can't bombard the router with RI 
> messages? The router
> can rate limit, as you mention above but, in your comments on 
> the Issues, you
> said that you didn't think rate limiting was an issue, so...? 
> Is rate limiting
> important or isn't it? I'm confused.

[Govind] Let me make myself clear yet again. I think it easier
to set the "limit" while  rate limiting in dycard than in the DT draft. I don't
discount the need for rate limiting.

> OK. What happens when the limit is reached? Wouldn't a cache 
> (regardless of the
> timeout policy) be necessary regardless?
[Govind] I didn't understand your point clearly here. But maybe my
previous explanations about understanding the need for rate limiting
would suffice for you.

Thanks,
Govind.

---

From: [email-masked]
Date: Fri, 14 Mar 2003 16:44:39 -0500

OK, you are right if MN has assigned bandwidth slice for which it is paying for. - Hemant

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Friday, March 14, 2003 12:23 PM
To: Chaskar Hemant (NRC/Boston); Krishnamurthi Govind (NRC/Boston); [email-masked]; [email-masked]
Subject: Re: [SeaMoby] Topic #3: Cache contamination

Hemant,

I don't understand.

If an attacking MN reports something that is not a GAAP, then sure, maybe it
gets some junk, but so what? If the MN wants to be so antisocial, then it gets
to deal with the results. As for wireless bandwidth, I assume the wireless
network is enforcing the MN's QoS so it only gets the amount of bandwidth it
paid for. As for the router, as mentioned in Issue 3 on the issues Web page, the
protocol should include a provision for rate limiting and a provision allowing
the router to selectively drop packets in order to deal with a spike in service
requests.

            jak

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Friday, March 14, 2003 7:36 AM
Subject: RE: [SeaMoby] Topic #3: Cache contamination

> I just realized that there is one more implication of cache contamination, its
on the wireless bandwidth. When there is non-GAAR in cache and MN reports an AP
associated with non-GAAR, its capabilities are downloaded to MN, though MN is
never going to be handed off to non-GAAR. - Hemant

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Fri, 14 Mar 2003 17:13:23 -0600

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

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Fri, 14 Mar 2003 17:13:23 -0600

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

<snip>

 Robert Chalmers

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Fri, 14 Mar 2003 17:55:56 -0600

-----Original Message-----
From: Eunsoo Shim [mailto:[email-masked]]
Sent: Friday, March 14, 2003 5:12 PM
To: Singh Ajoy-ASINGH1; 'James Kempf'; [email-masked];

> time imagining any real scenario like this.

[eunsoo] We are talking about malicious MNs, that is, malicious human beings
actually. They can find out AP L2 addresses in the domain by simply walking
around. And they can use the information to fill the cache with the L2
addresses. So probabality is not an issue here.

> appropriately sized to store entries for all the routers belonging to the
[eunsoo]Right. I am pointing it because it was claimed as if scope-id would
prevent cache contamination. If nobody claims that scope id prevents cache
contamination, then we can skip this.

AJOY->The scope-id can be used to limit the cache contamination within the 
given scope.  If you configure the AR cache size appropriately to allow the
caching of 
the maximum number of CAR entries supported in the given domain, then there
is 
no harmful affect of the cache contamination. Also, it should be 
possible to eliminate the contamination completely if the server 
maintains a lists of APs and its neighbors and 
use this information to reject the request when the CARD 
Req options is being reported from a mobile node attached 
to a an AP and the AP is not the neighbor of the AP whose 
AP id is being  provided by the mobile node.   But I do not see and need
for doing 
this because this will require additional configuration information without
any significant advantage. 

> does create an entry in its local cache?

[eunsoo] To defeat the attack, a simple approach is to accept only
authorized ARs as CARs. There are many ways to check authorization of ARs.

AJOY-> Ok. Could you please name a few possible approaches of the mutual 
authentication and authorization of ARs that you have in mind?

Eunsoo

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Fri, 14 Mar 2003 17:55:56 -0600

-----Original Message-----
From: Eunsoo Shim [mailto:[email-masked]]
Sent: Friday, March 14, 2003 5:12 PM
To: Singh Ajoy-ASINGH1; 'James Kempf'; [email-masked];

Eunsoo

---

From: [email-masked]
Date: Fri, 14 Mar 2003 19:20:44 -0500

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

<snip>

 Robert Chalmers

---

From: [email-masked]
Date: Fri, 14 Mar 2003 19:20:44 -0500

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

<snip>

 Robert Chalmers

---

From: [email-masked]
Date: Fri, 14 Mar 2003 20:55:36 -0500

Hi,

>any significant advantage. 

Do you actually realize that we have this kind of argument all over again? However, there are
still no design guidelines how this "should be possible" and "could be used" might look like. 
I saw nobody else who tried so desparately to uphold something that is so clearly underdefined in
its meaning, and I cannot see anything in the direction of a consensus that this "scope-id" would make
any use and would get an entry into a final solution. Maybe we should put a hold on the discussion of
this scope-id and its whatever use and try to make progress with other issues.

Dirk

---

From: [email-masked]
Date: Fri, 14 Mar 2003 20:55:36 -0500

Hi,

Dirk

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Sat, 15 Mar 2003 08:26:07 -0600

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 14, 2003 7:56 PM
To: Ajoy Singh; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: RE: [SeaMoby] Topic #3: Cache contamination

Hi,

>any significant advantage. 

Do you actually realize that we have this kind of argument all over again?
However, there are
still no design guidelines how this "should be possible" and "could be
used" might look like. 
I saw nobody else who tried so desparately to uphold something that is so
clearly underdefined in
its meaning, and I cannot see anything in the direction of a consensus that
this "scope-id" would make
any use and would get an entry into a final solution. Maybe we should put a
hold on the discussion of
this scope-id and its whatever use and try to make progress with other
issues.

AJOY-> I am not sure what is your confusion though. Let us meet offline in
IETF and discuss the issue of 
scope id. 

Dirk

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Sat, 15 Mar 2003 08:26:07 -0600

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 14, 2003 7:56 PM
To: Ajoy Singh; [email-masked]; [email-masked];

Hi,

Dirk

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Sat, 15 Mar 2003 09:08:55 -0600

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

<snip>

 Robert Chalmers

---

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

---

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

Eunsoo,

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

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

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. 

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

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

> 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

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Sun, 16 Mar 2003 14:03:32 -0600

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.

AJOY-> I have indicated in my earlier email that we need 
discuss your so called cache contamination comments 
either offline to during IETF presentation. BTW, 
here a few reasons for having server (e.g., AAA)
based CARD functions: 

1. Server based approach is able to provide seamless 
handoff even if the CAR information is not available in 
the current AR cache. This has been made clear
in previous discussion. 

2. The servers are easier to configure and manage. 

3. Server can be used for inter-AR authorization. 

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

> 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: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Sun, 16 Mar 2003 14:58:57 -0600

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

> the current AR cache. This has been made clear
[eunsoo] This is about initial population of the cache. We had lots of
discussion about this. There were arguements about whether we need initial
population of the cache. However it was clear that any existing management
tool can be used for the initial population from the discussion. It tells us
that we don't need to invenet the wheel for initial router configuration.

AJOY-> Initial population of cache does not address the problems due to 
cache timeout as well as cases when a new AP is added or removed from 
the coverage area of an AR. Also, server less approach of initial cache 
population is very difficult and challenging task for the service providers.

That is why we are defining CARD protocol in first place. If service
provider would like to manually configure L2->L3 mapping at each and 
every ARs then there is no good reason for the existence of the CARD
protocol. 

> 2. The servers are easier to configure and manage.
[eunsoo] It is arguable. If you have to figure out proper scope-ids for
every AR whenever there is a change in the network, it is not a really dummy
job.
Also we have to pay attention to the price of having a central server. In
general it is easier to manage one entity than many entities but you have to
pay the price of reliability (single point of failure) and scalability. 

I don't think the price is smaller than the benefit of easiness.

AJOY-> BTW, there is no additional price if the CARD is integrated 
with AAA function. On the contrary, I think probably managing 1000s of 
AR would be more expensive and error prone than managing a few 
servers. 

> 3. Server can be used for inter-AR authorization.
[eunsoo] Again, if we need a AAA server, we use it. We don't have to
introduce a new type of server functionality.

AJOY-> If we need to use AAA server then 
why not enhance that to support CARD functionality as well. I do 
see any justification for deploying a complicated protocol such 
as dycard when we can achieve the same function my making some 
enhancements to AAA function.  

An important point is that there is alternative requiring no central server.
Why should we bother ourselves with the server? 

AJOY-> This is because AAA servers are anyway required in an access
network and can also be useful tool for providing inter-AR 
authorization. So, I do not see any convincing reason for deploying a 
complicated protocol like dycard. 

We need compelling reasons
such as something that should/can be provided only by the central server and
that is not feasible in a solution without the server. 
Certainly it should
not be the case where there is already the wheel or the price is much larger
than the benefit.

AJOY-> I guess my previous reply would have answered your question. 

Eunsoo

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Sun, 16 Mar 2003 15:14:46 -0600

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

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.

AJOY-> There are two problems here: 
1. Authentication
2. Authorization 
If AR can authenticate each, this does not mean they can authorize 
each for CARD discovery. I am not sure manual configuration of SA
for authenticating as well as authorizing AR for CAR discovery 
will scale in big access network.  

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

AJOY-> In server based approach, AR gets correct information from 
the server so AR is not required to validate this. 

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

AJOY-> I am not sure it does. Please see my earlier 
reply. 

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

AJOY-> Sure. 

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.

AJOY-> So far we had lots of discussion about the cache contamination
and have not been able to resolve the issue over email discussion. 
Hopefully, face to face discussion would help us to resolve this issue.
This way we may be able to engage some security experts who may attend 
WG meeting but may not be participating in the email discussion.  

> > CARD. If you want to propose the server as the AAA server, please can
you
> do

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

AJOY-> I have explained this so many times. 

Eunsoo

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Sun, 16 Mar 2003 15:14:46 -0600

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

Ajoy,

My comments are inline.

AJOY-> Sure. 

you

Eunsoo

---

From: [email-masked]
Date: Mon, 17 Mar 2003 09:10:08 -0500

Hi Ajoy,

>the current AR cache. This has been made clear

It was also made clear that this seamless first handoff only happens with
a probability that is smaller than 1, and that there might be situations in
which might not even happen. 

>2. The servers are easier to configure and manage. 

A server that does not exists is even easier to manage, namely not at all. Your statement
is really kind of funny. Instead of answering the fundamental question why we need the server,
you come over and over again with the argument that servers are easy to manage. This is fundamentally
wrong if we don't need the server. Hence, the concerns are not about manageability, there are about 
necessity. As long as we haven't clarified the latter, the former doesn't matter.

Dirk

---

From: [email-masked]
Date: Mon, 17 Mar 2003 12:43:55 -0500

Inter-AR authorization is not a key point of CARD, IMHO. It is a requirement for many protocols - routing, FMIP, CT etc. Then there are CBPs and other efforts underway to solve this problem so that a family of protocols can use them. Key points of CARD are - rev. addr. translation and capability discovery, and that is exactly what is stated in issues draft. - Hemant 

-----Original Message-----
From: ext Eunsoo Shim [mailto:[email-masked]]
Sent: Sunday, March 16, 2003 5:33 PM
To: Singh Ajoy-ASINGH1; Chaskar Hemant (NRC/Boston); [email-masked]
Cc: [email-masked]
Subject: Re: [SeaMoby] Topic #3: Cache contamination

Ajoy,

My comments are inline.

[eunsoo]
other. MN cannot have influence on it. So it is not correct to say CARD has

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?

Eunsoo

---

From: [email-masked]
Date: Mon, 17 Mar 2003 12:43:55 -0500

-----Original Message-----
From: ext Eunsoo Shim [mailto:[email-masked]]
Sent: Sunday, March 16, 2003 5:33 PM
To: Singh Ajoy-ASINGH1; Chaskar Hemant (NRC/Boston); [email-masked]
Cc: [email-masked]
Subject: Re: [SeaMoby] Topic #3: Cache contamination

Ajoy,

My comments are inline.

[eunsoo]

Eunsoo

---

From: [email-masked]
Date: Tue, 18 Mar 2003 13:59:25 -0500

Hi Marco,

comments inline

>From: ext Liebsch [mailto:[email-masked]]
>Sent: Tuesday, March 18, 2003 2:23 PM
>To: Eunsoo Shim
>Cc: Singh Ajoy-ASINGH1; [email-masked]
>Hi Eunsoo,
>please find some comments below,
>
>marco
>
>Eunsoo Shim wrote:
>
>> >
>> > >
>> > tool can be used for the initial population from the 
>discussion. It tells
>> us
>> [eunsoo] Initial population in Dycard is just done by one 
>handoff between
>> each pair of CARs. What is so difficult and challenging? Can 
>you please
>> explain your claims?
>>
>
>[marco] I think the idea is good, but I have some doubts on 
>how realistic and
>reliable such a dynamic learning approch is. Please correct me if I'm
>wrong. Now, first of all, AR caches are updated by MNs after a
>handover. This is done after each handover, independent of 
>cache entries
>require an update or not. Each update makes use of high cost 
>radio bandwidth.

What amount of radio bandwidth are we talking about here? Sending a triple
of new L2, old L2, and old AR to the access router? I don't think this is
a large amount of bandwidth.

>Furthermore, additional protocol handshakes are most probably required
>to allow newARs to check whether or not a MN has been really attached
>to the oldAR (kind of authenticity check). 

Why would this be necessary if we already have the cache entry? Hence, this check
with the old AR would happen once. The cache entry is only refreshed upon reception of
another report for this old AR, i.e., the lifetime of the entry is renewed, but I don't 
have to check again.

Dirk

---

From: [email-masked]
Date: Tue, 18 Mar 2003 13:59:25 -0500

Hi Marco,

comments inline

Dirk

---

From: [email-masked]
Date: Tue, 18 Mar 2003 14:19:55 -0500

Hi Marco,

>> is really kind of funny. Instead of answering the 
>fundamental question why we need the server,
>> you come over and over again with the argument that servers 
>are easy to manage. This is fundamentally
>Again, both approaches have pros and cons. Now, I agree that 
>some issues
>might be easier to solve when having no server function. But what's the
>tradeoff with an alternative approach? DT just proposed the server
>function for this interface (and is open to modify in 
>particular this interface
>when reasonable and when there is a consensus in the entire WG). But to
>just decry the proposed mechanism and to address negative 
>characteristics
>is probably not the right way. 

The above statement of mine did not address a specific negative characteristic
of servers. I just wanted to make clear that the argument of "easier to manage"
is not proper when we first have to answer the question whether or not we need
the server for performing the L2-L3 mapping. I'm not introducing a server in a 
certain scheme (even in parts of the overall scheme), if I don't need this server. 
The fact that the server is easy to manage, doesn't change that. 

>We should also evaluate positive
>characteristics of the proposed mechnism and tradeoff when going for
>an alternative apporach. 

I agree with you. If you review the discussion last week, the topic concentrated 
more on the issue of performing L2-L3 mapping through the server. Issues like the
existence of a server for AP authentication is not explicitly addressed in the dycard
approach since we assumed such authentication to exist. I expect that such evaluation
as to what the tradeoff of different techniques for different problems within CAR would be,
will be done. 

>As I just indicated in a reply to 
>Eunsoo, dynamic
>learning is a good idea, but we have to evaluate how realistic 
>dynamic learning is
>to meet requirements on chache maintenance and scalability. I 
>expect some
>additional protocol complexity with a dynamic learning approach to
>authenticate info filling ARs' caches. Now, this is not 
>critical with regard
>to timing issues, but might drop down scalability within the 
>access network.

We certainly want to help understanding these issues. But you must also understand that "expecting"
protocol complexity is a not quite technical point to evaluate approaches. If you see concrete issues
regarding complexity and scalability, please bring them up and let's discuss them. To some of the issues
you brought, I've already replied in an earlier email.

In general, please keep in mind that we should not see this discussion as an "either/or" 
question. There are valid points for either approach in certain fields, and we should see
how to get the best out of both.

Dirk

---

From: [email-masked]
Date: Tue, 18 Mar 2003 14:19:55 -0500

Hi Marco,

Dirk