IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: CARD Protocol for Information Service Date Submitted: September 21, 2005 Presented at IEEE session #10, Orange County, California Authors : Ajoy Singh (Motorola), Vivek Gupta (Intel) Sources (RFC 4066) : Ajoy Singh, Eunsoo Shim, Marco Liebsch,Hemant Chaskar and Daichi Funato Abstract: Provides overview of CARD (RFC 4066) and how it can be used for MIH L3 transport

IEEE presentation release statements This document has been prepared to assist the IEEE Working Group. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual and in Understanding Patent Issues During IEEE Standards Development Section 6.3 of the IEEE-SA Standards Board Operations Manualhttp://standards.ieee.org/guides/opman/sect6.html#6.3

Contents CARD Protocol Overview CARD Protocol Architecture Consideration CARD Protocol Details CARD Protocol Message Structure CARD Protocol Security Mechanisms Review of IS Reference Model Proposal to IEEE WG

Objective Give an overview of CARD Plan a set future activities to modify (if required) CARD to meet L3 Transport requirements

CARD Protocol Overview CARD Protocol is specified in IETF: RFC 4066 Basic functionality Collect and distribute information about the access network, in particular, information about the current and neighboring L3 and L2 POAs (point of attachments). Defines only container protocol (InfoElement not defined) Defines mechanism for secure information delivery from one CARD entity to other Example L3/L2 information elements : Access point Channel numbers, access router load, IP Version, QoS parameters, Security Protocol info etc. Provides an IANA registry that can be used to register various information elements to be carried by the protocol Information is distributed from the network entity (assumed to be located at L3 POA) to the mobile node Server based CARD (defined in appendix) allows information delivery from CARD Server to Mobile Node and Network L3 POA. Information distribution modes Request/Reply (Solicited) Mode Broadcast or multicast (Unsolicited) Mode …

Server-less CARD Protocol Architecture CARD MN-AR CARD Request (1) MN-AR CARD Reply (4) AR-AR CARD Request (2) AR-AR Card Reply (3) The above diagram describes sequence of message exchange for mobile node initiated information request. L3 POA is Access Router (but it is possible to place network component of CARD on any node of Access Network) CARD MN (Mobile Node) Current L3 POA Neighbor L3 POA

Server-based CARD Protocol Architecture CARD Server AR-AR CARD Request (4) AR-AR CARD Reply (5) AR- Server CARD Request (2) MN-AR CARD Request (1) MN-AR CARD Reply (6) AR-Server CARD Reply (3) Described in appendix of RFC4066 Describes message exchange for Mobile Initiated information request for Sever-based CARD protocol CARD MN (Mobile Node) L3 POA (Point of Attachment)

CARD Protocol Details Possible applications Fast handoff (seamless handoff) Load balancing between AR (s) Inter-technology handovers. Multi-homing CARD messages Defined for Mobile Node L3 POA Uses ICMP for transport Defined for current L3 POA Neighboring L3 POA communication Uses SCTP or UDP for transport TLV based encoding is supported. Same TLV options used over MN L3 POA and current L3 POA Neighboring POA interface Information query options Preferences: same as filters (specify what type of information is needed) (e.g. I am interested in Link Type.) Requirements: specify the conditions which are information types and required values (e.g. Link type should be )

CARD Protocol Details Uses Sequence number to match CARD Request and CARD Response pair Supports reliable message delivery Allows CARD entity to send multiple CARD Reply messages in response to single CARD Request if entire content of Reply Message cannot be accommodated in a single ICMP Message. This behavior is only required for ICMP transport. CARD Request contains a list of AP Id (s) along with filters indicating the requested information. CARD supports two types of filters: Requirement Sub-Option Preference Sub-Option Using combination of Requirement and Preference filters all possible Information Requests can be made Reply is sent in response to Request and contains TLV encoded capability information aka InfoElement Supports in built security mechanisms to ensure secure information delivery

CARD Message Encoding CARD Sub-options CARD Option Transport Header Transport Header : IP/UDP, IP/SCTP, ICMP etc. CARD Options: CARD Request / CARD Reply CARD Sub-options: AVP (attribute Value Pair) for CARD Capabilities aka InfoElements

Sub-options Sequence Number Type CARD Request Option Encoding Length VersionsFlagsReserved CARD Request is sent by CARD entity to request capability information from other CARD entity. MN-AR CARD Request is used by MN to acquire capability information from AR. AR-AR CARD Request is used by AR to acquire capability information from its neighboring AR AR-Sever CARD Request is used by AR to acquire Capability from CARD Server

CARD Reply Option Encoding Sub-options Sequence Number Type Length VersionsFlagsReserved Sent in response to CARD Request Sub-option Contains Capability Container sub-options Capability Container Sub-options contains TLV encoded InfoElements

CARD Sub-options Encoding Sub-Option Type Sub-option Length Sub-options Data Sub-options: Container Sub-options: L2 ID Sub-options : Encodes L2 ID of AP Address : Encodes IPv4/IPv6 address of Access Router Capability Container Sub-option : Contains list of TLV containing information elements Filter Sub-options: Preferences : Carries information about the attribute of interest to the requesting entity Requirements : Carries information about attribute value pair required for pre-filtering of capability by L3 POA Security Sub-options (Used for SeND Based Authentication): Trusted Anchor : Carries name of trusted anchor for which MN has a certificate. Router Certificate : Carries one certificate in the path for the current AR or for a CAR

