idnits 2.17.1 draft-ietf-mobileip-mier-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 5) being 68 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 9 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 21 has weird spacing: '... It is inapp...' == Line 112 has weird spacing: '...llowing two s...' == Line 137 has weird spacing: '... Type is t...' == Line 140 has weird spacing: '...ub-Type is a ...' == Line 148 has weird spacing: '... Data is t...' == (5 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'Calhoun99a' is defined on line 195, but no explicit reference was found in the text == Unused Reference: 'Perkins99' is defined on line 200, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-mobileip-mn-nai-05 ** Obsolete normative reference: RFC 2002 (ref. 'Perkins96') (Obsoleted by RFC 3220) == Outdated reference: A later version (-13) exists of draft-ietf-mobileip-challenge-06 Summary: 7 errors (**), 0 flaws (~~), 13 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Mohamed M.Khalil, Nortel Networks 2 INTERNET-DRAFT Raja Narayanan, nVisible Networks 3 Haseeb Akhtar, Nortel Networks 4 Date: July, 2001, Emad Qaddoura, Nortel Networks 5 Expires: Jan, 2002 7 Mobile IP Extensions Rationalization (MIER) 9 Status of this memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use 22 Internet-Drafts as reference material or to cite them other 23 than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 It is in the interest of the Mobile IP WG to conserve the 34 usage of the type field since we see many drafts proposing 35 new extensions for Mobile IP. Therefore there is a real 36 need to find ways to limit the usage of the type field in the 37 extensions structure. MIER describes a new extension 38 structure to Mobile IP to make the extensions far more 39 extensible. 41 1.0 Introduction 43 The type field in the Mobile IP extension structure can support 44 upto 255 (skippable and not skippable) uniquely identifiable 45 extensions. With new developments/additions to Mobile IP 46 there is a strong possibility that the available space will 47 run out. 49 Mobile IP Extensions Rationalization (MIER) describes a 50 new extension structure to solve this problem. MIER strategy 51 is to initially aggregate certain types of extensions (e.g, 52 NAI) and sub types to identify the precise extension (example 53 MN/User NAI, HA NAI etc). This will greatly reduce the usage 54 of the type field. 56 MIER proposal is a natural evolution to the existing extension 57 structure. It does not impact extensions that have been already 58 defined. 60 1.1 Terminology 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in RFC 2119 [Bradner97]. 66 SA - Security Association [Perkins96] 68 MN - Mobile Node [Perkins96] 70 HA - Home Agent [Perkins96] 72 FA - Foreign Agent [Perkins96] 74 AAA - Authentication, Authorization, and Accounting. 76 SPI - Security Parameters Index is a 32 bit number to index a SA 77 in a database [Perkins96]. 79 2.0 Mobile IP Extension formats 81 The extension structure proposed in this draft [Sec 2.2] is 82 applicable to new extensions that are proposed to enhance 83 Mobile IP. It does not apply to the extensions that have already 84 been defined and standardised. 86 2.1 Existing Mobile IP Extension format 88 According to [Perkins96] : Mobile IP defines a general Extension 89 mechanism to allow optional information to be carried by Mobile 90 IP control messages. Each of these Extensions is encoded in the 91 following Type-Length-Value format: 93 0 1 2 94 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 95 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 96 | Type | Length | Data ... 97 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 99 Type Indicates the particular type of Extension. 101 Length Indicates the length (in bytes) of the data field within 102 this Extension. The length does NOT include the Type and 103 Length bytes. 105 Data The particular data associated with this Extension. This 106 field may be zero or more bytes in length. The format 107 and length of the data field is determined by the type 108 and length fields. 110 2.2 New Mobile IP Extension format 112 This draft proposes the following two structures for Mobile IP 113 extensions to be carried in the Mobile IP control messages. 114 Since the new extension structures will cause an efficient 115 usage of the extension type space, it is strongly recommended 116 that all the new proposals for the Mobile IP WG that have new 117 extensions SHOULD follow this format. 119 2.2.1 Long Extension Format 121 This format is applicable for non-skippable extensions which carry 122 information more than 256 bytes. It should be applicable to any future 123 standardization which consider non-skippable extensions which accommodate 124 up to 64 KBytes of data. 126 0 1 2 3 127 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 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | Type | Sub-Type | Length | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | Data ..... 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 The proposed general structure of the Long Extension consists 135 of the following fields: 137 Type is the type which describe a collection of extensions which 138 has a common data type (see A.1, A.3). 140 Sub-Type is a unique number given to each member in the 141 aggregated type. Sub-Type values between of 200 through 142 255 are reserved for future use and standardization. 144 Length indicates the length (in bytes) of the data field within 145 this Extension. It does NOT include the Type, Length 146 and Sub-Type bytes. 148 Data is the data associated with this extension. This data MAY 149 be represented in many ways (see A.1, A.3) 151 Two bytes for the length field is suggested to enable providing a 152 sufficiently large space for the extension data (maximum 64Kbytes). 154 2.2.2 Short Extension Format 156 This format is backward compatible with the skippable extensions 157 as it is defined in [Perkins96]. Also, it applicable for extensions 158 which doe not require more than 256 bytes of data. 160 0 1 2 3 161 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 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Type | Length | Sub-Type | Data .... 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 The proposed general structure of the Short Extension consists 167 of the following fields: 169 Type is the type which describe a collection of extensions which 170 has a common data type (see A.2). 172 Sub-Type is a unique number given to each member in the 173 aggregated type. Sub-Type values between of 200 through 174 255 are reserved for future use and standardization. 176 Length 8-bit unsigned integer. Length of the extension, in octets, 177 excluding the extension Type and the extension Length fields. 178 This field MUST be set to 1 plus the total length of the 179 data field. 181 Data is the data associated with this extension. This data MAY 182 be represented in many ways (see A.2) 184 3.0 Acknowledgements 186 The authors would like to acknowledge Basavaraj Patil, Pat 187 Calhoun, Neil Justusson, C. Perkins, N. Asokan, and Jouni Malinen 188 for their input in writing this draft. 190 4.0 References 192 [Bradner97] Bradner, S., "Key words for use in RFCs to Indicate 193 Requirement Levels", BCP 14, RFC 2119, March 1997. 195 [Calhoun99a] Calhoun, Perkins, "Mobile IP Network Access 196 Identifier Extension", draft-ietf-mobileip-mn-nai-05.txt 198 [Perkins96] Perkins, "IP mobility Support", RFC 2002, Oct 96 200 [Perkins99] Perkins, "Mobile IP Challenge/Response Extensions" 201 draft-ietf-mobileip-challenge-06.txt 203 [Bradner97] Bradner, "Key words for use in RFCs to Indicate 204 Requirement Levels", RFC 2119, Mar 97 206 A APPENDIX 208 The following are some exmples where we could use the concept 209 of the proposed extensions' structure. 211 A.1 General Authentication Extension 213 This section defines a generic authentication extensions. 215 0 1 2 3 216 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 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Type | Sub Type | Length | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | SPI | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Authenticator ..... 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 Type Authentication Extension type (TBD) 227 Sub-Type this field describes the type of the entity which 228 owns the Authentication Extension. The following 229 types are defined: 230 1 MN-AAA Authentication Extension 232 length The length of the Authenticator field. 234 SPI Security Parameters Index 236 Authenticator The variable length Authenticator field consists 237 random value of at least 128 bits. 239 A.2 General NAI Extension 241 This section defines a general purpose NAI extension for 242 different types of entities such MN, HA, FA etc. 244 0 1 2 3 245 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 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Type | Length | Sub-Type | NAI-INFO ... 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 Type NAI Aggregate type (TBD) 252 length The length of the NAI-INFO field. 254 Sub-Type this field describes the type of the entity which 255 owns the NAI. The following types are defined: 256 0 MN-NAI 257 1 FA-NAI 258 2 HA-NAI 259 3 Previous FA-NAI Extension 261 NAI-INFO Contains the NAI in a string format. 263 A.3 General Session Key Extension 265 This section defines a general purpose security association 266 extension which carries information necessary to establish security 267 association between different entities in the Mobile IP model 268 (e.g. MN-FA, FA-HA and MN-HA ). 270 0 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Type | Sub Type | Length | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | SPI1 | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | SPI2 | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | security information ... 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 Type Generic AA Key Extension (TBD) 284 length The length of the SA-INFO field. 286 Sub-Type defines the type of entity which owns the key 287 address: 288 0 MN-HA Key Extension 289 1 MN-FA Key Extension 290 2 FA-HA Key Extension 292 SPI1 A 32-bit opaque value, indicating the SPI that the 293 mobile node must use to determine the algorithm to use 294 for recovering the security information. 296 SPI2 A 32-bit opaque value, which the mobile node MUST use 297 to index all the necessary information recovered from 298 the FA security information after it is decoded. 300 Security Information 301 The necessary information (including the 302 key, algorithm etc) required by the mobile node 303 to create a Mobility Security Assocation between 304 itself and another entity such as HA and FA. 306 Author Information: 308 Mohamed Khalil Emad Qaddoura 309 Nortel Networks Inc. Nortel Networks Inc. 310 2201 Lakeside Blvd 2201 Lakeside Blvd 311 Richardson, TX 75082-4399 Richardson, TX 75082-4399 313 Phone: +1 972 685-0564 Phone: +1 972 684-2705 314 E-mail: mkhalil@nortelnetworks.com E-mail: emadq@nortelnetworks.com 316 Raja Narayanan Haseeb Akhtar 317 nVisible Networks. Nortel Networks Inc. 318 4716 Winter Park Dr, 2201 Lakeside Blvd 319 Richardson, TX-75082 Richardson, TX 75082-4399 321 Phone: Ph: 1 + 214 684 4905 Phone: +1 972 684-8850 322 E-mail: raja@nvisiblenetworks.com E-mail: haseeb@nortelnetworks.com