Subject: [Seamoby] Comments on DT CARD draft

From: [email-masked]
Date: Tue, 4 Mar 2003 18:26:51 -0500

Hi guys,
I glanced through the CARD draft and I have some preliminary comments. Here they are:

1. Violation of Requirement 3.8
The draft violates Requirement 3.8, by introducing a new network element specifically  intended for CARD. 

2. Need for CARD server.
The CARD server will never be used once the network reaches steady state.  So we are talking about introducing a network element for the sake of CARD discovery that will be never used probably after one handover between ARs. Once a handover happens between CARs, 
you can push all the AP information as capabilities to the CARs. So why do we need this server again? Apart from this, the DT draft has acknowledged the fact that there is no guarantee that the response from the CARD server will get to the MN in time for the handover. So even when the server is present, at least the first handover is a seamless in a probabilistic sense.

The CARD server is a single point of failure. To avoid this we may introduce some kind of redundancy here. But then we are talking about making the architecture even more complicated, along with associated baggage, for a functionality that will probably be never used after sometime.  There is some discussion in the draft that we can add this server functionality to AAA and RADIUS servers. But can this be such an unilateral decision that doesn't really need discussion with the AAA WG? I therefore think this is not quite a feasible solution right now. Please correct me if I'm wrong about this.

3. Security section
I think "Scope ID" is  a complicated solution, whose cost of usage far out weighs the benefit. Even here we are limiting the granularity of error to that decided by Scope IDs. Therefore if there are n ARs with the same scope ID then we allow n invalid entries in the cache. Also, when we talk about inter-domain handovers this may be quite difficult to achieve. I know that we are not talking about inter-domain handovers at this point, but coming up with a solution that does not work very well in the future is not the correct way to go, IMHO. 

4. Some random observations....
The difference between this draft and dycard is that the AP-AR for the first handover between any two CARs is got from the server. That's it. After this once the cache is created, inter CAR communication takes care of capability transfer and maintenance. Security wise, I don't think dycard is any way more susceptible to attacks than the DT draft. This is fundamentally because the MN's are involved in populating the cache. 

 In the current version of dycard, the first handover between CARs is a bootstrap handover and hence the MN is not provided the mapping between AP and AR. However, we have shown (albeit in an earlier version of our protocol) that we can lower the probability of this too. Even in the DT's CARD approach this is not deterministic process (as acknowledged in the draft) and if the entry is not in cache the response from the CARD server may not get to the MN in time.  So I think we should look hard into the cost vs. benefit ratio of introducing a new element in the network for CARD. IMHO, it is not worth it. 

Thanks for your time,
Govind.

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

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Wed, 5 Mar 2003 11:02:10 -0600

Hello Govind,
Thanks for your initial feedback. Please
find my inline reply.
Regards,
Ajoy 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Tuesday, March 04, 2003 5:27 PM
To: [email-masked]
Subject: [Seamoby] Comments on DT CARD draft

Hi guys,

AJOY-> We are aware of this. What is the status of 
requirement draft? Is it approved by IESG yet. Probably 
we need to change this requirement in case WG likes 
to go with server based approach.

2. Need for CARD server.
The CARD server will never be used once the network reaches steady state. 
So we are talking about introducing a network element for the sake of CARD discovery that will be never used probably after one handover between ARs. 

AJOY-> This depends upon the cache timeout as well as handoff traffic.
BTW, the server based approach is easier to manage as well 
it provides extra security. If we deploy scope-id with serve based approach, then
it is very much possible to reduce or even eliminate the problem of cache contamination. 
This also minimizes the affect DoS attack.

Once a handover happens between CARs, 
you can push all the AP information as capabilities to the CARs. So why do we need this server again? 

AJOY-> These entries may not be cached for ever. Smaller the cache timeout,
the earlier you will be able to detect any change of capability
or L2->L3 mapping information.

Apart from this, the DT draft has acknowledged the fact that there is no guarantee that the response from the CARD server will get to the MN in time for the handover. So even when the server is present, at least the first handover is a seamless in a probabilistic sense.

AJOY-> I think this will be better than the case where cache entries are solely 
propagated by the mobile node. I think in the later case, the first handoff 
will always be the slower. Moreover the later approach is very 
difficult to manage and is even less secure. 

The CARD server is a single point of failure. To avoid this we may introduce some kind of redundancy here. But then we are talking about making the architecture even more complicated, along with associated baggage, for a functionality that will probably be never used after sometime. 

BTW-> The IP packets are not routed via CARD server so I am not sure if it a big 
drawback. I will be more concerned about the single point of failure where IP packets are 
routed through it. CARD server will provide a similar function as DNS server
So, probably it is not a big drawback in my understanding. On the other handoff, 
server based approach provides better manageability as well control. As I mentioned above, 
with clever use of scope-id, it is possible to reduce the affect of DoS attack as 
well as cache contamination problem. 

There is some discussion in the draft that we can add this server functionality to AAA and RADIUS servers. But can this be such an unilateral decision that doesn't really need discussion with the AAA WG? I therefore think this is not quite a feasible solution right now. Please correct me if I'm wrong about this.

AJOY-> Probably you are right. We do need to get consensus from AAA group for doing this. 
BTW, If we use AAA server, then it is also possible to use AAA server for the 
purpose of key distribution. I would like to receive feedback from other members of 
WG about the potential use of AAA server as CARD server.

3. Security section
I think "Scope ID" is  a complicated solution, whose cost of usage far out weighs the benefit. Even here we are limiting the granularity of error to that decided by Scope IDs. Therefore if there are n ARs with the same scope ID then we allow n invalid entries in the cache. 

AJOY-> I am not sure I agree with you here. Could you provide some additional 
detail why you think scope id is complicated? 

Also, when we talk about inter-domain handovers this may be quite difficult to achieve. I know that we are not talking about inter-domain handovers at this point, but coming up with a solution that does not work very well in the future is not the correct way to go, IMHO. 

AJOY-> Let be focused now. 

Thanks for your time,
Govind.

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Wed, 5 Mar 2003 11:02:10 -0600

Hello Govind,

-----Original Message-----

Hi guys,

2. Need for CARD server.

3. Security section

Thanks for your time,
Govind.

---

From: [email-masked]
Date: Wed, 5 Mar 2003 13:58:23 -0500

Hi Ajoy,
Comments inline. Thanks for your reply.

-Govind.

[Govind] The requirements document has passed last WG last call. The IESG did come back with one set of comments, but I don't think they had
any problems with this particular requirement in those comments.

[snip]

[Govind] The cache timeout can be handled quite easily. Regarding, the server based approach being more secure, this is quite unclear from the document. I don't think you can eleminate the cache contamination problem from any of the schemes that you have described. I have explained in my email how using the scope ID approach still allows you to keep "n" entries
that are not CARs in the cache.  In fact, the DT draft acknowledges that the
CARD server can still be subjected to a DoS attack. I don't really agree with your premise that you alleviate the security problems just by having a
CARD server.

[snip]

[Govind] So we need to choose a timeout that is appropriate, why do we need a server for this? I still don't understand that.

[snip]

[Govind] Yes, the first handover case. So are you saying the cost of the first handover being not seamless is worth introducing a new element in the network? 
 Could you explain why the latter approach is less secure? Once you have a cache at the AR that is populated with MN input, like what you are doing in the DT draft and we do in dycard, the level of security of the protocols is pretty comparable. Please note, any of the security checks that you have introduced including scope ID, which I still think is not the best way to go, can be used without the server being present at all.

Also, you could you list out the security holes that you perceive in the dycard draft. Also, could you look at the way we have handled it and see whether we have presented solutions tackled the issues? 

