idnits 2.17.1 draft-mkhalil-mobileip-mier-03.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 121 has weird spacing: '... Type is t...' == Line 128 has weird spacing: '...ub-Type is a ...' == Line 132 has weird spacing: '... Data is t...' == Line 197 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) == Missing Reference: 'Perkins98' is mentioned on line 83, but not defined == Missing Reference: 'Proposed' is mentioned on line 105, but not defined == Unused Reference: 'Calhoun99a' is defined on line 151, but no explicit reference was found in the text == Unused Reference: 'Perkins96' is defined on line 154, but no explicit reference was found in the text == Unused Reference: 'Perkins99' is defined on line 156, but no explicit reference was found in the text == Unused Reference: 'Bradner97' is defined on line 159, 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 (~~), 18 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 Emad Qaddoura 4 Date: Dec, 1999 Haseeb Akhtar 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." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 It is in the interest of the Mobile IP WG to conserve the 33 usage of the type field since we see many drafts proposing 34 new extensions for Mobile IP. Therefore there is a real 35 need to find ways to limit the usage of the type field in the 36 extensions structure. MIER describes a new extensions 37 structure to Mobile IP to make the extensions far more 38 extensible. 40 1.0 Introduction 42 The type field in the Mobile IP extension structure can support 43 upto 255 (skippable and not skippable) uniquely identifiable 44 extensions. With new developments/additions to Mobile IP 45 there is a strong possibility that the available space will 46 run out. 48 Mobile IP Extensions Rationalization (MIER) describes a 49 new extensions structure to solve this problem. MIER strategy 50 is to initially aggregate certain types of extensions (e.g, 51 NAI) and sub types to identify the precise extension (example 52 MN/User NAI, HA NAI etc). This will greatly reduce the usage 53 of the type field. 55 MIER proposal is a natural evolution to the existing extension 56 structure. It does not impact extensions that have been already 57 defined. 59 1.1 Terminology 61 SA - Security Association [Perkins98] 63 MN - Mobile Node [Perkins98] 65 HA - Home Agent [Perkins98] 67 FA - Foreign Agent [Perkins98] 69 AAA - Authentication, Authorization, and Accounting. 71 SPI - Security Parameters Index is a 32 bit number to index a SA 72 in a database [Perkins98]. 74 2.0 Mobile IP Extension formats 76 The extension structure proposed in this draft [Sec 2.2] is 77 applicable to new extensions that are proposed to enhance 78 Mobile IP. It does not apply to the extensions that have already 79 been defined and standardised. 81 2.1 Existing Mobile IP Extension format 83 According to [Perkins98] : Mobile IP defines a general Extension 84 mechanism to allow optional information to be carried by Mobile 85 IP control messages. Each of these Extensions is encoded in the 86 following Type-Length-Value format: 88 0 1 2 89 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 90 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 91 | Type | Length | Data ... 92 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 94 Type Indicates the particular type of Extension. 96 Length Indicates the length (in bytes) of the data field within 97 this Extension. The length does NOT include the Type and 98 Length bytes. 100 Data The particular data associated with this Extension. This 101 field may be zero or more bytes in length. The format 102 and length of the data field is determined by the type 103 and length fields. 105 2.2 New [Proposed] Mobile IP Extension format 107 This draft proposes the following structure for Mobile IP 108 extensions to be carried in the Mobile IP control messages. 110 0 1 2 3 111 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 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | Type | Length | Sub-Type | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | Data ..... 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 The proposed general structure of the Generic Extension consists 119 of the following fields: 121 Type is the type which describe a collection of extensions which 122 has a common data type (see A.1, A.2, A.3). 124 Length indicates the length (in bytes) of the data field within 125 this Extension. It does NOT include the Type, Length, rsv 126 and SubType (ST) bytes. 128 Sub-Type is a unique number given to each member in the 129 aggregated type. Sub-type values between of 200 through 130 255 are reserved for future use and standardization. 132 Data is the data associated with this extension. This data MAY 133 be represented in many ways (see A.1, A.2, A.3) 135 Two bytes for the length field is suggested to enable providing a 136 sufficiently large space for the extension data. 138 Since this extension structure will cause an efficient usage of 139 the extension type space, it is mandatory that all the new 140 proposals for the Mobile IP WG that have new extensions MUST 141 follow this format unless there is an overwhelming reason 142 not to do so. 144 3.0 Acknowledgements 146 The authors would like to acknowledge Basavaraj Patil, Pat 147 Calhoun and Neil Justusson for their input in writing this draft. 149 4.0 References 151 [Calhoun99a] Calhoun, Perkins, "Mobile IP Network Access 152 Identifier Extension", draft-ietf-mobileip-mn-nai-05.txt 154 [Perkins96] Perkins, "IP mobility Support", RFC 2002, Oct 96 156 [Perkins99] Perkins, "Mobile IP Challenge/Response Extensions" 157 draft-ietf-mobileip-challenge-06.txt 159 [Bradner97] Bradner, "Key words for use in RFCs to Indicate 160 Requirement Levels", RFC 2119, Mar 97 162 A APPENDIX 164 The following are some exmples where we could use the concept 165 of the proposed extension's structure. 167 A.1 Generic Authentication Extension 169 This section defines a generic authentication extensions. 171 0 1 2 3 172 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 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Type | length | Sub-Type | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | SPI | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Authenticator ..... 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 Type Authentication Extension type (TBD) 183 length The length of the Authenticator field. 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 SPI Security Parameters Index 192 Authenticator The variable length Authenticator field consists 193 random value of at least 128 bits. 195 A.2 Generic NAI Extension 197 This section defines a general purpose NAI extension for 198 different types of entities such MN, HA, FA etc. 200 0 1 2 3 201 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 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Type | length | Sub-Type | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | NAI-INFO ..... 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 Type NAI Aggregate type (TBD) 210 length The length of the NAI-INFO field. 212 Sub-Type this field describes the type of the entity which 213 owns the NAI. The following types are defined: 214 0 MN-NAI 215 1 FA-NAI 216 2 HA-NAI 217 3 Previous FA-NAI Extension 219 NAI-INFO Contains the NAI in a string format. 221 A.3 Generic Session Key Extension 223 This section defines a general purpose security association 224 extension which carrries information necessary to establish security 225 association between different entities in the Mobile IP model 226 (e.g. MN-FA, FA-HA and MN-HA ). 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Type | length | Sub-Type | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | SPI1 | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | SPI2 | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | security information ... 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 Type Generic AA Key Extension (TBD) 242 length The length of the SA-INFO field. 244 Sub-Type defines the type of entity which owns the key 245 address: 246 0 MN-HA Key Extension 247 1 MN-FA Key Extension 248 2 FA-HA Key Extension 250 SPI1 A 32-bit opaque value, indicating the SPI that the 251 mobile node must use to determine the algorithm to use 252 for recovering the security information. 254 SPI2 A 32-bit opaque value, which the mobile node MUST use 255 to index all the necessary information recovered from 256 the FA security information after it is decoded. 258 Security Information 259 The necessary information (including the 260 key, algorithm etc) required by the mobile node 261 to create a Mobility Security Assocation between 262 itself and another entity such as HA and FA. 264 Author Information: 266 Mohamed Khalil Emad Qaddoura 267 Nortel Networks Inc. Nortel Networks Inc. 268 2201 Lakeside Blvd 2201 Lakeside Blvd 269 Richardson, TX 75082-4399 Richardson, TX 75082-4399 271 Phone: +1 972 685-0564 Phone: +1 972 684-2705 272 E-mail: mkhalil@nortelnetworks.com E-mail: emadq@nortelnetworks.com 274 Raja Narayanan Haseeb Akhtar 275 Nortel Networks Inc. Nortel Networks Inc. 276 2201 Lakeside Blvd 2201 Lakeside Blvd 277 Richardson, TX 75082-4399 Richardson, TX 75082-4399 279 Phone: +1 972 684-5707 Phone: +1 972 684-8850 280 E-mail: raja@nortelnetworks.com E-mail: haseeb@nortelnetworks.com