CARD Designteam A. Singh, D. Funato, H. Chaskar, M. Liebsch Candidate Access Router Discovery Protocol <draft-ietf-seamoby-card-protocol-01.txt> Overview of CARD Protocol Design And Pending Issues 20th March 2003 CARD Designteam A. Singh, D. Funato, H. Chaskar, M. Liebsch

Intro The draft delivered from the design team, covers … Description of CARD protocol functions. Proposal on 2 operational modes to keep CARD protocol design and its deployment flexible. Proposes server based CARD protocol for network assisted mode. Proposes server less MN-Orchestrated CARD. Proposes protocol messages encoding for AR-MN, AR-Server and AR-AR interfaces. Include security consideration discussion.

WG Comments and Issues Support of AP authorization at AR (Issue-1) AP authorization is not supported in the current draft. Does this belong to the scope of the CARD protocol?

WG Comments Issues Characteristics of server based approach (Issue-2) Server based approach is able to provide seamless handoff even if the CAR information is not available in the current AR cache. The server provides in built authorization function by using scope-id. It introduces additional single point of failure in an access network, but this can be eliminated if CARD server function can be integrated with existing server e.g., AAA server. Scope-id can be used to minimize or avoid the cache contamination issues. Single server is easier to configure and manage compared to multiple AR(s).

WG Comments and Issues Characteristics of handover based approach (Issue-2) No server required. The seamless handoff not possible until AR cache is populated. The AR cache is only updated when MN performs active L3 handoff. Additional protocol complexity for validating information provided by MN.

Denial of Service Attack (Issue-3) Possible to minimize by rate limiting the number of AR-server requests as well as MN-AR requests.

WG Comments and Issues Cache Contamination (Issue-4) A proposal for solution using scope id Scope-1 = {AR(y), AR(x)} Scope-2 = {AR(x), AR(z)} AR(x) AR(z) Scope 1 Scope 2 Scope 1 Scope 2 Server AR(y)

WG Comments and Issues Piggybacking CARD options on FMIPv6 messages and use of “P” bit (Issue-5) DT draft optionally allows the piggybacking of MN-AR CARD options on FMIP6 messages. To get the benefit of the piggybacking, the FMIPv6 implementation would need to process the CARD options. Do we need to have some text to clarify this in the FMIPv6 draft? Do we need to restrict piggybacking to FMIPv6, or should it be supported also with Router Solicitation/Advertisement ? The “P” bit is used to discover the piggybacking capability of CARD communication peers.

WG Comments and Issues What is the function of lifetime flag (Issue-6) The lifetime flag supports indication of dynamic or static capabilities. Editorial Issues 7-10 These issues will be addressed in the next revision of the draft. IPR Issues There may be potential IPRs on some of CARD optimizations? Do we need to keep the base draft IPR free or it is fine have IPR on the draft?

Backup Slides

MN-Orchestrated CARD Timing Diagram

Network Assisted CARD Timing Diagram After cache timeout

WG Comments and Issues Cache Contamination (Issue-4) To avoid the problem of cache contamination, ARs of a given domain need to be grouped in a set of scopes in such a way that each scope would only consist up of ARs that are neighbors (e.g., scope-1 will contain AR(a) and AR(b) only if AR(a) and AR(b) are neighbors). The boarder AR would belong to more than one scopes. For example, AR(X) would belong to two scopes if AR(X) has neighborhood relation with AR(Y) and AR(Z) , but AR(Y) and AR(Z) are not neighbors. The server would resolve the L2 address of an AP to CAR IP address only if following two conditions are met: AP is attached to the CAR. Both requesting AR and the CAR are the members of the same pre-configured scope. The above approach would ensure that any attempt to resolve an invalid AP ID by an AR that does not belong to its neighboring AR will be rejected by the CARD server.