Lastly, as I pointed out in my earlier mail, we have provided a method, in an earlier version of the draft, that makes the first handover also seamless in a probabilistic sense. I don't think DT draft can promise better than that too. We omitted this, because we felt that it doesn't make much sense in the steady state of the system. Basically a cost vs. benefit analysis.

----------*
[snip]

BTW-> The IP packets are not routed via CARD server so I am not sure if it a big 
drawback. 
[Govind] You need the CARD server for any translation on a cache miss. 
So what is this that you bring about routing packets via CARD server? I'm completely missing your point here.
-----------------------*
I will be more concerned about the single point of failure where IP packets are 
routed through it. CARD server will provide a similar function as DNS server
So, probably it is not a big drawback in my understanding.

[Govind] Does this imply that the functionality of the CARD server is minimal? We are talking about the "central" point of control here that determines the cache entries. I think it a very important point to consider.
---------------------------*
 On the other handoff, 
server based approach provides better manageability as well control. 

[Govind] What manageability are you talking about? You assume that each AR knows what APs it has. Why should it be conveyed to the CARD server? Why can't it be conveyed directly to its CARs? Also, what lack of manageability that you perceive in dycard? Can we talk quantitatively rather qualitatively here?

As I mentioned above, 

[Govind] Could you define "clever" use of scope-id? Quoting from the draft
"operators may set their ARs' scope id to a server. When a current AR requests the L2-L3 mapping from the server, the server returns the mapping with the scope-id".  From the above reasoning, there is an close correlation assumed with the ARs and APs. That might not be true first. Second if the approximate locations of APs and ARs are known and they are in the same domain, why not have these scope-IDs directly stored at the ARs in the cache rather than pushing them to the CARD server then getting them down to the ARs. 

[snip]
[Govind] I don't think we need to do this at all. Key distribution, that too for ARs in the same domain, is not at all CARD problem at all. There are other ways to do it, and I don't think we need to re-invent the wheel. Routers within a domain are trusting each other right now too, is it not? 

[snip]

[Govind]I'll let you know if I come up with something more, than what I've provided in my previous email.

[Govind] Focusing on a solution that doesn't work very well even now is not the best way to go either. Instead, it will be more prudent to come up with 
a solution that works well now, and also has a good chance of being accepted later.

---

From: [email-masked]
Date: Wed, 5 Mar 2003 14:37:10 -0500

Hi Ajoy,

some comments inline.

>From: ext Singh Ajoy-ASINGH1 [mailto:[email-masked]]
>Sent: Wednesday, March 05, 2003 12:02 PM
>To: Krishnamurthi Govind (NRC/Boston); [email-masked]
>Subject: RE: [Seamoby] Comments on DT CARD draft
>
>
>Hello Govind,
>The draft violates Requirement 3.8, by introducing a new 
>network element specifically  intended for CARD. 
>

I'm wondering why we have discussions about requirements when later we are 
so easily willing to change requirements to push certain solutions. Doesn't it
contradict the purpose of requirements??

>So we are talking about introducing a network element for the 
>sake of CARD discovery that will be never used probably after 
>one handover between ARs. 
>

Cache population through any means, i.e., server or dycard-like approach, depends
on the timeout of the cache entries, and you certainly want to minimize any kind of
extra measures to run those population mechanisms.

>it provides extra security. 

Could you elaborate on this? It sounds pretty much like out-of-the-blue statements to me. 
I don't see anything in the draft regarding the server approach that would justify 
this statement. More specifically, it is quite unclear to me why an approach that does have
an extra element compared to another one, is easier to manage than an approach that doesn't
need the extra element. 

>If we deploy scope-id with serve 
>based approach, then

How would this happen? If I have n ARs in the scope of one scope-id, I still
have the possibility of n false cache entries. Could you give some details on how
such elimination would happen?

>you can push all the AP information as capabilities to the 
>CARs. So why do we need this server again? 
>
>Apart from this, the DT draft has acknowledged the fact that 
>there is no guarantee that the response from the CARD server 
>will get to the MN in time for the handover. So even when the 
>server is present, at least the first handover is a seamless 
>in a probabilistic sense.
>
>will always be the slower. 

Well, does it really matter for most ARs???? I buy the possibility, with a probability<1 
(sometimes even <<1) that the first handoff would be seamless with the necessity of an 
additional server. Is this really worth the effort??

> Moreover the later approach is very 

Again, this sounds very weird to me. Having an server-less approach is more complicated
to manage than a server-based approach? Further, could you also elaborate on the security issues
that you see with a server-free approach that would be solved with the server approach?

>
>The CARD server is a single point of failure. To avoid this we 
>may introduce some kind of redundancy here. But then we are 
>talking about making the architecture even more complicated, 
>along with associated baggage, for a functionality that will 
>probably be never used after sometime. 
>

The single-point-of-failure is to be seen for the functionality, it is supposed 
to provide. If the server fails, no L2-L3 mapping is possible, no cache is populated,
ALL handoffs are break-before-make. Compared to a server-less approach, this sound
significant to me.

>well as cache contamination problem. 

"Clever usage" of parameters is a security measure that sounds quite suspicious to me, and
I don't think it is a valid one. Hence, you should elaborate on what those "clever usages" are.

>
>There is some discussion in the draft that we can add this 
>server functionality to AAA and RADIUS servers. But can this 
>be such an unilateral decision that doesn't really need 
>discussion with the AAA WG? I therefore think this is not 
>quite a feasible solution right now. Please correct me if I'm 
>wrong about this.
>

Hmm, so now we are integrating CARD with AAA? Looking at the progress of the
AAA WG, I'm not sure they're quite willing to open this box. And I don't think
we should either. Using AAA for key distribution sounds quite out of scope to me.

>
>3. Security section
>I think "Scope ID" is  a complicated solution, whose cost of 
>usage far out weighs the benefit. Even here we are limiting 
>the granularity of error to that decided by Scope IDs. 
>Therefore if there are n ARs with the same scope ID then we 
>allow n invalid entries in the cache. 
>

Mainly because of your wording of "clever usage". A parameter that
requires "clever" setting in order to provide security concerns me.
So it is up to you to provide additional detail how this would work.
I do see Govind's point quite clearly, that having n ARs in the same scope
would allow for n false entries in the cache. Assuming inter-CAR exchange
of capabilities between those ARs doen't make my concern smaller.

Regards,

Dirk

---

From: [email-masked]
Date: Wed, 5 Mar 2003 14:37:10 -0500

Hi Ajoy,

some comments inline.

Regards,

Dirk

---

From: [email-masked]
Date: Wed, 5 Mar 2003 16:18:43 -0500

Hi,

One comment on AAA integration. To me, this sounds totally out of scope of CARD. CARD security problem for inter-AR security is not different than CT or FMIPv6. That leaves AR-server branch open for security discussion. But given that both AR and server will lie in the same administrative domain (current assumption), there are a number of ways other that AAA to do this. The simplest one is shared passwords. Another one is through IPSec policy framework.

OK, what if some ISP wants to deploy CARD server on DNS box. Do we need to go to DNS security folks for it?

Hemant  

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 05, 2003 2:37 PM
To: [email-masked]
Subject: FW: [Seamoby] Comments on DT CARD draft

Hi Ajoy,

some comments inline.

Regards,

Dirk

---

From: [email-masked]
Date: Wed, 5 Mar 2003 16:18:43 -0500

Hi,

Hemant  

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 05, 2003 2:37 PM
To: [email-masked]
Subject: FW: [Seamoby] Comments on DT CARD draft

Hi Ajoy,

some comments inline.

Regards,

Dirk

---

