idnits 2.17.1 draft-ietf-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 4 longer pages, the longest (page 6) being 64 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 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 3 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 21 has weird spacing: '... It is inapp...' == Line 122 has weird spacing: '... Type is t...' == Line 125 has weird spacing: '...ub-Type is a ...' == Line 133 has weird spacing: '... Data is t...' == Line 199 has weird spacing: '...section defin...' == (1 more instance...) == 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) == Unused Reference: 'Calhoun99a' is defined on line 153, but no explicit reference was found in the text == Unused Reference: 'Perkins99' is defined on line 158, but no explicit reference was found in the text == Unused Reference: 'Bradner97' is defined on line 161, 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 (~~), 15 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 2 INTERNET-DRAFT Raja Narayanan 3 Haseeb Akhtar 4 Date: Dec, 1999 Emad Qaddoura 5 Expires: May, 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 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 SA - Security Association [Perkins96] 64 MN - Mobile Node [Perkins96] 66 HA - Home Agent [Perkins96] 68 FA - Foreign Agent [Perkins96] 70 AAA - Authentication, Authorization, and Accounting. 72 SPI - Security Parameters Index is a 32 bit number to index a SA 73 in a database [Perkins96]. 75 2.0 Mobile IP Extension formats 77 The extension structure proposed in this draft [Sec 2.2] is 78 applicable to new extensions that are proposed to enhance 79 Mobile IP. It does not apply to the extensions that have already 80 been defined and standardised. 82 2.1 Existing Mobile IP Extension format 84 According to [Perkins96] : Mobile IP defines a general Extension 85 mechanism to allow optional information to be carried by Mobile 86 IP control messages. Each of these Extensions is encoded in the 87 following Type-Length-Value format: 89 0 1 2 90 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 91 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 92 | Type | Length | Data ... 93 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 95 Type Indicates the particular type of Extension. 97 Length Indicates the length (in bytes) of the data field within 98 this Extension. The length does NOT include the Type and 99 Length bytes. 101 Data The particular data associated with this Extension. This 102 field may be zero or more bytes in length. The format 103 and length of the data field is determined by the type 104 and length fields. 106 2.2 New Mobile IP Extension format 108 This draft proposes the following structure for Mobile IP 109 extensions to be carried in the Mobile IP control messages. 111 0 1 2 3 112 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 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | Type | Sub-Type | Length | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | Data ..... 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 The proposed general structure of the Generic Extension consists 120 of the following fields: 122 Type is the type which describe a collection of extensions which 123 has a common data type (see A.1, A.2, A.3). 125 Sub-Type is a unique number given to each member in the 126 aggregated type. Sub-Type values between of 200 through 127 255 are reserved for future use and standardization. 129 Length indicates the length (in bytes) of the data field within 130 this Extension. It does NOT include the Type, Length 131 and Sub-Type bytes. 133 Data is the data associated with this extension. This data MAY 134 be represented in many ways (see A.1, A.2, A.3) 136 Two bytes for the length field is suggested to enable providing a 137 sufficiently large space for the extension data. 139 Since this extension structure will cause an efficient usage of 140 the extension type space, it is mandatory that all the new 141 proposals for the Mobile IP WG that have new extensions MUST 142 follow this format unless there is an overwhelming reason 143 not to do so. 145 3.0 Acknowledgements 147 The authors would like to acknowledge Basavaraj Patil, Pat 148 Calhoun, Neil Justusson and C. Perkins for their input in 149 writing this draft. 151 4.0 References 153 [Calhoun99a] Calhoun, Perkins, "Mobile IP Network Access 154 Identifier Extension", draft-ietf-mobileip-mn-nai-05.txt 156 [Perkins96] Perkins, "IP mobility Support", RFC 2002, Oct 96 158 [Perkins99] Perkins, "Mobile IP Challenge/Response Extensions" 159 draft-ietf-mobileip-challenge-06.txt 161 [Bradner97] Bradner, "Key words for use in RFCs to Indicate 162 Requirement Levels", RFC 2119, Mar 97 164 A APPENDIX 166 The following are some exmples where we could use the concept 167 of the proposed extension's structure. 169 A.1 Generic Authentication Extension 171 This section defines a generic authentication extensions. 173 0 1 2 3 174 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 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Type | Sub-Type | Length | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | SPI | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Authenticator ..... 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 Type Authentication Extension type (TBD) 185 Sub-Type this field describes the type of the entity which 186 owns the Authentication Extension. The following 187 types are defined: 188 1 MN-AAA Authentication Extension 190 length The length of the Authenticator field. 192 SPI Security Parameters Index 194 Authenticator The variable length Authenticator field consists 195 random value of at least 128 bits. 197 A.2 Generic NAI Extension 199 This section defines a general purpose NAI extension for 200 different types of entities such MN, HA, FA etc. 202 0 1 2 3 203 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 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Type | Sub-Type | Length | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | NAI-INFO ..... 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 Type NAI Aggregate type (TBD) 212 length The length of the NAI-INFO field. 214 Sub-Type this field describes the type of the entity which 215 owns the NAI. The following types are defined: 216 0 MN-NAI 217 1 FA-NAI 218 2 HA-NAI 219 3 Previous FA-NAI Extension 221 NAI-INFO Contains the NAI in a string format. 223 A.3 Generic Session Key Extension 225 This section defines a general purpose security association 226 extension which carrries information necessary to establish security 227 association between different entities in the Mobile IP model 228 (e.g. MN-FA, FA-HA and MN-HA ). 230 0 1 2 3 231 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 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Type | Sub-Type | Length | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | SPI1 | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | SPI2 | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | security information ... 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 Type Generic AA Key Extension (TBD) 244 length The length of the SA-INFO field. 246 Sub-Type defines the type of entity which owns the key 247 address: 248 0 MN-HA Key Extension 249 1 MN-FA Key Extension 250 2 FA-HA Key Extension 252 SPI1 A 32-bit opaque value, indicating the SPI that the 253 mobile node must use to determine the algorithm to use 254 for recovering the security information. 256 SPI2 A 32-bit opaque value, which the mobile node MUST use 257 to index all the necessary information recovered from 258 the FA security information after it is decoded. 260 Security Information 261 The necessary information (including the 262 key, algorithm etc) required by the mobile node 263 to create a Mobility Security Assocation between 264 itself and another entity such as HA and FA. 266 Author Information: 268 Mohamed Khalil Emad Qaddoura 269 Nortel Networks Inc. Nortel Networks Inc. 270 2201 Lakeside Blvd 2201 Lakeside Blvd 271 Richardson, TX 75082-4399 Richardson, TX 75082-4399 273 Phone: +1 972 685-0564 Phone: +1 972 684-2705 274 E-mail: mkhalil@nortelnetworks.com E-mail: emadq@nortelnetworks.com 276 Raja Narayanan Haseeb Akhtar 277 Nortel Networks Inc. Nortel Networks Inc. 278 2201 Lakeside Blvd 2201 Lakeside Blvd 279 Richardson, TX 75082-4399 Richardson, TX 75082-4399 281 Phone: +1 972 684-5707 Phone: +1 972 684-8850 282 E-mail: raja@nortelnetworks.com E-mail: haseeb@nortelnetworks.com