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