From: [email-masked]
Date: Wed, 5 Mar 2003 16:59:40 -0500

Jim,
First, I think the DT has a different view from you about the server not being a new element :).

Essentially what saying is that you are adding a new functionality on some other 
existing element in the network. 
There is an inherent assumption that this can be added to such servers. For example, this may
not be possible in AAA servers given the present charter of AAA WG. The DT members also 
seem to accept this may be the case.

The main point I was trying to make is
 having an extra server (or functionality) whereever it may  reside is not worth it at all. 

Could you elaborate more on the IPSec configuration that you mention. Just to
understand you better.
I look forward to your comments. 
-Govind.
-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Wednesday, March 05, 2003 4:36 PM
To: Krishnamurthi Govind (NRC/Boston); [email-masked];
[email-masked]
Subject: Re: [Seamoby] Comments on DT CARD draft

Govind,

I don't agree that the server specified in the draft is a new element. The
specification is for a configuration server, AAA or LDAP or something like that.
This is a common way of configuring routers, I believe it is used for IPsec
configuration information.

I haven't finished reading the draft yet so I can't comment on the rest of your
points.

            jak

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Wednesday, March 05, 2003 10:58 AM
Subject: RE: [Seamoby] Comments on DT CARD draft

> [Govind] The requirements document has passed last WG last call. The IESG did
come back with one set of comments, but I don't think they had
> [Govind] The cache timeout can be handled quite easily. Regarding, the server
based approach being more secure, this is quite unclear from the document. I
don't think you can eleminate the cache contamination problem from any of the
schemes that you have described. I have explained in my email how using the
scope ID approach still allows you to keep "n" entries
> CARD server can still be subjected to a DoS attack. I don't really agree with
your premise that you alleviate the security problems just by having a
> [Govind] So we need to choose a timeout that is appropriate, why do we need a
server for this? I still don't understand that.
> [Govind] Yes, the first handover case. So are you saying the cost of the first
handover being not seamless is worth introducing a new element in the network?
>  Could you explain why the latter approach is less secure? Once you have a
cache at the AR that is populated with MN input, like what you are doing in the
DT draft and we do in dycard, the level of security of the protocols is pretty
comparable. Please note, any of the security checks that you have introduced
including scope ID, which I still think is not the best way to go, can be used
without the server being present at all.
>
> Also, you could you list out the security holes that you perceive in the
dycard draft. Also, could you look at the way we have handled it and see whether
we have presented solutions tackled the issues?
>
> Lastly, as I pointed out in my earlier mail, we have provided a method, in an
earlier version of the draft, that makes the first handover also seamless in a
probabilistic sense. I don't think DT draft can promise better than that too. We
omitted this, because we felt that it doesn't make much sense in the steady
state of the system. Basically a cost vs. benefit analysis.
> [Govind] Does this imply that the functionality of the CARD server is minimal?
We are talking about the "central" point of control here that determines the
cache entries. I think it a very important point to consider.
> [Govind] What manageability are you talking about? You assume that each AR
knows what APs it has. Why should it be conveyed to the CARD server? Why can't
it be conveyed directly to its CARs? Also, what lack of manageability that you
perceive in dycard? Can we talk quantitatively rather qualitatively here?
> "operators may set their ARs' scope id to a server. When a current AR requests
the L2-L3 mapping from the server, the server returns the mapping with the
scope-id".  From the above reasoning, there is an close correlation assumed with
the ARs and APs. That might not be true first. Second if the approximate
locations of APs and ARs are known and they are in the same domain, why not have
these scope-IDs directly stored at the ARs in the cache rather than pushing them
to the CARD server then getting them down to the ARs.
> [Govind] I don't think we need to do this at all. Key distribution, that too
for ARs in the same domain, is not at all CARD problem at all. There are other
ways to do it, and I don't think we need to re-invent the wheel. Routers within
a domain are trusting each other right now too, is it not?
> Also, when we talk about inter-domain handovers this may be quite difficult to
achieve. I know that we are not talking about inter-domain handovers at this
point, but coming up with a solution that does not work very well in the future
is not the correct way to go, IMHO.
> [Govind] Focusing on a solution that doesn't work very well even now is not
the best way to go either. Instead, it will be more prudent to come up with

---

From: [email-masked]
Date: Wed, 5 Mar 2003 18:58:46 -0500

Jim,

> seem to accept this may be the case.

It could be an LDAP server.

[Govind] Are you sure LDAP servers exist everywhere? Plus, you might have similar issues
as with AAA WG.

>  having an extra server (or functionality) whereever it may  reside is not
worth it at all.

Depends. There are other things in this draft (TAR calculation, for example)
that one could argue shouldn't be there.

[Govind] AFAIK, the DT draft does not talk about TAR selection. But I might have missed it.
It just mentions that the CARD output is fed to TARS. But I agree with you in the sense
that what is not essentially relevant to CARD shouldn't be there.
_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Thu, 6 Mar 2003 12:18:35 -0600

Hello Govind,
Please find my inline reply.
Regards,
Ajoy 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Wednesday, March 05, 2003 12:58 PM
To: Ajoy Singh; [email-masked]
Subject: RE: [Seamoby] Comments on DT CARD draft

Hi Ajoy,

-Govind.

[snip]

This depends upon the cache timeout as well as handoff traffic.

[Govind] The cache timeout can be handled quite easily. 

AJOY-> I meant every time cache times out, your proposed scheme (dycard) 
will perform slow handoff. But in case of server based approach this may 
not be the case. In server based approach, AR cache is updated when a mobile 
node scans the neighboring channel and detects a new link layer id. In this it is likely 
that the server cache will be updated prior to layer 3 handoff. 
Hence, the current AR may not be required to query AR server during critical
path of handoff. Also, by properly placing the server with 
respect to AR, you can minimize the round trip delay with server.

Regarding, the server based approach being more secure, this is quite unclear from the document. I don't think you can eleminate the cache contamination problem from any of the schemes that you have described. I have explained in my email how using the scope ID approach still allows you to keep "n" entriesthat are not CARs in the cache.  In fact, the DT draft acknowledges that the
CARD server can still be subjected to a DoS attack. I don't really agree with your premise that you alleviate the security problems just by having a
CARD server.

AJOY-> The scope-id reduces the cache contamination problem, the 
potential growth of AR cache is bounded. This will eliminate the problem 
introduced due to unbounded cache growth. For example, in case of dycard, 
you might have a situation where the AR cache will overflow if a mobile node 
keeps injecting wrong information to the AR. This will cause 
AR to either crash or remove the old  useful cache entries. Potentially 
this will create a situation where AR will loose valid cache entries 
to populate invalid entries. Is it not correct? 

[snip]

These entries may not be cached for ever. Smaller the cache timeout,
the earlier you will be able to detect any change of capability
or L2->L3 mapping information.

AJOY-> Won't next handoff performed by dycard will
be slow after cache timeout? BTW, 
this is necessarily not a problem with server based approach. 
The AR cache is updated when a mobile node scans the neighboring 
channel and detects a new link layer id. In this it is likely 
that the server cache will be updated prior to layer 3 handoff. 
Hence, the AR may not be required to query CARD server during critical
path of handoff. Also, by properly placing the server with 
respect to AR, you can minimize the round trip delay with server.

[snip]

I think this will be better than the case where cache entries are solely 
propagated by the mobile node. I think in the later case, the first handoff 
will always be the slower. Moreover the later approach is very 
difficult to manage and is even less secure. 

AJOY-> This is not the only reason. The server based approach provides 
centralized configuration. It is also easier to manage. Also, 
you can deploy scope-id to eliminate the harmful aspect of cache 
contamination. In this you can eliminate the cache overflow by 
properly configuring the size of AR cache.

