IETF Seamoby Working Group CARD Design Team Internet Draft Marco Liebsch Ajoy Singh (Editors) Hemant Chaskar Daichi Funato draft-ietf-seamoby-card-protocol-01.txt Expires: September 2003 March 2003 Candidate Access Router Discovery Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt To view the list of Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract To enable seamless IP-layer handover of a mobile node (MN) from one access router (AR) to another, the MN is required to discover the identities of candidate ARs (CARs) for handover, along with their capabilities, prior to the initiation of the IP-layer handover. Depending upon the mode of operation, the current AR may or may not be involved in the CAR discovery process. The act of discovery of CARs has two aspects to it: Identifying the IP addresses of the CARs and finding the capabilities of those CARs. This process is called "candidate access router discovery" (CARD). At the time of IP-layer handover, that CAR, whose capabilities are a good match to the preferences of the MN, may be chosen as the target AR (TAR) for handover. This draft describes a solution to perform CARD. CARD Design Team Expires û September 2003 [Page 1] Internet-Draft Candidate Access Router Discovery March 2003 TABLE OF CONTENTS 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. CARD Protocol Functions . . . . . . . . . . . . . . . . . . . . 4 3.1 Reverse Address Translation . . . . . . . . . . . . . . . . 4 3.2 Discovery of CAR Capabilities . . . . . . . . . . . . . . . 5 4. CARD Protocol Operation . . . . . . . . . . . . . . . . . . . . 6 4.1 MN-Orchestrated CARD. . . . . . . . . . . . . . . . . . . . 6 4.2 Network-Assisted CARD . . . . . . . . . . . . . . . . . . . 7 5. Protocol Messages . . . . . . . . . . . . . . . . . . . . . . .12 5.1 CARD Messages for the interface MN - AR . . . . . . . . . .12 5.1.1 CARD Main Header Format. . . . . . . . . . . . . . . .12 5.1.2 CARD Options Format . . . . . . . . . . . . . . . . . .14 5.1.2.1 CARD Request Option .. . . . . . . . . . . . . . .15 5.1.2.2 CARD Reply Option .. . . . . . . . . . . . . . . .15 5.1.3 Sub-Options Format .. . . . . . . . . . . . . . . . . .16 5.1.3.1 L2-ID Sub-Option . . . . . . . . . . . . . . . . .17 5.1.3.2 Preferences Sub-Option . . . . . . . . . . . . . .17 5.1.3.3 Requirements Sub-Option .. . . . . . . . . . . . .18 5.1.3.4 Capability Container Sub-Option. . . . . . . . . .18 5.1.3.5 Address Sub-Option . . . . . . . . . . . . . . . .19 5.1.4 CARD AVP encoding . . . . . . . . . . . . . . . . . . .20 5.2 CARD Messages for the interface between ARs (AR - AR) . . .21 5.2.1 Protocol transport (AR-AR). . . . . . . . . . . . . . .21 5.2.2 Protocol main header. . . . . . . . . . . . . . . . . .21 5.2.3 Protocol payload types. . . . . . . . . . . . . . . . .22 5.3 CARD Messages for the interface between an AR and the CARD server . . . . . . . . . . . . . . . . . . .22 5.3.1 Protocol transport (AR-Server function) . . . . . . . .22 5.3.2 Protocol main header. . . . . . . . . . . . . . . . . .22 5.3.3 Protocol payload types. . . . . . . . . . . . . . . . .23 5.4 Overview on sub-options'/payload types' usage . . . . . . .24 6. Security Considerations . . . . . . . . . . . . . . . . . . . .24 6.1 Security Associations . . . . . . . . . . . . . . . . . . .24 6.2 DoS Attack . . . . . . . . . . . . . . . . . . . . . . . .24 6.3 CAR Cache Contamination . . . . . . . . . . . . . . . . . .25 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . .26 8. References . . . . . . . . . . . . . . . . . . . . . . . . . .26 9. Authors' addresses . . . . . . . . . . . . . . . . . . . . . .27 10. IPR Statements. . . . . . . . . . . . . . . . . . . . . . . . .27 11. Copyright Notice . . . . . . . . . . . . . . . . . . . . . . .28 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . .28 CARD Design Team Expires û September 2003 [Page 2] Internet-Draft Candidate Access Router Discovery March 2003 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. 1. Introduction IP mobility protocols enable mobile nodes (MNs) to execute IP-level handover between access routers (ARs). CAR discovery (CARD) enables acquiring information about the ARs that are candidates (CARs) for the MN's handover. In future wireless networks, there will be cases when a MN has a choice of performing IP-level handover to different CARs. The MN would then choose one of them as a target access router (TAR) for handover, based on a match between a MN's requirements and CARs' capabilities. The MN requires some means of obtaining information about the CARs so that the best decision about the TAR can be made. The CARD protocol enables this. The problem statement and requirements for CARD are discussed in [2] and [3] respectively. In this draft, we describe a solution to perform CARD. We begin by describing two main functions of the CARD protocol. Then, we describe two modes of protocol operation that we think cover most of the important handover scenarios. Finally, we describe the messages and protocol operation of MN-AR, AR-AR and AR- server interfaces of the CARD protocol. 2. Terminology Mobile Node (MN) A Mobile Node is an IP host capable of moving its point of attachment to the Internet. Access Point (AP) A radio transceiver by which a MN obtains Layer 2 connectivity with the wired network. Access Router (AR) An IP router residing in an access network and connected to one or more APs. An AR offers IP connectivity to MNs. CARD Design Team Expires û September 2003 [Page 3] Internet-Draft Candidate Access Router Discovery March 2003 Candidate AR (CAR) An AR to which a MN has a choice of performing IP-level handover. This implies that the MN has the right radio interface to connect to an AP that is served by this AR, as well as the coverage of this AR overlaps with that of the AR to which the MN is currently attached to. Capability of AR A characteristic of the service offered by an AR that may be of interest to a MN when the AR is being considered as a handover candidate. L2 ID Identifier of an AP, that uniquely identifies that AP. For example, in 802.11 PCF, this could be a MAC address of an AP. Target AR (TAR) An AR with which the procedures for the MN's IP-level handover are initiated. The TAR is selected after running a TAR Selection algorithm that takes into account the capabilities of CARs, preferences of the MN and any other local policies. 3. CARD Protocol Functions A CARD protocol accomplishes the following functions. 3.1 Reverse Address Translation This functionality refers to mapping the L2 ID of a new AP that the MN can hear, to the IP address of the CAR that connects to the new AP. In cases where the MN can acquire IP connectivity with CARs prior to making handover decisions, this functionality is trivially realized. However, if a MN can only listen to L2 IDs of new APs prior to making decision about IP-level handover to CARs, a special mechanism is needed for reverse address translation. This could be realized via cached information in the MN. Alternatively, the MN may seek the help of the current AR, wherein the MN sends L2 IDs of new APs to the current AR and expects it to resolve the L2 IDs to the IP address of CARs. CARD Design Team Expires û September 2003 [Page 4] Internet-Draft Candidate Access Router Discovery March 2003 Note: In some networks, such as cellular networks, link-layer technology may be capable of delivering the L2 ID of the new AP to the current AR. In this case the current AR can send CAR address information to a MN without receiving an explicit request for reverse address translation before. Finally, few comments are in order. First, note that the new AR can be in a different subnet than that of the current AR (even far away from the current AR in terms of IP hops). Second, when the MN delivers L2 IDs of APs to the reverse address translation module, implicit is the assumption that MN is satisfied with the signal strength of the new APs. Lower level criteria such as signal strength are out of scope of capabilities that we refer to in the CARD protocol. Finally, establishment of a L2 security association between a MN and individual AP(s) is assumed to be performed in accordance with the relevant L2 mechanism, and is outside the scope of the CARD protocol. 3.2 Discovery of CAR Capabilities Information about capabilities of CARs can assist the MN in making optimized handover decisions. This capability information serves as input to the TAR selection algorithm. Some of the capability parameters of CARs can be static, some others can change only on a long time scale, while the rest can be highly dynamic. Definition of capabilities is out of scope of the CARD protocol design. Encoding rules for capabilities and the format of a capability container for capability transport are specified in section 5. If the MN can establish robust IP connectivity with CARs before making handover decisions, the MN can directly ask for capability information from the CARs. Alternatively, certain capabilities may be periodically transmitted over downlink channels. On the other hand, if the MN cannot establish IP connectivity with CARs before making handover decisions, the current AR can assist the MN in retrieving capability information from the CAR. CARD Design Team Expires û September 2003 [Page 5] Internet-Draft Candidate Access Router Discovery March 2003 4. CARD Protocol Operation There are two modes of CARD protocol operation, namely the MN- orchestrated CARD and the network-assisted CARD. These are described below. 4.1 MN-Orchestrated CARD In this mode, the MN performs CARD without any assistance from the current AR. For this, the MN needs to have a capability to establish IP connectivity with a CAR, while still being connected to its current AR at IP level. In this case, the MN by itself discovers capabilities of a CAR over the IP connectivity it establishes with the CAR. The MN then performs TAR selection. Figure 1 describes the timing diagram of MN-Orchestrated CARD. In this mode of operation while being connected with current AR, a MN establishes the IP layer connectivity with the serving AR of the newly discovered AP and then obtains the capabilities from it. The MN discovers the new access point ID during the periodic L2 scan of the non-IP-connected interfaces. Subsequently, the MN requests the capabilities of the newly discovered CAR by sending MN-AR CARD Request ICMP options. The CAR in turn returns the capabilities to the MN by sending AR-MN CARD Reply ICMP options. The capabilities are encoded as sub-options of the AR-MN CARD Reply ICMP option. The MN-AR CARD Request and the AR-MN CARD Reply ICMP options are either piggybacked upon ongoing Router Advertisement/Solicitation messages or sent as part of new ICMP messages. Section 5 describes the format of the ICMP options as well as the header of the new ICMP message required for delivering CARD options in stand-alone mode. CARD Design Team Expires û September 2003 [Page 6] Internet-Draft Candidate Access Router Discovery March 2003 MN current AR CAR1 CAR2 | Existing | | | | IP Connectivity | | | |<------------------->| | | | | | | | <~ ~ ~ L2-SCAN (1) | | | | | | | | Establish IP connectivity (2) | | |<--------------------------------------->| | | | | | | | | | | | | | | | | | | MN-AR CARD Request ICMP Option (3) | | |---------------------------------------->| | | | | | | | | | | AR-MN CARD Reply ICMP Option (4) | | |<----------------------------------------| | | | | | | | | | | | | | | Establish IP Connectivity (2) | |<------------------------------------------------------------->| | | | | | | | | | MN-AR CARD Request ICMP Option (3) | |-------------------------------------------------------------->| | | | | | | | | | AR-MN CARD|Reply ICMP Option (4) | |<------------------------------------------------------------- | | | | | | | | | Figure 1: MN Orchestrated CARD timing diagram 4.2 Network-Assisted CARD This mode caters to the case where the MN has IP layer connectivity with the current AR only. However, the MN is capable of listening to the L2 beacons from the neighboring AP(s) and thereby deducing their L2 ID(s). For example, 802.11 families of MN or cellular handsets with the mobile assisted handover capability are capable of performing the aforementioned functions. CARD Design Team Expires û September 2003 [Page 7] Internet-Draft Candidate Access Router Discovery March 2003 The MN discovers the L2 ID of an AP during L2 scan process. The MN passes on one or more L2 ID(s) to its current AR and the current AR resolves it to the IP address of the CAR. For this, the current AR first checks if the mapping is available locally in its cache. If not, the current AR queries a CARD server with the said L2 ID and the CARD server in turn returns the IP address of the CAR to the current AR. The current AR then directly contacts the CAR and performs capability discovery with it. The current AR then passes on the IP address of the CAR and its capabilities to the MN. When the handoff is imminent, the MN runs the TAR selection algorithm to choose one AR as a target for handover from the set of CARs and their capabilities it has learned through the CARD protocol. The network-assisted CARD protocol operation is illustrated in Figure 2 below. +----------+ +------------>| CARD |<-------------+ |+------------| Server |-------------+| || +----------+ || || || || ~~~~~~~~~~~ || (3)AR-Server||(4)AR-Server{ } || (0) CARD CARD || CARD { } ||Registration Request || Reply { IP Cloud } ||Request/Reply || { } || || { } || |V ~~~~~~~~~~~ V| +---------+ (5)AR-AR CARD Request +-----+-----+ | Current |------------------------->| CAR | CAR | | AR |<-------------------------| 1 | 2 | +---------+ (6)AR-AR CARD Reply +-----+-----+ ^ | | | (2)MN-AR | |(7)MN-AR | | CARD | | CARD | | Request| V REPLY +---+ +---+ +--------------+ (1) AP1 L2 ID +--|AP1| |AP2| | Mobile |<---------------------+ +---+ +---+ | Node |<--------------------------------| +--------------+ (1) AP2 L2 ID Figure 2: CARD Protocol Overview (Network Assisted Mode) CARD Design Team Expires û September 2003 [Page 8] Internet-Draft Candidate Access Router Discovery March 2003 Note on TAR selection at current AR: Throughout this draft, we have assumed that TAR selection is always performed on the MN. However, there was also interest in the working group to enable TAR selection on the current AR. In this case, there is a need to inform the current AR about its requirements, so that the current AR can make appropriate choice of a TAR from the set of CARs and their capabilities. TAR selection on the current AR has not been discussed in this draft as the working group consensus is pending on it. Note on capability pre-filtering: In case of implementing TAR selection in the MN, CAR capabilities are required to be conveyed to the MN as input to the TAR selection algorithm. The following approaches can be used for this purpose: (A) Providing full capability set for TAR selection The MN receives the full set of capability information from the sender of capabilities. In the MN orchestrated mode, this sender is the CAR, while in the network assisted mode it is the current AR. Since no MN preferences for capabilities are to be transmitted to the current AR, but the full set of capability information is to be conveyed to the MN, this approach is "uplink optimized". (B) Providing partial capability set for TAR selection The MN informs the sender about the capabilities of interest. In the MN orchestrated mode, this sender is the CAR, while in the network assisted mode it is the current AR. In response, the sender sends a subset of the CARs' capabilities to the MN to be used as input for the TAR selection function. Since this approach considers a reduced set of capabilities to be sent to the MN but assumes a set of preferences to be sent previously to the current AR, this approach is "downlink optimized". As an enhancement to approach (B), context transfer (CT) framework [4,5] can help to avoid sending the MN's preferences for pre- filtering the capability information to the current AR for each handover event. After the MN's preferences for pre-filtering have been provided to the current AR once, this information can be transferred to the selected TAR by means of CT mechanisms. CARD Design Team Expires û September 2003 [Page 9] Internet-Draft Candidate Access Router Discovery March 2003 Figure 3 describes the timing diagram of the Network Assisted CARD. It is to be noted that in Figure 3, the CAR registration process is not shown in critical path of the CARD discovery process. The CARs register with the CARD server when the CAR is initialized or when status of some of the L2 AP associated with the CAR or the capability associated with the CAR change. The CAR MAY also periodically register with the CARD server to update its capability as well as the list of the current AP(s) being supported by it. The CAR discovery process is initiated as soon as a mobile node discovers the link layer ID of nearby AP during periodic L2 scan process. The MN sends L2 ID of the AP to the connected AR in MN-AR CARD Request ICMP option to obtain the identity and the capabilities of the associated CAR. If not available in local cache, the current AR subsequently sends AR-Server CARD Request message to the CARD server to resolve the IP address of the serving AR of the newly discovered AP. The CARD server then resolves the link layer ID to the IP address of the CAR and returns the identity of the CAR as well as available static capabilities to the requesting AR in the Server-AR CARD Reply message. The capabilities are encoded according to the encoding rule described in section 5.1.4 and conveyed in a capability container attached to the Server-AR CARD Reply message. Upon receipt of the Server-AR CARD Reply message, the current AR extracts the IP address of the CAR and in turn requests remaining capabilities by sending AR-AR CARD Request message to the CAR. The CAR subsequently conveys its capabilities to the requesting AR in AR-AR CARD Reply message. Upon receipt of the AR-AR CARD Reply message, the current AR caches the capabilities as well as the L2-L3 mapping information in local cache and encodes the capabilities as the sub-options of the AR-MN CARD Reply ICMP options. The AR-MN CARD reply ICMP options are conveyed to the Mobile Node either as piggybacked options of an outgoing FMIP Proxy Router Advertisement message or the options of the new AR-MN CARD ICMP message. The format of the new MN-AR ICMP message is described in section 5.1. CARD Design Team Expires û September 2003 [Page 10] Internet-Draft Candidate Access Router Discovery March 2003 MN current AR CARD Server CAR | | | (Candidate | | | Access | | | Router) | | | | | | | Registration Req | | | |<--------------------| | <~ ~ ~ L2-SCAN (1) | | Registration Reply | | | |-------------------->| | | | | | | | | |MN-AR CARD Req ICMP | | | | Option (2) | | | |-------------------->| | | | | AR-Server | | | | CARD Req (3) | | | |------------------>| | | | Server-AR | | | | CARD Reply (4) | | | |<----------------- | | | | | | | | AR-AR CARD Req (5) | | |---------------------------------------->| | | | | | | AR-AR CARD Reply (6) | | |<----------------------------------------| | | | | | AR-MN CARD Reply | | | | ICMP Options (7) | | | |<--------------------| | | | | | | | | | | | | | | | | | | | | | | | | | | Figure 3: Network Assisted CARD timing diagram CARD Design Team Expires û September 2003 [Page 11] Internet-Draft Candidate Access Router Discovery March 2003 5. Protocol Messages 5.1 CARD Messages for the interface MN - AR 5.1.1 CARD Main Header Format Hosts and Access Routers use the CARD ICMP-type main header when CARD protocol messages, to be exchanged between a MN and an AR, cannot be piggybacked by another outgoing ICMP-type message, as for example for Fast-MIPv6 purposes. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- IP Fields: Source Address: An IP address assigned to the sending interface. Destination Address: An IP address assigned to the receiving interface. Hop Limit: 255 Authentication Header: The sender SHOULD include the Authentication Header, based on the previously established Security Association between the sender and the receiver. ICMP Fields: Type T.B.A (To be assigned) Code 0 Checksum The ICMP checksum. Reserved This field is unused. It MUST be initialized with zero by the sender and MUST be ignored by CARD Design Team Expires û September 2003 [Page 12] Internet-Draft Candidate Access Router Discovery March 2003 the receiver. Valid Options: CARD Request: The CARD Request allows entities to request CARD specific information. To process the CARD Request message on the receiver side, further sub-option must be carried with the message, serving as input for the reverse address translation function and/or capability discovery function. CARD Reply: The CARD Reply carries parameters, previously requested with a CARD Request, back to the sender of the CARD Request. Further sub-options will be associated with the CARD Reply message. Valid Sub-Options: Layer-2 ID: The Layer-2 ID carries information about the type of access point as well as the Layer-2 address of the access point associated with the CAR whose IP address and capability information is to be resolved. Preferences sub-option: The Preferences sub-option carries information about attributes of interest for the requesting entity. Attributes are encoded according to the AVP encoding rule as described in section 5.1.4. For settings of AVP Code and Data field, please see section 5.1.3.2. This sub-option is used only in case of performing capability pre- filtering on ARs, which is referred to as option to network assisted CARD and is described in section 4.2. Requirements: The Requirements sub-option carries information about attribute-value pairs required for TAR selection to the entity performing TAR selection. Currently, only the MN performs TAR selection, hence, this sub-option is not used so far, as long as working group consensus on this issue is pending (please refer to section 4.2). Attribute-value pairs are encoded according to the AVP encoding rule as described in section 5.1.4. For settings of AVP Code and Data field, please see section 5.1.3.3. CARD Design Team Expires û September 2003 [Page 13] Internet-Draft Candidate Access Router Discovery March 2003 Capability container: The Capability container sub-option carries information about a single CAR's capabilities. The format of this sub-option is described in section 5.1.3.4. Address: The Address sub-option carries information on a resolved AR's IP address. The associated AR is indicated either as a CAR or as a selected TAR, depending on the protocol operation. 5.1.2 CARD Options Format All options are of the form: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type: 8-bit identifier of the type of option. The options defined in this document are: Option Name Type -------------------------------------------------- MN-AR CARD Request T.B.A MN-AR CARD Reply T.B.A Length: 8-bit unsigned integer. The length of the option including the type and length fields in units of octets. The value 0 is invalid. CARD Design Team Expires û September 2003 [Page 14] Internet-Draft Candidate Access Router Discovery March 2003 5.1.2.1 CARD Request Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |P| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Options +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - Fields: Type: T.B.A Length: The length of the option in units of octets, including the type and length fields as well as sub-options. Flags: P-bit: Indicates Piggybacking capability of the sender. Remaining flags are reserved and MUST be initialized with 0. Sequence Number: Allows correlating requests with replies. Valid Sub-Options: - L2-ID sub-option - Preferences sub-option - Requirements sub-option 5.1.2.2 CARD Reply Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |P| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Options +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - CARD Design Team Expires û September 2003 [Page 15] Internet-Draft Candidate Access Router Discovery March 2003 Fields: Type: T.B.A Length: The length of the option in units of octets, including the type and length fields as well as sub-options. Flags: P-bit: Indicates piggybacking capability of the message sender. Remaining flags are reserved and MUST be initialized with 0. Sequence Number: Allows correlating requests with replies. Valid Sub-Options: - L2-ID sub-option - Capability Container sub-option - Address sub-option 5.1.3 Sub-Options Format All Sub-Options are of the form: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-Option Type|Sub-Option Len | Sub-Option Data . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Option Type: 8-bit identifier of the type of option. The Sub-Options defined in this document are: Sub-Option Name Type -------------------------------------------- L2-ID T.B.A Preferences T.B.A Requirements T.B.A Capability Container T.B.A Address T.B.A Option-Length: 8-bit unsigned integer. The length of the option including the type and length fields in CARD Design Team Expires û September 2003 [Page 16] Internet-Draft Candidate Access Router Discovery March 2003 units of octets. The value 0 is invalid. 5.1.3.1 L2-ID Sub-Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-Option Type|Sub-Option Len | Context-ID | L2-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2-ID . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - Sub-Option Type: T.B.A Sub-Option Length: Length of the Sub-Option (including type and length Fields as well as L2 type indicator) in units of 8 octets. Context-ID: Identifies matching L2-ID, IP address and capability information, when coming with separated sub-options. L2 type: Indicates the interface type (Ethernet, IEEE802.11b, ...). L2-ID: The variable length layer-2 identifier of an Individual CAR's Access Point. (bit and byte ordering specifics?) 5.1.3.2 Preferences Sub-Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-Option Type|Sub-Option Len | Preferences +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Option Type: T.B.A Sub-Option Length: Length of the Sub-Option (including type and length fields) in units of 8 octets. Preferences: AVP encoded preferences (see section 5.1.4). CARD Design Team Expires û September 2003 [Page 17] Internet-Draft Candidate Access Router Discovery March 2003 AVPs MUST be encoded according to the rule described in section 5.1.4. Only ATTRIBUTES (AVP Code) need to be set. VALUE indicator (Data) will not be processed and can be omitted. 'AVP Length' field is to be set appropriately. 5.1.3.3 Requirements Sub-Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-Option Type|Sub-Option Len | Requirements +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Option Type: T.B.A Sub-Option Length: Length of the Sub-Option (including type and length fields) in units of octets. Requirements: AVP encoded requirements (see section 5.1.4) AVPs MUST be encoded according to the rule described in section 5.1.4. Both, ATTRIBUTES (AVP Code) and VALUES (Data) MUST be set. 5.1.3.4 Capability Container Sub-Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-Option Type|Sub-Option Len |P| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Context-ID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVPs +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - Sub-Option Type: T.B.A Sub-Option Length: Length of the Sub-Option (including type and length fields as well as AVPs) in units of 8 octets. CARD Design Team Expires û September 2003 [Page 18] Internet-Draft Candidate Access Router Discovery March 2003 Flags: P-flag: Indicates piggybacking capability of a CAR. This flag allows a MN already after CARD process to know about a selected new AR's piggybacking capability. Remaining flags are reserved and MUST be initialized with 0. Context-ID: Identifies L2-ID, IP address and capability triples, coming with separated sub-options. Reserved: This field MUST be initialized with 0. AVPs: AVPs are a method of encapsulating capability information relevant for the CARD protocol. See section 5.1.4 for AVP encoding rule. 5.1.3.5 Address Sub-Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-Option Type|Sub-Option Len | Address Type | Node Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Context-ID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - Sub-Option Type: T.B.A Sub-Option Length: Length of the Sub-Option (including type and length fields) in units of octets. Address Type: Indicates the type of the address. 0x01 IPv4 0x02 IPv6 Node Type: Indicates the node type the subsequent address is associated to. CARD Design Team Expires û September 2003 [Page 19] Internet-Draft Candidate Access Router Discovery March 2003 Currently, the following node types are specified: 0x01 CAR Address 0x02 TAR Address Context-ID: Identifies L2-ID, IP address and capability triples, coming with separated sub-options. Address: The Target Access Router's IP address. 5.1.4 CARD AVP encoding 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | AVP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| Reserved | Attribute Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - AVP Code: Identifies the attribute uniquely. Flags: S: Static 1: static attribute, lifetime field is ignored 0: lifetime field indicates the attribute's lifetime. If lifetime is set to 0, the attribute value is valid only for this single request! Remaining flags are reserved and MUST be set to 0. AVP Length: The three octet AVP length field indicates the number of octets in this AVP, including the AVP Code, AVP Flags, AVP Length, Lifetime and Data. CARD Design Team Expires û September 2003 [Page 20] Internet-Draft Candidate Access Router Discovery March 2003 5.2 CARD Messages for the interface between ARs (AR - AR) 5.2.1 Protocol transport (AR-AR) For the CARD protocol operation between a MN's current AR and CARs on the network side, UDP is used as transport for CARD protocol messages. A UDP port for CARD is to be assigned. To authenticate protocol messages between ARs, the IPSec Authentication header is to be used. 5.2.2 Protocol main header Protocol main header comprises the first 8 octets: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Flags | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - Version: Indicates the version of the protocol. Flags: All flags are reserved and MUST be set to 0. Type: Message type. Message types specified for this interface: Message Type -------------------------------------- AR-AR CARD Request 0x01 AR-AR CARD Reply 0x02 Length: Length of the subsequent payload in octets. Sequence number: Allows correlating requests with responses. CARD Design Team Expires û September 2003 [Page 21] Internet-Draft Candidate Access Router Discovery March 2003 5.2.3 Protocol payload types Payload types and encoding rules are the same as described for the various sub-option types in section 5.1 for the Interface MN-AR. Same TLV-encoded format is used to attach the options to the protocol main header. 5.3 CARD Messages for the interface between an AR and the CARD server 5.3.1 Protocol transport (AR-Server function) For the CARD protocol operation between an AR and the CARD server function on the network side, UDP is used as transport for CARD protocol messages. A UDP port for CARD is to be assigned. Note: However, if for security and reliability reasons use of, for example, RADIUS or DIAMETER is preferable (assuming the CARD server function to be integrated with a RADIUS/AAA server), CARD protocol messages and payload is to be encoded appropriately. This needs to be discussed. To authenticate protocol messages between ARs, the IPSec Authentication header is to be used. 5.3.2 Protocol main header The protocol main header for this interface is the same as used for the interface between ARs on network side, and is described in section 5.2.2. Since ARs need to register with the CARD server function, two additional message types have been specified, which is a CARD REGISTRATION REQUEST and a CARD REGISTRATION REPLY message. The following table lists message types specified for CARD between an AR and the CARD server function: Message types specified for this interface: Message Type ------------------------------------ AR-Server CARD Request 0x03 AR-Server CARD Reply 0x04 CARD Registration Request 0x05 CARD Registration Reply 0x06 CARD Design Team Expires û September 2003 [Page 22] Internet-Draft Candidate Access Router Discovery March 2003 For the registration related message types, an additional payload type is required and described in section 5.3.3. 5.3.3 Protocol payload types Payload types and encoding rules are the same as described for the various sub-option types in section 5.1 for the Interface MN-AR. Same TLV-encoded format is used to attach the options to the protocol main header. For the registration of an AR with a CARD server function, an additional payload type is required to indicate the lifetime of the AR's registration. The lifetime option is encoded as follows 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: T.B.A Length: 0x08 - Length of the lifetime payload option in octets (including type and length fields). Reserved: To be initialized with 0. Lifetime: Indicates the lifetime of a registration in seconds. If the lifetime is set to '0', this indicates a de-registration with a CARD server function. CARD Design Team Expires û September 2003 [Page 23] Internet-Draft Candidate Access Router Discovery March 2003 5.4 Overview on sub-options'/payload types' usage The following table indicates which sub-options or payload types are relevant for the various interfaces in CARD protocol functions. Description Type Interface MN-AR AR-Server AR-AR --------------------------------------------------------------- L2-ID T.B.A x x Preferences T.B.A x x Requirements T.B.A x Capability Container T.B.A x x x Address T.B.A x x Lifetime T.B.A x 6. Security Considerations 6.1 Security Associations The AR-CARD Server communication and AR-AR communication need to be protected using security associations between them. These security associations can be established using current best practices. For example, statically programmed passwords or certificates (note that ARs and CARD server are in the same administrative domain) can be used to create session keys for message protection using IPSec. Alternatively, IPSec policy framework may be used to push credentials on these network entities from the policy server, which in turn can be used to create session keys for message protection using IPSec. It is not the intent of the CARD protocol to define a mechanism to create AR-CARD server and AR-AR security associations. It is implicit that the MN will have a security association with the current AR. Note: For AR-AR messaging, the CARD protocol shares security requirements with FMIPv6 and CT. Thus a common solution to establish security association between ARs can be used for FMIPv6, CT and CARD protocol. 6.2 DoS Attack The MN-AR communication presents chances to an attacker. A rogue MN can use CARD as a Denial-of-Service (DoS) attack against an AR. It may also flood the backend AR-Server and AR-AR communications. If the MN undertakes a DoS attack by flooding the AR with real or bogus layer 2 addresses, the CARD should prevent it. Since the requests from a MN come from within its subnet, the AR may know who is CARD Design Team Expires û September 2003 [Page 24] Internet-Draft Candidate Access Router Discovery March 2003 sending the requests. One possible solution is to limit the number of requests from a MN within a unit of time. But still, the rogue MN may change its identity so that the AR cannot detect. Another solution may be to define a kind of 'scope ID'. This is something to be configured administratively, but would make detection of ARs, which are not CARs easier and avoids cache overflow. For example, operators may set their ARs' scope-IDs based on the rough location and ARs register their scope-IDs to a server. When a current AR requests the L2-L3 mapping from the server, the server returns the mapping with its scope-ID. The current AR detects that this AR is potentially no CAR. Then, it can avoid further attempts to perform reverse address translation and capability discovery for this AR. 6.3 CAR Cache Contamination When caching is allowed at AR, the issue of preventing cache contamination needs to be addressed. A MN provides the current AR with unauthenticated observations of AP identifiers that it can hear. Then the AR asks for the authenticated AR information via the CARD server. The CARD server can tell only that there is a registered AR with the given L2 address but it cannot tell whether the AR is a CAR of the current AR (Note that CAR needs to have an access point geographically adjacent to current AR). Now the current AR relies on the fact that a MN provided the L2 address matching to a registered AR. A malicious MN may provide a L2 address, which is the L2 address of a registered AR but not a CAR of the current AR, that is, no overlapping coverage with the current AR. Then the current AR will build a CAR cache table with IP addresses of ARs that are not CARs. This has implications on size of cache that can be allowed on ARs. A more serious implication is that if large number of non-CAR entries appear in AR cache, AR spends processing power in performing capability exchange procedures with them. However, this issue may not be a problem in actual handover cases. At the time of handover, the MN or AR will receive the layer 2 address of the AP to which the MN is moving. Or the MN will match the AP layer 2 addresses in the CAR table with the address of the Aps it can hear. Thus, an AP address that is provided by a malicious MN but has no wireless connectivity to the CAR will get filtered out when the MN or AR uses the information for handover, so this issue can do no harm when the time of handover. Note: If cache contains bogus entries, hit ratio will go down. So, L2-IP mapping needs to be done from the CARD server. There is no guarantee, that answer from the CARD server will come in time for handover. CARD Design Team Expires û September 2003 [Page 25] Internet-Draft Candidate Access Router Discovery March 2003 This contaminated cache issue can be considered as a failure of the CAR cache table optimization. In addition to the æscope IDÆ solution described above, there is another possible solution for this optimization. The ARs can handle this by making the CARD information soft state, so that it times out the AP addresses if it doesnÆt receive a confirmation from another MN within a certain period of time. Thus, any bogus information has only limited lifetime, and even within that lifetime, it cannot do more than to occupy a table slot in the ARÆs memory. In fact, the AR can use the number of MNs reporting a particular address to weight the relevance of a reported AP. So, if 20 MNs report it, the AP address is more likely to stick around than if only 1 reports it. Note that this is not a protocol issue but an optimization issue for implementation. For additional security concerns, the reader is referred to [3]. 7. IANA considerations This will be done later when the protocol proposal has been finalized. 8. References [1]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2]Trossen, D., Krishanmurthi, G. Chaskar, H., Kempf, J. ôIssues in candidate access router discovery for seamless IP-level handoffs", draft-ietf-seamoby-cardiscovery-issues-04.txt, work in progress, October 2002. [3]Krishanmurti, G., ôRequirements for CAR Discovery Protocolsö, draft-ietf-seamoby-card-requirements-02.txt, a work in progress, October 2002. [4]Kempf, J.,"Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network", RFC 3374, September 2002. [5]Kenward, B.,"General Requirements for Context Transfer", draft- ietf-seamoby-ct-reqs-05.txt, a work in progress, October 2002. CARD Design Team Expires û September 2003 [Page 26] Internet-Draft Candidate Access Router Discovery March 2003 9. Authors' Addresses Hemant Chaskar Nokia Research Center 5 Wayside Road Burlington, MA 01803, USA Phone: 781 993 3785 Email: Hemant.Chaskar@nokia.com Daichi Funato NTT DoCoMo USA Labs 181 Metro Drive, Suite 300 San Jose, CA 95110, USA Phone: +1 408-451-4736 EMail: funato@docomolabs-usa.com Marco Liebsch NEC Network Laboratories Kurfuersten-Anlage 36 , 69115 Heidelberg Germany Phone: +49/(0)6221 90511 46 Email: marco.liebsch@ccrle.nec.de Ajoy Singh Motorola Inc 1501 West Shure Dr Phone: 847 632 6941 Email: asingh1@email.mot.com 10. IPR Statements The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Please refer to http://www.ietf.org/ietf/IPR for more information. CARD Design Team Expires û September 2003 [Page 27] Internet-Draft Candidate Access Router Discovery March 2003 11. Copyright Notice "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 12. Acknowledgements The CARD design team would like to thank Erik Nordmark for providing valuable insight about the piggybacking of CARD options upon FMIPv6 messages. In addition, the design team would like to thank (in alphabetical order) Eunsoo Shim, Govind Krishnamurthi, James Kempf, Madjid Nakhjiri, Pete McCann, Rajeev Koodli, and other members of the Seamoby WG for their valuable comments on the previous version of the draft as well as the general CARD related discussion and feedback on the WG mailing list. CARD Design Team Expires û September 2003 [Page 28]