AVP(s) … Capability Container Sub-options Encoding Sub-Option Type Sub-option LengthContext-ID PResd Contains multiple requested information element belonging to a single Access Network Context-ID : Correlates L2 Id with the Information Element AVPs (Attribute Value Pair): encapsulates information elements

Attribute Lifetime Data Capability Attribute Value Pair Encoding AVP Code AVP LengthReserved CARD AVP is analogues to Information Element AVP Code : Identifies the attribute uniquely Lifetime : Lifetime of capability. 0xffff means static capability Data: Encoded capability information

Neighbor InformationNeighboring network information AllTechnology specific information SecurityLink layer security supported AllTechnology specific, e.g. WEP in , i, PKM in UEA in 3G, Cipher Suites, Authentication_Methods, etc. Quality of ServiceLink QoS supported or not by the access network AllE.g e, Other Mechanisms Access Router Info AccessRouterAddress, IPversion, MobilityProtocolSupp ort, FASupport Can be part of Higher Layer services Name of Information Element DescriptionMedia Types Comments Example Information Elements

Using Card Request to Query Information AP-ID1 L2-ID Option SO Length Context-ID (C1) AP Neighbor ListSupport of Location Services Preference SOSO Length Security Protocol Sequence Number of Request Message: SN1 CARD Request Length VersionsFlagsReserved Describes CARD Request Message encoding to request following information about access network using AP ID of one of the Access Point (AP-ID1): Security Protocol Neighbor List, Support of Location Service Possible to query information about multiple access networks by including AP- Id(s) belonging to multiple access network in same request Note: Message format not drawn to the scale

Using CARD Reply to deliver Information Attribute Lifetime Data (location Service Info) Location Service AVP Info Element Length Resvd Attribute Lifetime Data ( Neighbor List) Neighbor List AVP Info Element LengthResvd Attribute Lifetime Data (Security Info) Security Protocol AVP AVP (Info Element) LengthResvd Capability Cont Sub-opt SO LengthContext-ID (C1) P Resvd Sequence Number of Reply Message : SN1 CARD Reply Length VersionsFlagsReserved Context-ID identifies the AP-Id (access network) for which the capability information (InfoElements) is being delivered Information about each access network is encoded using various AVP(s) and packed inside a single capability container. Multiple capability containers are needed to send information about multiple access networks.

CARD Security Mechanisms CARD protocol provides secure information delivery using combination of SeND (Secure Neighbor Discovery) and IPSEC mechanism SeND (RFC 3971) is used between MN-L3 POA interface for message authentication IPSEC ESP is used between current L3 POA- Neighbor L3 POA interface ESP with NULL encapsulation is used if only authentication is required IKE is used for key management between current L3 POA- Neighbor L3 POA interface IPSEC security mechanism can be extended between L3 POA - Server Interface for Server based approach

Case 2b: Distributed Information Service with separate Information Database UE Information Database Information Database Ia Ix IS Function Network IS Provider IS Function IS Function Ia` IEEE / IETF Scope (?) Ia: Interface between UE and Network Ix : Interface between IS Function and Information Database IEEE / IETF Scope Source --- DCN: Title: Reference Model and Use-Cases for Information Service

Proposal to IEEE WG Protocol Comparis on MN L3 POA Interface L3 POA L3 POA Interface L3 POA Server Interface CARD (RFC 4066) CARD MN AR (L3 POA) CARD L3 POA L3 POA CARD L3 POA CARD Server MIH IS Protocol Ia Ia` Ix IETF has invested four years work in the area of Information Service and published this as CARD RFC (4066) IEEE should continue requirements discussion and keep CARD in consideration. Extensions or modification of CARD to meet IS requirements is possible.

Potential Modifications to CARD To Support IS protocol requirements Relax the requirements of CARD protocol to allow placement of L3POA CARD entity to any IP node including AP without changing existing CARD protocol Make sever-based CARD protocol approach as default CARD protocol assuming server based approach will be favored by requirements Make additional changes needed to support IS protocol

Why CARD ? CARD is designed to distribute mobility related access network information to handoff control entity CARD architecture is flexible enough to accommodate various scenarios being discussed by requirement team Supports simple Query / Reply Message protocol for secure Information Delivery Provides generic encoding mechanism and flexible transport that allows CARD Messages to be transported over any transport layer protocol. e.g., ICMP, UDP and SCTP CARD has been implemented and verified in lab setup Quicker to modify and enhance an existing protocol than to define a new one Last but not least, CARD protocol is already published as RFC and has undergone IETF WG as well as IESG review

CARD Next Steps Produce an initial document describing how CARD can be enhanced to support L3 requirements Initial goal is IS, but plan to consider protocol enhancements for Event and Command Service as well Work in an ad hoc manner to describe how CARD protocol can be enhanced to support L3 requirements

Preference / Requirements Sub-option Encoding Sub-Option Type Sub-option Length Preferences Preferences: List of capability attribute values Sub-Option Type Sub-option Length Requirements Requirements: AVP Encoded Requirements Request / Reply filters are used by MN to request specific capabilities from L3 POA

Address and L2 Sub-options Encoding Address Sub-Option Type Sub-option LengthContext-ID Address Type L2 Sub-options : Encodes L2 Ids of AP L2 Type Sub-Option Type Sub-option Length L2 ID Context-ID Status Code Context-ID: Context-Id is used to associate L2-Id, IP-Address, Capability Information Status Code: Indicates the Status of L2->L3 mapping Address Sub-options : Encodes IPv4/IPv6 address of AR