AJOY-> The scope-id enables you to avoid cache overflow problem. If you do not have 
scope-id defined, some malicious MN will able to inject the fake messages to 
AR that would increase the size of cache to unexpectedly large value. Depending 
upon the caching policy, AR may either discard the useful cache information 
to store fake entries. 

AJOY-> Could you please explain how dycard plans to avoid the problem of 
cache overflow? 

----------*
[snip]

AJOY-> It is relatively inexpensive to provide redundancy of a
server that only does L2->L3 mapping. This function can be 
easily piggybacked upon existing high availability server 
platform. 

-----------------------*

AJOY-> See previous reply.

AJOY-> The server based approach also allows the server to store
L2->L3 mapping, scope-id and static capabilities. It is 
very easy to manage these information if it stored at 
single point. Managing such information in 
distributed case is difficult.  

As I mentioned above, 

[Govind] Could you define "clever" use of scope-id? Quoting from the draft
"operators may set their ARs' scope id to a server. When a current AR requests the L2-L3 mapping from the server, the server returns the mapping with the scope-id". 

AJOY-> The scope-id can also be manually configured at server. 
In this case if any AR tries to resolve the link layer 
id belonging to AR whose scope-id does not match the 
requester's scope-id, server can simply reject the 
request. Also, you can properly configure the size of AR cache if 
you know how many AR's are covered by the 
given scope-id. BTW, I do admit we need to clarify the 
proper use of scope-id in the draft

From the above reasoning, there is an close correlation assumed with the ARs and APs. That might not be true first. Second if the approximate locations of APs and ARs are known and they are in the same domain, why not have these scope-IDs directly stored at the ARs in the cache rather than pushing them to the CARD server then getting them down to the ARs. 

[snip]
Probably you are right. We do need to get consensus from AAA group for doing this. 
BTW, If we use AAA server, then it is also possible to use AAA server for the 
purpose of key distribution. I would like to receive feedback from other members of 
WG about the potential use of AAA server as CARD server.

AJOY-> BTW, the AAA server is widely used in access network. So, 
I do not see why are you so much opposed to this? I think 
the AAA server based key distribution may be useful in 
inter-domain case. BTW, I am flexible in this and 
NOT proposing that key distribution MUST be done 
through AAA server. I am just looking for 
others' opinion about it.

[snip]
I am not sure I agree with you here. Could you provide some additional 
detail why you think scope id is complicated? 

AJOY-> Ok, it will be helpful. 

Let be focused now. 

AJOY-> I do not agree with your conclusion. The server based approach (DNS)
has been widely deployed in Internet name->address resolution.  
_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Thu, 6 Mar 2003 12:18:35 -0600

Hello Govind,

-----Original Message-----

Hi Ajoy,

-Govind.

[snip]

[snip]

[snip]

----------*
[snip]

-----------------------*

As I mentioned above, 

[snip]

[snip]

Let be focused now.

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Thu, 6 Mar 2003 12:26:39 -0600

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 05, 2003 3:19 PM
To: [email-masked]; [email-masked]
Subject: RE: [Seamoby] Comments on DT CARD draft

Hi,

One comment on AAA integration. To me, this sounds totally out of scope of
CARD. CARD security problem for inter-AR security is not different than CT
or FMIPv6. That leaves AR-server branch open for security discussion. But
given that both AR and server will lie in the same administrative domain
(current assumption), there are a number of ways other that AAA to do this.
The simplest one is shared passwords. Another one is through IPSec policy
framework.

AJOY-> You please see my reply to Govind. 

OK, what if some ISP wants to deploy CARD server on DNS box. Do we need to
go to DNS security folks for it?

Hemant  

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 05, 2003 2:37 PM
To: [email-masked]
Subject: FW: [Seamoby] Comments on DT CARD draft

Hi Ajoy,

some comments inline.

I'm wondering why we have discussions about requirements when later we are 
so easily willing to change requirements to push certain solutions. Doesn't
it
contradict the purpose of requirements??

>AJOY-> This depends upon the cache timeout as well as handoff traffic.

Cache population through any means, i.e., server or dycard-like approach,
depends
on the timeout of the cache entries, and you certainly want to minimize any
kind of
extra measures to run those population mechanisms.

>it provides extra security. 

Could you elaborate on this? It sounds pretty much like out-of-the-blue
statements to me. 
I don't see anything in the draft regarding the server approach that would
justify 
this statement. More specifically, it is quite unclear to me why an approach
that does have
an extra element compared to another one, is easier to manage than an
approach that doesn't
need the extra element. 

How would this happen? If I have n ARs in the scope of one scope-id, I still
have the possibility of n false cache entries. Could you give some details
on how
such elimination would happen?

>will always be the slower. 

Well, does it really matter for most ARs???? I buy the possibility, with a
probability<1 
(sometimes even <<1) that the first handoff would be seamless with the
necessity of an 
additional server. Is this really worth the effort??

>difficult to manage and is even less secure. 

Again, this sounds very weird to me. Having an server-less approach is more
complicated
to manage than a server-based approach? Further, could you also elaborate on
the security issues
that you see with a server-free approach that would be solved with the
server approach?

>So, probably it is not a big drawback in my understanding. 

The single-point-of-failure is to be seen for the functionality, it is
supposed 
to provide. If the server fails, no L2-L3 mapping is possible, no cache is
populated,
ALL handoffs are break-before-make. Compared to a server-less approach, this
sound
significant to me.

>well as cache contamination problem. 

"Clever usage" of parameters is a security measure that sounds quite
suspicious to me, and
I don't think it is a valid one. Hence, you should elaborate on what those
"clever usages" are.

Hmm, so now we are integrating CARD with AAA? Looking at the progress of the
AAA WG, I'm not sure they're quite willing to open this box. And I don't
think
we should either. Using AAA for key distribution sounds quite out of scope
to me.

Regards,

Dirk

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Thu, 6 Mar 2003 12:26:39 -0600

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 05, 2003 3:19 PM
To: [email-masked]; [email-masked]
Subject: RE: [Seamoby] Comments on DT CARD draft

Hi,

Hemant  

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 05, 2003 2:37 PM
To: [email-masked]
Subject: FW: [Seamoby] Comments on DT CARD draft

Hi Ajoy,

some comments inline.

Regards,

Dirk

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Thu, 6 Mar 2003 12:48:20 -0600

Hello Dirk,
See my reply to Govind's
email for answers for most of 
your questions. Please 
also see the inline reply.
Regards,
Ajoy 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 05, 2003 1:37 PM
To: [email-masked]
Subject: FW: [Seamoby] Comments on DT CARD draft

Hi Ajoy,

some comments inline.

AJOY-> This requirements are not yet approved.
BTW, we are open to re-use the existing 
server to provide CARD functionality. 

AJOY-> Why not? see my reply to Govind's email.

AJOY-> This is not a technical reason for not pursuing this.
BTW, what is your opion about the time frame when the 
vendors will deploy CARD? 

AJOY-> Please see the my reply to Govind's email. BTW,
I do agree that we need to clarify the use of scope-id
in the next revision of the draft.

Regards,

Dirk

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Thu, 6 Mar 2003 12:48:20 -0600

Hello Dirk,
See my reply to Govind's

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 05, 2003 1:37 PM
To: [email-masked]
Subject: FW: [Seamoby] Comments on DT CARD draft

Hi Ajoy,

some comments inline.

Regards,

Dirk

---

From: [email-masked]
Date: Thu, 6 Mar 2003 13:51:16 -0500

Hi Ajoy,
My replies are embedded.
-Govind.

