idnits 2.17.1 draft-mkhalil-mobileip-mier-00.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 10 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 27 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 21 has weird spacing: '... It is inapp...' == Line 119 has weird spacing: '...section defin...' == Line 136 has weird spacing: '...nt-type this...' == Line 155 has weird spacing: '...section defin...' == Line 172 has weird spacing: '...nt-type this...' == (5 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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) -- Looks like a reference, but probably isn't: 'Perkins98' on line 74 -- Looks like a reference, but probably isn't: 'Calhoun99a' on line 112 -- Looks like a reference, but probably isn't: 'Dommety99' on line 269 == Unused Reference: '1' is defined on line 361, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 368, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 370, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-mobileip-mn-nai-04 -- No information found for draft-dommety-mobileip-vendor-ext - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2' ** Obsolete normative reference: RFC 2002 (ref. '3') (Obsoleted by RFC 3220) Summary: 4 errors (**), 0 flaws (~~), 14 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Mohamed Khalil 2 INTERNET-DRAFT Raja Narayanan 3 Emad Qaddoura 4 Date: October, 1999 Haseeb Akhtar 5 Expires: April, 2000 Nortel Networks 7 Mobile IP Extensions Rationalization (MIER) 9 Status of this memo 11 This document is an Internet-Draft and is in full conformance with 12 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 Internet-Drafts 22 as reference material or to cite them other than as "work in 23 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 As the large scale Mobile IP deployment becomes fairly imminent, we 34 see many drafts proposing new extensions for Mobile IP. Therefore 35 there is a real need to conserve the type field in the extensions 36 structure. MIER describes a new extensions structure to Mobile IP 37 to make the extensions truly extensible and secure. 39 1. Introduction 41 The type field in the Mobile IP extension structure can support 42 upto 255 uniquely identifiable extensions. With large scale 43 deployment needs there is a strong possibility that the available 44 space will run out. In addition the current extension format does 45 not provide for encryption. 47 Mobile IP Extensions Rationalization (MIER) describes a new 48 extensions structure to solve this problem. MIER strategy is to 49 initially aggregate certain types of extensions (e.g, NAI) and sub 50 types (content type) to identify the precise sub type of the 51 extension (example MN/User NAI, HA NAI etc). This will greatly 52 reduce the usage of the type field. In addition MIER format 53 provides a way for these extensions to be optionally encrypted thus 54 providing a measure of security to the contents of the extension. 55 MIER also specifies a specific type to be used when all the space 56 in the type field is used up. 58 2. Terminology 60 This document uses the following terminology: 62 SA Security Association is the logical term used 63 to capture the shared secret keys, secruity 64 attributes and policy that needs to be defined 65 in order to apply protection to traffic between 66 any two nodes in a network. SPI (defined below) 67 uniquely identifies a SA within the context of 68 a host. 70 MN Mobile Node [Perkins98] 72 HA Home Agent [Perkins98] 74 FA Foreign Agent [Perkins98] 76 AAA Authentication, Authorization, and Accounting 77 Server 79 SPI Security Parameters Index is a 32 bit number to 80 index a SA in a database. 82 3. Specification Language 84 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 86 this document are to be interpreted as described in RFC 2119 [2]. 88 4. Generic Mobile IP Extension format 90 The Mobile IP Extension format is described below: 92 0 1 2 3 93 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 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 95 | Type | length | content-type |E| rsv | 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | SPI | 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 | Data ..... 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 The type field MUST be used in a a way to aggregate extensions. 103 The content-type field MUST identify the sub types. If E is set to 104 1 then the data is encrypted. SPI is the Security Parameter Index 105 to identify the encryption attributes. SPI field MUST be dropped if 106 the E field is set to 0. The rsv field is reserved for future use. 108 5. New Extension Specification 110 Some of the extensions proposed in the following sections are under 111 consideration in the Mobile IP WG by virtue of other drafts namely, 112 MN NAI Extension [Calhoun99a], Vendor/Organization specific 113 extension [Dommety99]. This draft proposes the same extensions in a 114 format that reduces type field proliferation and provides 115 optionality for encryption. 117 5.1. NAI Extension 119 This section defines a general purpose NAI extension for different 120 types of entities such MN, HA, FA etc. 122 0 1 2 3 123 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 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | Type | length | content-type |E| rsv | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | SPI | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | NAI-INFO ..... 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 Type NAI Aggregate type (TBD) 134 length The length of the NAI-INFO field. 136 content-type this field describes the type of the entity which 137 owns the NAI. The following types are defined: 138 0 MN-NAI 139 1 FA-NAI 140 2 HA-NAI 142 E if 1 then the contents of NAI-INFO field 143 is encrypted. 145 SPI Security Parameter Index. Defines the key and type 146 of encrypted algorithm which used to encrypt the 147 NAI. This parameter is included only if the E bit 148 set ( E=1). 150 NAI-INFO Contains the NAI string in an encrypted or regular 151 string format. 153 5.2. Address Extension 155 This section defines a general purpose L2 Address extension for 156 different types of transport technologies. 158 0 1 2 3 159 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 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Type | length | content-type |E| rsv | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | SPI | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | L2-ADDRESS-INFO ..... 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 Type Layer 2 Address Aggregate type (TBD) 170 length The length of the L2 ADDRESS-INFO field. 172 content-type this field describes the type of L2 addresses 173 included in the extension. The following types 174 are defined: 175 0 ETHERNET-ADDRESS 176 1 IMSI 177 2 MIN (Mobile Identification Number) 179 E if 1 then the contents of L2-ADDRESS-INFO field 180 is encrypted. 182 SPI Security Parameter Index. Defines the key and type 183 of encrypted algorithm which used to encrypt the 184 L2-ADDRESS-INFO filed. This parameter is included 185 only if the E bit set ( E=1). 187 L2-ADDRESS-INFO Contains the L2 address in an encrypted of reqular 188 format. 190 5.3. IP Extension 192 This section defines a general purpose IP extension which carry IP 193 addresses in encrypted or unencrypted format. Currently the MN Home 194 IP address is carried in the clear. Under requirements for user 195 privacy there MAY be need to send the MN's IP address encrypted and 196 this extension provides a way to do that. 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Type | length | content-type |E| rsv | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | SPI | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | IP-INFO ..... 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 Type IP Extension Aggregate type (TBD) 210 length The length of the IP-INFO field. 212 content-type defines the type of entity which owns the IP 213 address: 214 0 MN-HOME-IP 215 1 DEFAULT-ROUTER-IP 217 E if 1 then the contents of IP-INFO field is 218 encrypted. 220 SPI Security Parameter Index. Defines the key and type 221 of encrypted algorithm which used to encrypt the 222 IP-INFO filed. This parameter is included only if 223 the E bit set ( E=1). 225 IP-INFO Contains the IP address in an encrypted of reqular 226 format. 228 5.4. Per Session Security Association Extension 230 This section defines a general purpose security association 231 extension which carrries information necessary to establish 232 security association between different entities in the Mobile IP 233 model (e.g. MN-FA SA and FA-HA SA). 235 0 1 2 3 236 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 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Type | length | content-type |E| rsv | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | SPI | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | SA-INFO ..... 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Type Per Session SA Aggregate type (TBD) 247 length The length of the SA-INFO field. 249 content-type defines the type of entity which owns the IP 250 address: 251 0 MN-FA-SA 252 1 FA-HA-SA 254 E if 1 then the contents of SA-INFO field 255 is encrypted. 257 SPI Security Parameter Index. Defines the key and type 258 of encrypted algorithm which used to encrypt the 259 SA-INFO field. This parameter is included only if 260 the E bit set ( E=1). 262 SA-INFO This field encode the information to establish 263 security association such as private key or 264 session key. 266 5.5. Vendor/Organization Specific Extension 268 This section defines a general purpose vendor/organization specific 269 extension [Dommety99] 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 | length | content-type |E| rsv | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Vendor ID | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | SPI | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Data ..... 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 Type Vendor/organization Specific Aggregate Type (TBD) 284 length The length of the Data field 286 content-type defines the type of vendor/organization specific 287 extension as critical or normal. 289 0 Critical 290 1 Normal 292 Critical or Normal as as defined in Dommety99. 294 Vendor ID Vendor ID is as referred to in Dommety99. 296 E if 1 then the contents of SA-INFO field 297 is encrypted. 299 SPI Security Parameter Index. Defines the key and type 300 of encrypted algorithm which used to encrypt the 301 SA-INFO field. This parameter is included only if 302 the E bit set ( E=1). 304 Data This field contains the vendor specific data. 306 5.6. General Extension 308 In the event when all the available type space is consumed the 309 following format will further provide extensibility. This format 310 MAY also be used in the event that a certain aggregation type 311 requires the length field to be greater than one. 313 0 1 2 3 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Type | length | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Actual-Type | Content-Type |E| rsv | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | SPI | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Data ..... 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 Type The general type (TBD) 327 Actual-Type The actual aggregate type 329 length The length of the Data field. 331 content-type Defines the sub type of aggregate type 333 E if 1 then the contents of Data field 334 is encrypted. 336 SPI Security Parameter Index. Defines the key and type 337 of encrypted algorithm which used to encrypt the 338 SA-INFO field. This parameter is included only if 339 the E bit set ( E=1). 341 Data This field contains the actual data 343 6. IANA Considerations 345 Assignment of the TBDs for the types, content types and actual 346 types MUST occur in a non conflicting manner. 348 7. Security Considerations 350 Each extension has a field using which the extension MAY be 351 encrypted. The SPI field MUST be present if the extension is 352 encrypted. 354 8. Acknowledgements 356 The authors would like to acknowledge Basavaraj Patil for his input 357 in writing this draft. 359 9. References 361 [1] [Calhoun99a] Calhoun, Perkins, "Mobile IP Network Access 362 Identifier Extension", draft-ietf-mobileip-mn-nai-04.txt 364 [2] [Dommety99] Dommety, Leung, "Vendor/Organization Specific 365 Extensions for Mobile IP", draft-dommety-mobileip-vendor-ext- 366 00.txt 368 [3] [Perkins96] Perkins, "IP mobility Support", RFC 2002, Oct 96 370 [4] Bradner S., "Key words for use in RFCs to Indicate Requirement 371 Levels", RFC 2119, March 1997. 373 10. Authors' Addresses 375 Questions about this document can be directed to: 377 Mohamed Khalil Emad Qaddoura 378 Nortel Networks Inc. Nortel Networks Inc. 379 2201 Lakeside Blvd 2201 Lakeside Blvd 380 Richardson, TX 75082-4399 Richardson, TX 75082-4399 382 Phone: +1 972 685-0564 Phone: +1 972 684-2705 383 E-mail: mkhalil@nortelnetworks.com E-mail: emadq@nortelnetworks.com 385 Raja Narayanan Haseeb Akhtar 386 Nortel Networks Inc. Nortel Networks Inc. 387 2201 Lakeside Blvd 2201 Lakeside Blvd 388 Richardson, TX 75082-4399 Richardson, TX 75082-4399 390 Phone: +1 972 684-5707 Phone: +1 972 684-8850 391 E-mail: raja@nortelnetworks.com E-mail: haseeb@nortelnetworks.com