Internet Engineering Task Force Mohamed M.Khalil, Nortel Networks INTERNET-DRAFT Raja Narayanan, nVisible Networks Haseeb Akhtar, Nortel Networks Date: July, 2001, Emad Qaddoura, Nortel Networks Expires: Jan, 2002 Mobile IP Extensions Rationalization (MIER) Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Khalil, et al. Expires Jan 2002 [Page 1] Internet-Draft MIER July 2001 Abstract It is in the interest of the Mobile IP WG to conserve the usage of the type field since we see many drafts proposing new extensions for Mobile IP. Therefore there is a real need to find ways to limit the usage of the type field in the extensions structure. MIER describes a new extension structure to Mobile IP to make the extensions far more extensible. 1.0 Introduction The type field in the Mobile IP extension structure can support upto 255 (skippable and not skippable) uniquely identifiable extensions. With new developments/additions to Mobile IP there is a strong possibility that the available space will run out. Mobile IP Extensions Rationalization (MIER) describes a new extension structure to solve this problem. MIER strategy is to initially aggregate certain types of extensions (e.g, NAI) and sub types to identify the precise extension (example MN/User NAI, HA NAI etc). This will greatly reduce the usage of the type field. MIER proposal is a natural evolution to the existing extension structure. It does not impact extensions that have been already defined. 1.1 Terminology 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 [Bradner97]. SA - Security Association [Perkins96] MN - Mobile Node [Perkins96] HA - Home Agent [Perkins96] FA - Foreign Agent [Perkins96] AAA - Authentication, Authorization, and Accounting. SPI - Security Parameters Index is a 32 bit number to index a SA in a database [Perkins96]. Khalil, et al. Expires Jan 2002 [Page 2] Internet-Draft MIER July 2001 2.0 Mobile IP Extension formats The extension structure proposed in this draft [Sec 2.2] is applicable to new extensions that are proposed to enhance Mobile IP. It does not apply to the extensions that have already been defined and standardised. 2.1 Existing Mobile IP Extension format According to [Perkins96] : Mobile IP defines a general Extension mechanism to allow optional information to be carried by Mobile IP control messages. Each of these Extensions is encoded in the following Type-Length-Value format: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type Indicates the particular type of Extension. Length Indicates the length (in bytes) of the data field within this Extension. The length does NOT include the Type and Length bytes. Data The particular data associated with this Extension. This field may be zero or more bytes in length. The format and length of the data field is determined by the type and length fields. 2.2 New Mobile IP Extension format This draft proposes the following two structures for Mobile IP extensions to be carried in the Mobile IP control messages. Since the new extension structures will cause an efficient usage of the extension type space, it is strongly recommended that all the new proposals for the Mobile IP WG that have new extensions SHOULD follow this format. Khalil, et al. Expires Jan 2002 [Page 3] Internet-Draft MIER July 2001 2.2.1 Long Extension Format This format is applicable for non-skippable extensions which carry information more than 256 bytes. It should be applicable to any future standardization which consider non-skippable extensions which accommodate up to 64 KBytes of data. 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 | Sub-Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The proposed general structure of the Long Extension consists of the following fields: Type is the type which describe a collection of extensions which has a common data type (see A.1, A.3). Sub-Type is a unique number given to each member in the aggregated type. Sub-Type values between of 200 through 255 are reserved for future use and standardization. Length indicates the length (in bytes) of the data field within this Extension. It does NOT include the Type, Length and Sub-Type bytes. Data is the data associated with this extension. This data MAY be represented in many ways (see A.1, A.3) Two bytes for the length field is suggested to enable providing a sufficiently large space for the extension data (maximum 64Kbytes). Khalil, et al. Expires Jan 2002 [Page 4] Internet-Draft MIER July 2001 2.2.2 Short Extension Format This format is backward compatible with the skippable extensions as it is defined in [Perkins96]. Also, it applicable for extensions which doe not require more than 256 bytes of data. 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 | Sub-Type | Data .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The proposed general structure of the Short Extension consists of the following fields: Type is the type which describe a collection of extensions which has a common data type (see A.2). Sub-Type is a unique number given to each member in the aggregated type. Sub-Type values between of 200 through 255 are reserved for future use and standardization. Length 8-bit unsigned integer. Length of the extension, in octets, excluding the extension Type and the extension Length fields. This field MUST be set to 1 plus the total length of the data field. Data is the data associated with this extension. This data MAY be represented in many ways (see A.2) 3.0 Acknowledgements The authors would like to acknowledge Basavaraj Patil, Pat Calhoun, Neil Justusson, C. Perkins, N. Asokan, and Jouni Malinen for their input in writing this draft. 4.0 References [Bradner97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [Calhoun99a] Calhoun, Perkins, "Mobile IP Network Access Identifier Extension", draft-ietf-mobileip-mn-nai-05.txt [Perkins96] Perkins, "IP mobility Support", RFC 2002, Oct 96 [Perkins99] Perkins, "Mobile IP Challenge/Response Extensions" draft-ietf-mobileip-challenge-06.txt [Bradner97] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Mar 97 Khalil, et al. Expires Jan 2002 [Page 5] Internet-Draft MIER July 2001 A APPENDIX The following are some exmples where we could use the concept of the proposed extensions' structure. A.1 General Authentication Extension This section defines a generic authentication extensions. 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 | Sub Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authenticator ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Authentication Extension type (TBD) Sub-Type this field describes the type of the entity which owns the Authentication Extension. The following types are defined: 1 MN-AAA Authentication Extension length The length of the Authenticator field. SPI Security Parameters Index Authenticator The variable length Authenticator field consists random value of at least 128 bits. A.2 General NAI Extension This section defines a general purpose NAI extension for different types of entities such MN, HA, FA etc. 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 | Sub-Type | NAI-INFO ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type NAI Aggregate type (TBD) length The length of the NAI-INFO field. Khalil, et al. Expires Jan 2002 [Page 6] Internet-Draft MIER Jan 2002 Sub-Type this field describes the type of the entity which owns the NAI. The following types are defined: 0 MN-NAI 1 FA-NAI 2 HA-NAI 3 Previous FA-NAI Extension NAI-INFO Contains the NAI in a string format. A.3 General Session Key Extension This section defines a general purpose security association extension which carries information necessary to establish security association between different entities in the Mobile IP model (e.g. MN-FA, FA-HA and MN-HA ). 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 | Sub Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | security information ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Generic AA Key Extension (TBD) length The length of the SA-INFO field. Sub-Type defines the type of entity which owns the key address: 0 MN-HA Key Extension 1 MN-FA Key Extension 2 FA-HA Key Extension SPI1 A 32-bit opaque value, indicating the SPI that the mobile node must use to determine the algorithm to use for recovering the security information. SPI2 A 32-bit opaque value, which the mobile node MUST use to index all the necessary information recovered from the FA security information after it is decoded. Security Information The necessary information (including the key, algorithm etc) required by the mobile node to create a Mobility Security Assocation between itself and another entity such as HA and FA. Khalil, et al. Expires Jan 2002 [Page 7] Internet-Draft MIER July 2001 Author Information: Mohamed Khalil Emad Qaddoura Nortel Networks Inc. Nortel Networks Inc. 2201 Lakeside Blvd 2201 Lakeside Blvd Richardson, TX 75082-4399 Richardson, TX 75082-4399 Phone: +1 972 685-0564 Phone: +1 972 684-2705 E-mail: mkhalil@nortelnetworks.com E-mail: emadq@nortelnetworks.com Raja Narayanan Haseeb Akhtar nVisible Networks. Nortel Networks Inc. 4716 Winter Park Dr, 2201 Lakeside Blvd Richardson, TX-75082 Richardson, TX 75082-4399 Phone: Ph: 1 + 214 684 4905 Phone: +1 972 684-8850 E-mail: raja@nvisiblenetworks.com E-mail: haseeb@nortelnetworks.com Khalil, et al. Expires Jan 2002 [Page 8]