[Govind] Why will cache time out if there are frequent handovers. Plus once two ARs 
have recognized each other as CARs, why can't we setup a refresh procedure. Doesn't
that take care of it? Secondly, what do you mean "properly placing the server
with respect to the AR, we minimize the round trip delay". You have one server per domain
right? How are you going to optimize w.r.t each AR. Are you suggesting now an server per
AR?

[Govind] First, if you read dycard you will see that the "overflow" problem
that you talk about is almost impossible. We do this by a scheme wherein
we restrict the number of entries that can be created by each MN. 
Also, I don't think your scope-id solution anyway reduces the problem. You
are saying that if we have "n" incorrect entries in the cache it is not 
a problem, where n can be arbitrarily large right (atleast w.r.t the cache size)
? I don't quite agree with that.

[snip]

[Govind] I disagree with your premise that dycard introduces frequent
cache misses. This statement is terribly flawed. Rather, I think
in the steady state the server is useless. If you have a proper
cache update policy and make sure DoS is hard, we are through.

[Govind] Again, what management are you talking about? When CARs talk to each other
why not store all the information required in each other's caches? You are doing
that anyway in the DT draft. What you are advocating is a cache + server. What I am
saying that cache is enough.

[Govind] Yes while I agree we have to protect against DoS, scope-id is not the way to
 handle this, IMO. 

[Govind] Sure, we restrict the number of entries that each MN can create in the server.
The number of entries is configurable.
We make sure that the MN was actually present in the previous ARs domain in the "recent" past.
Where "recent" is a variable that can be configured. 

[Govind] I don't disagree with the fact that it might be relatively
inexpensive to provide reliability. But look at the cost in terms
of any benefit you receive from the server. It doesn't add up.
Plus, you have consistency issues to take care of when you have redundancy.
Instead, why not have a server at each AR then?

[Govind]Why are you introducing a new
element or functionality instead of dealing with routers themselves. CARs
can contact each other just fine once they know about each other. They
can talk to each other and manage capabilities. They don't need talk to a 
server to get updates.

[Govind] What advantage do you have by manually configuring scope-ids? 
If that is the case, why don't you program it in routers themselves
and make themselves aware of their scope-id? 

[Govind] Why don't we use already existing SAs (trust relationships)
 between routers in the same domain. Why do we have to invent a new
 scheme altogether?

[Govind] Just because something works
someplace, you don't need to use it everywhere when there is no need for it.
_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: [email-masked]
Date: Thu, 6 Mar 2003 13:51:16 -0500

Hi Ajoy,
My replies are embedded.
-Govind.

[snip]

---

From: [email-masked]
Date: Thu, 6 Mar 2003 13:52:48 -0500

Hi Ajoy,

see inline.

>respect to AR, you can minimize the round trip delay with server.

It still boils down to the same question:
In case there is no entry in the AR cache (either due to very first
handoff or due to cache timeout), is it worth to deploy a server to catch
the first handoff in order to populate the cache? In the server-based approach
this will happen with a certain probability only, and it is hard to get real
numbers on this probability since it depends on delay for the query compared to
the time the mobile resides in the overlapping region of coverage. Guessing that
"it will probably be there in time" is not a quantitive measure that helps, since it
is a highly physical topology and mobility pattern dependent problem. 
But even so, is it worth the effort, in particular if we consider conservative cache 
timeout settings or even dynamic cache timeout mechanisms in the AR based on the handoff 
traffic?

>
>Regarding, the server based approach being more secure, this 
>is quite unclear from the document. I don't think you can 
>eleminate the cache contamination problem from any of the 
>schemes that you have described. I have explained in my email 
>how using the scope ID approach still allows you to keep "n" 
>entriesthat are not CARs in the cache.  In fact, the DT draft 
>acknowledges that the
>CARD server can still be subjected to a DoS attack. I don't 
>really agree with your premise that you alleviate the security 
>problems just by having a
>CARD server.
>

Why can't I do the same bound operation in dycard? If an MN is injecting
wrong information to the AR, I can start rejecting the entries after n ARs.
I have to do the same thing for the server. Nothing crashes here. Further,
you have to keep in mind that it is probably easier to inject wrong L2-L3 
mapping requests (as for the server approach) than to forge your L2 identifier
(which you have to provide in the dycard approach) when injecting the 
old AR's address. 

>[Govind] Yes, the first handover case. So are you saying the 
>cost of the first handover being not seamless is worth 
>introducing a new element in the network? 
>

We're turning in circles here. The question is not whether or not the
server is managable and nice to configure, the question is whether we
need the server at all. Having nothing to be configured and managed is
better than any other solution that requires management and configuration, right?

Regarding the scope-id, it is not yet clear (also James indicated this) how
the scope-id would work. Eliminating cache overflow is always possible by simply
rejecting entries after a certain cache size.

>
>Also, you could you list out the security holes that you 
>perceive in the dycard draft. Also, could you look at the way 
>we have handled it and see whether we have presented solutions 
>tackled the issues? 
>

Please take a look at the draft since it is explained in there. 

>[Govind] What manageability are you talking about? You assume 
>that each AR knows what APs it has. Why should it be conveyed 
>to the CARD server? Why can't it be conveyed directly to its 
>CARs? Also, what lack of manageability that you perceive in 
>dycard? Can we talk quantitatively rather qualitatively here?
>

It would be helpful if you would point out the difficulties in
managing a distributed approach such as dycard. 

>"operators may set their ARs' scope id to a server. When a 
>current AR requests the L2-L3 mapping from the server, the 
>server returns the mapping with the scope-id". 
>

How would this work in an environment with a certain dynamic? Would you have
to reconfigure the id? The problem right now is mostly that we are relying 
on a mechanism when it comes to security, which is not at all clear with respect to
its usage. "Proper" and "clever" as design guidelines are not helpful to resolve
these concerns.

>[Govind] I don't think we need to do this at all. Key 
>distribution, that too for ARs in the same domain, is not at 
>all CARD problem at all. There are other ways to do it, and I 
>don't think we need to re-invent the wheel. Routers within a 
>domain are trusting each other right now too, is it not? 
>

The main opposition comes from the question whether we're tackling a problem
here that we shouldn't. 

>[Govind]I'll let you know if I come up with something more, 
>than what I've provided in my previous email.
>

It is not about complicated or not. It is simply not clear how to use
the parameter, in particular since it is proposed to cope with DoS attacks.
Again, clarifying "clever" and "proper" from your side would be helpful to
give everybody a picture of the usefulness of the parameter and the ability to
do what it is supposed to do.

>
>Also, when we talk about inter-domain handovers this may be 
>quite difficult to achieve. I know that we are not talking 
>about inter-domain handovers at this point, but coming up with 
>a solution that does not work very well in the future is not 
>the correct way to go, IMHO. 
>
>Let be focused now. 
>
>[Govind] Focusing on a solution that doesn't work very well 
>even now is not the best way to go either. Instead, it will be 
>more prudent to come up with 

You're simply not comparing the right things. DNS isn't a widely
deployed and accepted solution because everybody loves servers for the sake of 
their existence. The problem of name resolution (with its existing naming structure) 
points towards a server solution. At least, I can hardly imagine a fully
server-less solution for DNS (apart from shouting into the network).
However, this does not give sufficient reason to use servers for another
problem, in particular not if a server-less solution is available.

Dirk

---

From: [email-masked]
Date: Thu, 6 Mar 2003 13:52:48 -0500

Hi Ajoy,

see inline.

Dirk

---

From: "Eunsoo Shim" <[email-masked]>
Date: Thu, 06 Mar 2003 15:04:46 -0500

>such elimination would happen?
(eunsoo) I don't understand either how scope-id prevents cache 
contamination. Please provide us a scenario of it.
To assign scope id, you should know what base stations are in the adjacent 
region and to which AR those APs are associated. Also you need to assign 
multiple scope-ids to each AR. We started CARD work to find a solution for 
dynamic discovery while we knew that static configuration of L2-L3 mapping 
at each AR was always a possibility. Now the server approach requires static 
configuration of L2-L3 mapping in a server and also requires knowledge of 
which base stations are close to each other. If a new base station is 
deployed, a new mapping entry should be typed in and also the admin should 
figure out right scope-ids for the AR associated to the base station. If the 
system admin does not mind keeping track of coverage areas of all the base 
stations or changing the static configuration in the server at every change 
(even just IP address change of an AR), why should she/he open the door for 
cache contamination? It seems to me that the server approach is getting 
quite close to static configuration solution of L2-L3 mapping at each AR.

Regards,

Eunsoo

_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*.  
http://join.msn.com/?page=features/featuredemail

---

From: "Eunsoo Shim" <[email-masked]>
Date: Thu, 06 Mar 2003 15:04:46 -0500

Regards,

Eunsoo

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Thu, 6 Mar 2003 15:57:21 -0600

Hello Govind,

-----Original Message-----
Sent: Thursday, March 06, 2003 12:51 PM

Hi Ajoy,
My replies are embedded.
-Govind.

I meant every time cache times out, your proposed scheme (dycard) 

[Govind] Why will cache time out if there are frequent handovers. Plus once two ARs 
have recognized each other as CARs, why can't we setup a refresh procedure. 
Doesn't that take care of it?

AJOY-> Sure you can but I think you are complicating the protocol. 
The L2-> L3 mapping is a simple problem and we should keep it 
simple. 

Secondly, what do you mean "properly placing the server
with respect to the AR, we minimize the round trip delay". 

AJOY-> BTW, you do not need do this because L2->L3 mapping 
is initiated by link layer trigger that happens 
prior to L2 handoff. Hence, I do not see any reason 
to optimize this RTT. This is probably noto relevant 
in this context.

The scope-id reduces the cache contamination problem, the 

AJOY-> I am not sure just limiting the number of entries created by 
single MN will fix this problem. The attacker can use multiple MN to 
launch such attack. Whereas this type of attack is not possible 
when scope-id is used? 

AJOY-> You can configure the appropriately sized 
cache at AR if you know the number of ARs being covered 
by a given scope-id. This will also ensure that cache 
overflow would never happen. Hence, 
it will be impossible for an attacker to inject 
fake message to remove the useful entries from the 
AR. I do not see how will you achieve this in 
dycard?  

[snip]

Won't next handoff performed by dycard will

AJOY-> This is difficult to justify without proper data from 
real deployment or simulation.  Do have any real data to 
prove me otherwise? 

Could you please explain how dycard plans to avoid the problem of 
cache overflow? 

AJOY-> This does not fix the problem. The attacker can use multiple MN to launch 
such attack. Do you believe that service provider would deploy an 
such network that can be disabled by few malicious attackers? 

It is relatively inexpensive to provide redundancy of a
server that only does L2->L3 mapping. This function can be 
easily piggybacked upon existing high availability server 
platform. 

[Govind] I don't disagree with the fact that it might be relatively
inexpensive to provide reliability. 

AJOY-> OK 

But look at the cost in terms
of any benefit you receive from the server. It doesn't add up.
Plus, you have consistency issues to take care of when you have redundancy.
Instead, why not have a server at each AR then?

AJOY-> What is the cost? You can deploy the CARD server on existing 
server platform for example AAA platform. I do not see any extra cost
of doing this. 

AJOY-> Well you can. This means that every time you configure 
a router, you have to configure its scope-id. Whereas 
in former case, you can do it at once?

---

From: [email-masked]
Date: Thu, 6 Mar 2003 17:55:14 -0500

Hi Ajoy,
Comments embedded.
Regards,
-Govind.

[Govind] I don't think so at all. We need refreshing clearly to take care
of dyanmic capabilities. So why is it complicated? Ofcourse, you will have handovers
happening between them anyways which will also refresh state. So the main thing
would be to choose a lifetime that makes sure that at least one handover happens (if you use
soft state at ARs).. For example, if you keep the lifetime is 1 day. You would hope that
at least one handover (after the first ever handover) happens between the ARs in 1 day to 
refresh state. Which I think is pretty reasonable. In a real systems, handovers
will always happen so why not let the system learn from that? I agree that the lifetime is
something we need to think about and we have done some simulations to study the effect of
lifetimes on the cache hit ratio. 

[Govind] Well this comment was to answer your earlier statement
where you said that you can optimize this round trip time like you
said above.
Now you say it is not necessary. However, I think this minimization
of round trip is needed for the very reason that is mentioned 
in the DT draft.

[Govind] Consider that we limit one entry per MN. How many colluding
MNs would you need? 
We have done simulations on this and have seen that the
performance is not very much affected even when we limit the number of 
entries per MN, in a steady state system.

The colluding attack is even possible in the DT draft.
Consider this. A malicious MN keeps changing its identity and keeps sending
up "incorrect" L2 ids. The AR keeps asking the server for translation.
Isn't this a DoS attack waiting to happen. I think you have acknowledged this 
in the DT draft too. How does the scope-id prevent this?

[Govind] A similar argument can hold good also in a server
free approach. Clearly my point is, if you have no problems with DoS
attacks why will you ever contact the server again? 
Regarding dycard, I have explained how it is done in the earlier
part of this email and other emaisl.  However, whatever the DoS prevention
 mechanism, you wouldn't need servers.
[snip]

[Govind] We have implemented
dycard and we have gotten it to work with FMIPv6 in our local
test-bed. We have demonstrated dycard at Mobicom2002. We have done simulations
and a performance analysis on dycard. My observations are based on that. 
I hope you consider this "real data". Now on the flip side, do you have any
 "real data", as you put it, to quantify your statements  that you would need 
servers and a serverless approach will not work? Or the server based approach
 is better?

[snip]

[Govind] Can you define "few". I don't clearly think it is few. 
I would urge you read our draft to see whether you can do it with
 a few malicious MNs. We will be updating our draft in the next
couple of days. But the basic idea is what I have explained. 
[snip]

[Govind] Why should you add a server at all? 
DT approach is server + cache. Dycard is cache alone. We have shown that it 
works fine. 
You agreed yesterday about
the task (w.r.t to convincing the AAA WG) involved in putting it in a AAA platform.
At least thats the opinion I got from the WG mails. 
But the previous one is just a minor point, even if it were easy
 why have a server at all when it is not going to be used after sometime,
if you have taken care of  DoS attacks, and the network is in steady state. 

[Govind]   I don't think you would need to. 

But I think you are
missing the point. My main point is severs are unnecessary in a steady
state and as long as you take care of ensuring that DoS is difficult.

---

From: [email-masked]
Date: Thu, 6 Mar 2003 17:55:14 -0500

Hi Ajoy,
Comments embedded.
Regards,
-Govind.

[snip]

But I think you are

---

From: [email-masked]
Date: Thu, 6 Mar 2003 18:50:26 -0500

Hi guys:

DT hat off>

My "own analysis" shows that the only drawbacks of dyCard and DT protocol respectively, while using scope ID, are:

+ In dyCard, the first handoff is slow

+ In DT protocol, CARD server is needed

The DoS vulnerabilities are same for both approaches, i.e. same kind of DoS cache attack can be launched in both methods using slightly different techniques. This amounts to filling cache entries with all ARs in scope ID. However, in both approaches, this can be managed without scope ID if AAA asserted MN identity is used at AR to tag cache entries, e.g. by snooping  on NAI that is being passed between MN and AAA.

DT hat on>

DT does not have cost-benefit analysis for above tradeoff between dyCARD and DT protocol. So, in the interest of having at least one concrete protocol in 01 version, we decided to go for one approach. Now WG should provide input on this.

Hemant 

-----Original Message-----
From: ext [email-masked]
[mailto:[email-masked]]
Sent: Thursday, March 06, 2003 5:55 PM
To: [email-masked]; [email-masked]
Subject: RE: [Seamoby] Comments on DT CARD draft

Hi Ajoy,
Comments embedded.
Regards,
-Govind.

[snip]

But I think you are

---

From: [email-masked]
Date: Thu, 6 Mar 2003 18:50:26 -0500

Hi guys:

DT hat off>

DT hat on>

Hemant 

-----Original Message-----

Hi Ajoy,
Comments embedded.
Regards,
-Govind.

[snip]

But I think you are

---

From: [email-masked]
Date: Thu, 6 Mar 2003 18:52:24 -0500

Hi Daichi:

DT hat off>

-----Original Message-----
From: ext Daichi Funato [mailto:[email-masked]]
Sent: Thursday, March 06, 2003 6:45 PM
To: [email-masked]
Subject: Re: [Seamoby] Comments on DT CARD draft

Hi Eunsoo,

> 1) First of all, the dycard draft shows that CARD works without any central
> server. That is, we don't need the server for CARD.

In dycard, ARs need to be stateful for every MN just for CARD.
Most of the MN states in ARs would be useless since we just need one
MN report to build one CAR entry. Only a few MN may discover new CARs.

Hemant -> This not how dyCARD works. You should check the draft again. 

After CAR cache comes to an stable condition, the MN state maintenance
is in vain. Unfortunately, an AR never knows whether it is in the stable
condition or not. So, the AR needs to continue to maintain every MN's state.
I think this is waste of the resources and not worth doing such a 
useless MN state maintenance in every AR.

Hemant -> Again, this is now how dyCARD works.

If we take the server approach, we can keep ARs stateless.
This is much simpler than the dycard approach. (ARs may have some
states to avoid cache contamination, as James proposed before.
But, it is not like the dycard MN states, which are not to be used 
in most cases.)

So, I believe the server approach keeps the system simple and avoids
wasting the AR's resources for the useless MN state maintenance.

Regards,
Daichi

---

From: [email-masked]
Date: Thu, 6 Mar 2003 18:52:24 -0500

Hi Daichi:

DT hat off>

-----Original Message-----
From: ext Daichi Funato [mailto:[email-masked]]
Sent: Thursday, March 06, 2003 6:45 PM
To: [email-masked]
Subject: Re: [Seamoby] Comments on DT CARD draft

Hi Eunsoo,

Regards,
Daichi

---

From: [email-masked]
Date: Thu, 6 Mar 2003 19:29:15 -0500

Which thread? Which section? If you know quick pointer to it, please paste it here. - Hemant

-----Original Message-----
From: ext Singh Ajoy-ASINGH1 [mailto:[email-masked]]
Sent: Thursday, March 06, 2003 1:27 PM
To: Chaskar Hemant (NRC/Boston); Trossen Dirk (NRC/Boston);
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 05, 2003 3:19 PM
To: [email-masked]; [email-masked]
Subject: RE: [Seamoby] Comments on DT CARD draft

Hi,

Hemant  

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 05, 2003 2:37 PM
To: [email-masked]
Subject: FW: [Seamoby] Comments on DT CARD draft

Hi Ajoy,

some comments inline.

Regards,

Dirk

---

From: [email-masked]
Date: Thu, 6 Mar 2003 19:29:15 -0500

-----Original Message-----
From: ext Singh Ajoy-ASINGH1 [mailto:[email-masked]]
Sent: Thursday, March 06, 2003 1:27 PM
To: Chaskar Hemant (NRC/Boston); Trossen Dirk (NRC/Boston);
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 05, 2003 3:19 PM
To: [email-masked]; [email-masked]
Subject: RE: [Seamoby] Comments on DT CARD draft

Hi,

Hemant  

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 05, 2003 2:37 PM
To: [email-masked]
Subject: FW: [Seamoby] Comments on DT CARD draft

Hi Ajoy,

some comments inline.

Regards,

Dirk

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Mon, 10 Mar 2003 10:55:02 -0600

Hi Hemant,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, March 06, 2003 6:29 PM
To: Ajoy Singh; [email-masked]; [email-masked]
Subject: RE: [Seamoby] Comments on DT CARD draft

Which thread? Which section? If you know quick pointer to it, please paste
it here. - Hemant

-----Original Message-----
From: ext Singh Ajoy-ASINGH1 [mailto:[email-masked]]
Sent: Thursday, March 06, 2003 1:27 PM
To: Chaskar Hemant (NRC/Boston); Trossen Dirk (NRC/Boston);
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 05, 2003 3:19 PM
To: [email-masked]; [email-masked]
Subject: RE: [Seamoby] Comments on DT CARD draft

Hi,

AJOY-> Sure there is. But what is wrong in using AAA? 

AJOY-> this is not relevant in current discussion. But if 
ever decide to design CARD as an extension to DNS protocol 
then I do not see any reason for not re-using the DNS
security mechanism. But why do you think otherwise?

Hemant  

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 05, 2003 2:37 PM
To: [email-masked]
Subject: FW: [Seamoby] Comments on DT CARD draft

Hi Ajoy,

some comments inline.

Regards,

Dirk

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Mon, 10 Mar 2003 10:55:02 -0600

Hi Hemant,

-----Original Message-----
From: ext Singh Ajoy-ASINGH1 [mailto:[email-masked]]
Sent: Thursday, March 06, 2003 1:27 PM
To: Chaskar Hemant (NRC/Boston); Trossen Dirk (NRC/Boston);
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 05, 2003 3:19 PM
To: [email-masked]; [email-masked]
Subject: RE: [Seamoby] Comments on DT CARD draft

Hi,

Hemant  

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 05, 2003 2:37 PM
To: [email-masked]
Subject: FW: [Seamoby] Comments on DT CARD draft

Hi Ajoy,

some comments inline.

Regards,

Dirk

---

From: [email-masked]
Date: Mon, 10 Mar 2003 12:03:48 -0500

Hi Ajoy: 

There is nothing wrong with AAA. The point is that AAA functionality is not central to CARD service. In fact, they are quite independent functionality wise, and hence, CARD server should be treated as logical entity and people can integrate it with whatever server they want it to be. Then, CARD service should be usable even if there is no AAA server of one's choice present in some network. These integration tasks can be taken as separate drafts in collaboration with respective server WGs.

Hemant

-----Original Message-----
From: ext Singh Ajoy-ASINGH1 [mailto:[email-masked]]
Sent: Monday, March 10, 2003 11:55 AM
To: Chaskar Hemant (NRC/Boston); Singh Ajoy-ASINGH1; Trossen Dirk
(NRC/Boston); [email-masked]
Subject: RE: [Seamoby] Comments on DT CARD draft

Hi Hemant,

-----Original Message-----
From: ext Singh Ajoy-ASINGH1 [mailto:[email-masked]]
Sent: Thursday, March 06, 2003 1:27 PM
To: Chaskar Hemant (NRC/Boston); Trossen Dirk (NRC/Boston);
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 05, 2003 3:19 PM
To: [email-masked]; [email-masked]
Subject: RE: [Seamoby] Comments on DT CARD draft

Hi,

Hemant  

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 05, 2003 2:37 PM
To: [email-masked]
Subject: FW: [Seamoby] Comments on DT CARD draft

Hi Ajoy,

some comments inline.

Regards,

Dirk

---

From: [email-masked]
Date: Mon, 10 Mar 2003 12:03:48 -0500

Hi Ajoy: 

Hemant

-----Original Message-----
From: ext Singh Ajoy-ASINGH1 [mailto:[email-masked]]
Sent: Monday, March 10, 2003 11:55 AM
To: Chaskar Hemant (NRC/Boston); Singh Ajoy-ASINGH1; Trossen Dirk

Hi Hemant,

-----Original Message-----
From: ext Singh Ajoy-ASINGH1 [mailto:[email-masked]]
Sent: Thursday, March 06, 2003 1:27 PM
To: Chaskar Hemant (NRC/Boston); Trossen Dirk (NRC/Boston);
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 05, 2003 3:19 PM
To: [email-masked]; [email-masked]
Subject: RE: [Seamoby] Comments on DT CARD draft

Hi,

Hemant  

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 05, 2003 2:37 PM
To: [email-masked]
Subject: FW: [Seamoby] Comments on DT CARD draft

Hi Ajoy,

some comments inline.

Regards,

Dirk

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Mon, 10 Mar 2003 11:11:31 -0600

Hi Govind, 

-----Original Message-----
Sent: Thursday, March 06, 2003 4:55 PM

Hi Ajoy,
Comments embedded.
Regards,
-Govind.

This is difficult to justify without proper data from 
real deployment or simulation.  Do have any real data to 
prove me otherwise? 

[Govind] We have implemented
dycard and we have gotten it to work with FMIPv6 in our local
test-bed. We have demonstrated dycard at Mobicom2002. We have done
simulations
and a performance analysis on dycard. My observations are based on that. 
I hope you consider this "real data". Now on the flip side, do you have any
 "real data", as you put it, to quantify your statements  that you would
need 
servers and a serverless approach will not work? Or the server based
approach
 is better?

AJOY-> We have also implemented some sort of server approach and saw it 
working. My question was more towards validating your 
protocol with real world handoff data.

BTW, you do not need do this because L2->L3 mapping 
is initiated by link layer trigger that happens 
prior to L2 handoff. Hence, I do not see any reason 
to optimize this RTT. This is probably noto relevant 
in this context.

[Govind] Well this comment was to answer your earlier statement
where you said that you can optimize this round trip time like you
said above.
Now you say it is not necessary. 

AJOY-> I stated this but on second thought I do not 
see any reason to optimize the RTT given that L2->L3 
cache is built prior to any handoff and is not 
in critical path of handoff.

However, I think this minimization
of round trip is needed for the very reason that is mentioned 
in the DT draft.

AJOY-> To be honest, I do not see any need for this and probably we should 
remove such claim from DT draft unless you can provide 
some valid reason for keeping this in DT draft.
_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Mon, 10 Mar 2003 11:11:31 -0600

Hi Govind, 

-----Original Message-----

Hi Ajoy,
Comments embedded.
Regards,
-Govind.

---

From: [email-masked]
Date: Mon, 10 Mar 2003 12:15:30 -0500

Ajoy,
Just curious.
Regarding AAA:
Just because it can be done, it doesn't need to be done. I think we don't need to invent a problem
and then solve it. I think there is a trust relationship existing between routers of the same
domain already. Isn't this true?. Routers don't forward packets arbitrarily. 
 We can use those keys or derive keys from that existing trust relationship right. 
Therefore, why do you want to introduce a new scheme to distribute keys, that too specifically 
for CARD?
I don't think we need special trust relationship, solely for the purpose of CARD. 
As Hemant pointed out, if we have shared secrets between routers of the same domain, then we are through is it not. I have heard in many routing networks, keys are put in manually in routers as part of their configuration, though I am not claiming that this is the only way it is done.

Correct me if I'm wrong in any of my above staements.
Regards,
Govind.

-----Original Message-----
From: ext Singh Ajoy-ASINGH1 [mailto:[email-masked]]
Sent: Monday, March 10, 2003 11:55 AM
To: Chaskar Hemant (NRC/Boston); Singh Ajoy-ASINGH1; Trossen Dirk

Hi Hemant,

-----Original Message-----
From: ext Singh Ajoy-ASINGH1 [mailto:[email-masked]]
Sent: Thursday, March 06, 2003 1:27 PM
To: Chaskar Hemant (NRC/Boston); Trossen Dirk (NRC/Boston);
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 05, 2003 3:19 PM
To: [email-masked]; [email-masked]
Subject: RE: [Seamoby] Comments on DT CARD draft

Hi,

Hemant  

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 05, 2003 2:37 PM
To: [email-masked]
Subject: FW: [Seamoby] Comments on DT CARD draft

Hi Ajoy,

some comments inline.

Regards,

Dirk

---

From: [email-masked]
Date: Mon, 10 Mar 2003 12:15:30 -0500

Ajoy,
Just curious.
Regarding AAA:

-----Original Message-----
From: ext Singh Ajoy-ASINGH1 [mailto:[email-masked]]
Sent: Monday, March 10, 2003 11:55 AM
To: Chaskar Hemant (NRC/Boston); Singh Ajoy-ASINGH1; Trossen Dirk

Hi Hemant,

-----Original Message-----
From: ext Singh Ajoy-ASINGH1 [mailto:[email-masked]]
Sent: Thursday, March 06, 2003 1:27 PM
To: Chaskar Hemant (NRC/Boston); Trossen Dirk (NRC/Boston);
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 05, 2003 3:19 PM
To: [email-masked]; [email-masked]
Subject: RE: [Seamoby] Comments on DT CARD draft

Hi,

Hemant  

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 05, 2003 2:37 PM
To: [email-masked]
Subject: FW: [Seamoby] Comments on DT CARD draft

Hi Ajoy,

some comments inline.

Regards,

Dirk

---

From: [email-masked]
Date: Mon, 10 Mar 2003 12:29:37 -0500

Ajoy,

[Govind] I don't have access to real world handover data. Maybe if you do,
you could provide it to us and we can test it out. We have done
simulations as best as we could and our results are based on that.
I guess this is the approach taken by many to do performance analysis.

The point was that the server was useless after bootstrap. I guess this was
 agreed by one of your DT members too.
 Another point was that the DT approach is susceptible to attacks 
detailed out in earlier mails. You haven't said anything that helps
 me reverse my opinion on any of these issues. 

[Govind] I have explained in my earlier mails about why this is useful. So
have others. You can never claim that the cache, in the DT scheme is built 
prior to handovers. It clearly depends on the order the MN reports. 
I think you should read prior threads that explains these points quite
clearly. Therefore the RTT is clearly important. 

Having said that, if have subsequent handovers wherein the mappings are in cache
you wouldn't need the server at all.
_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: [email-masked]
Date: Mon, 10 Mar 2003 12:29:37 -0500

Ajoy,

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Mon, 10 Mar 2003 11:45:41 -0600

Govind,

AJOY->  I have not seen any objective reply from any one 
so far. If there is sufficient overlap between neighboring AR, 
then it is safe to assume that cache will be built prior to L3 handoff. 
Without sufficient overlap, it is difficult to assume 
any seamless handoff between neighboring ARs.

Regards,
Ajoy 

-----Original Message-----
Sent: Monday, March 10, 2003 11:30 AM

Ajoy,

Having said that, if have subsequent handovers wherein the mappings are in
cache
you wouldn't need the server at all.
_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Mon, 10 Mar 2003 11:45:41 -0600

Govind,

Regards,
Ajoy 

-----Original Message-----

Ajoy,