idnits 2.17.1 draft-ietf-mip4-gre-key-extension-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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 date (Mar 28, 2011) is 4771 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Yegani 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track K. Leung 5 Expires: September 29, 2011 Cisco Systems 6 A. Lior 7 Bridgewater Systems 8 K. Chowdhury 9 J. Navali 10 Cisco Systems 11 Mar 28, 2011 13 GRE Key Extension for Mobile IPv4 14 draft-ietf-mip4-gre-key-extension-05.txt 16 Abstract 18 The Generic Routing Encapsulation (GRE) specification contains a Key 19 field, which MAY contain a value that is used to identify a 20 particular GRE data stream. This specification defines a new Mobile 21 IP extension that is used to exchange the value to be used in the GRE 22 Key field. This extension further allows the Mobility Agents to set 23 up the necessary protocol interfaces prior to receiving the mobile's 24 traffic. The new extension allows a foreign agent to request GRE 25 tunneling without disturbing the Home Agent behavior specified for 26 Mobile IPv4. GRE tunneling with the Key field allows the operators 27 to have home networks that consist of multiple Virtual Private 28 Networks (VPNs), which may have overlapping home addresses. When the 29 tuple < Care of Address, Home Address and Home Agent Address > is the 30 same across multiple subscriber sessions, GRE tunneling will provide 31 a means for the Foreign Agent and Home Agent to identify data streams 32 for the individual sessions based on the GRE key. In the absence of 33 this key identifier, the data streams cannot be distinguished from 34 each other, a significant drawback when using IP-in-IP tunneling. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on September 29, 2011. 53 Copyright Notice 55 Copyright (c) 2011 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. GRE-Key Extension . . . . . . . . . . . . . . . . . . . . . . . 4 73 4. Operation and Use of the GRE-Key Extension . . . . . . . . . . 4 74 4.1. Foreign Agent Requirements for GRE Tunneling Support . . . 4 75 4.2. Home Agent Requirements for GRE Tunneling Support . . . . . 5 76 4.3. Mobile Node Requirements for GRE Tunneling Support . . . . 6 77 5. GRE Key Extension and Tunneling Procedures . . . . . . . . . . 6 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 81 9. Normative references . . . . . . . . . . . . . . . . . . . . . 8 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 84 1. Introduction 86 This document specifies a new extension for use by Foreign Agent (FA) 87 operating Mobile IP for IPv4. The new extension allows a foreign 88 agent to request Generic Routing Encapsulation (GRE) [RFC2784] 89 tunneling without disturbing the Home Agent (HA) behavior specified 90 for Mobile IPv4 [RFC3344]. This extension contains the GRE key 91 [RFC2890] required for establishing a GRE tunnel between the FA and 92 the HA. 94 GRE tunneling with the Key field allows the operators to have home 95 networks that consist of multiple Virtual Private Networks (VPNs), 96 which may have overlapping home addresses. When the tuple < Care of 97 Address, Home Address and Home Agent Address > is the same across 98 multiple subscriber sessions, GRE tunneling will provide a means for 99 the FA and the HA to identify data streams for the individual 100 sessions based on the GRE key. In the absence of this key 101 identifier, the data streams cannot be distinguished from each other, 102 a significant drawback when using IP-in-IP tunneling. 104 2. Terminology 106 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. Other 109 terminology is used as already defined in [RFC3344]. 111 3. GRE-Key Extension 113 The format of the GRE-Key Extension conforms to the Extension format 114 specified for Mobile IPv4 [RFC3344]. This extension option is used 115 by the Foreign Agent to supply GRE key and other necessary 116 information to the Home Agent to establish a GRE tunnel between the 117 FA and the HA. 119 4. Operation and Use of the GRE-Key Extension 121 4.1. Foreign Agent Requirements for GRE Tunneling Support 123 The FA MUST support IP-in-IP tunneling of datagrams for Mobile IPv4 124 [RFC3344]. The FA may support GRE tunneling that can be used, for 125 example, to allow for overlapping private home IP addresses 126 [X.S0011-D]. If the FA is capable of supporting GRE encapsulation, 127 it should set the 'G' (GRE encapsulation) bit in the Flags field in 128 the Agent Advertisement message sent to the Mobile Node (MN) during 129 the Mobile IP session establishment. 131 If the MN does not set the 'G' bit, the FA MAY fall back to using IP- 132 in-IP encapsulation for the session per [RFC3344]. 134 If the MN does not set the 'G' bit and does not set the 'D' 135 (Decapsulation by mobile node) bit (i.e., the mobile node does not 136 request GRE tunneling and is not using a co-located care-of address), 137 and the local policy allows the FA to override the 'G' bit setting 138 received from the MS, the FA MUST include the GRE-Key Extension as 139 defined in this memo in the Registration Request that it propogates 140 to the HA. The presence of this extension is a request for GRE 141 encapsulation that takes precedence over the setting of the 'G' bit 142 in the Registration Request (RRQ). The FA MUST NOT modify the 'G' 143 bit in the Registration Request because it is protected by the 144 Mobile-Home Authentication Extension. 146 If the FA does not support GRE encapsulation, the FA MUST reset the 147 'G' bit in the Agent Advertisement message. In this case, if the MN 148 sets the 'G' bit in the Registration Request message, the FA returns 149 a Registration Reply (RRP) message to the MN with code 'Requested 150 Encapsulation Unavailable' (72) per [RFC3344]. 152 If the FA allows GRE encapsulation, and either the MN requested GRE 153 encapsulation or local policy dictates using GRE encapsulation for 154 the session and the 'D' bit is not set (i.e., the mobile node is not 155 using a co-located care-of address, the FA MUST include the GRE Key 156 in the GRE Key Extension in all Mobile IP Registration Requests 157 (including initial, renewal and de-registration requests) before 158 forwarding the request to the HA. The FA may include a GRE key of 159 value zero in the GRE Key Extension to signal that the HA assign GRE 160 keys in both directions. The GRE key assignment in the FA and the HA 161 is outside the scope of this memo. 163 The GRE Key Extension SHALL follow the format defined in [RFC3344]. 164 This extension SHALL be added after the MN-HA and MN-FA Challenge and 165 MN-AAA extensions (if any) and before the FA-HA Auth extension (if 166 any). 168 4.2. Home Agent Requirements for GRE Tunneling Support 170 The HA MUST follow the procedures specified in RFC 3344 in processing 171 this extension in Registration Request messages. If the HA receives 172 the GRE Key Extension in a Registration Request and does not 173 recognize this non-skippable extension, it MUST silently discard the 174 message per [RFC3344]. 176 The HA MUST follow the procedures specified in RFC 3344 in processing 177 this extension in Registration Request messages. If the HA receives 178 the GRE Key Extension in a Registration Request and does not 179 recognize this non-skippable extension, it MUST silently discard the 180 message. The HA MUST use other alternative forms of encapsulation 181 (e.g., IP-in-IP tunneling), when requested by the mobile node per 182 [RFC3344]. 184 If the HA receives the GRE Key Extension in a Registration Request 185 and recognizes the GRE Key Extension but is not configured to support 186 GRE encapsulation, it MUST send an Registration Reply with code 187 'Requested Encapsulation Unavailable (139)' [RFC3024] . 189 If the HA receives a Registration Request with a GRE Key Extension 190 but without the 'G' bit set, the HA SHOULD treat this as if 'G' bit 191 is set in the Registration Request i.e., the presence of GRE Key 192 Extension indicates a request for GRE encapsulation. 194 If the HA receives the GRE Key Extension in a Registration Request 195 and recognizes the GRE Key Extension as well as supports GRE 196 encapsulation, the following procedures should apply: 198 The HA SHOULD accept the RRQ and send a RRP with code 'Accepted (0)'. 199 The HA MUST assign a GRE key and include the GRE Key Extension in the 200 RRP before sending it to the FA. The HA MUST include the GRE Key 201 Extension in all RRPs in response to any RRQ that included GRE Key 202 Extension, when a GRE key is available for the registration. 204 If the HA receives the GRE Key Extension in the initial Registration 205 Request and recognizes the GRE Key Extension carrying a GRE key value 206 of zero, it SHOULD accept the RRQ and send a RRP with code 'Accepted 207 (0)'. The HA MUST assign GRE keys for both directions and include 208 these keys in the GRE Key Extension in the RRP before sending it to 209 the FA. The HA MUST include the GRE Key Extension in the RRP in 210 response to the initial RRQ that included GRE Key Extension, when a 211 GRE key is available for the registration. 213 4.3. Mobile Node Requirements for GRE Tunneling Support 215 If the MN is capable of supporting GRE encapsulation, it SHOULD set 216 the 'G' bit in the Flags field in the Registration Request per 217 [RFC3344]. 219 5. GRE Key Extension and Tunneling Procedures 221 GRE tunneling support for Mobile IP will permit asymmetric GRE keying 222 i.e., the FA assigns a GRE key for use in encapsulated traffic and 223 the HA can assign its own GRE key. Once the GRE keys have been 224 exchanged, the FA uses the HA-assigned key in the encapsulating GRE 225 header for reverse tunneling and the HA uses the FA-assigned key in 226 the encapsulating GRE header. 228 The format of the GRE Key Extension is as shown below. 230 The GRE Key extension MAY be included in Registration Requests or 231 Registration Replies [RFC3344]. The GRE Key extension is used to 232 inform the recipient of the Mobile IP request of the value to be used 233 in GRE's Key field. 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 | Sub-Type | Length | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Key Identifier | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 Figure 1: GRE Key Extension 245 Type 246 To be assigned by IANA. An 8-bit identifier of the GRE Key 247 Extension type (non-skippable) 249 Sub-Type 250 0 252 Length 253 4 255 Key Identifier 256 This is a four octet value assigned during registration and 257 inserted in every GRE packet of the user traffic. 259 6. IANA Considerations 261 The GRE Key extension defined in this memo is a Mobile IP extension 262 as defined in [RFC3344]. IANA should assign a Type value for this 263 Extension from the non-skippable range (0-127). 265 The GRE Key extension introduces a new sub-type numbering space where 266 the value 0 has been assigned from the range, 0 to 255. Approval of 267 new GRE Key Extension sub-type values are to be made through Expert 268 Review with Specification Required. 270 7. Security Considerations 272 This specification does not introduce any new security 273 considerations, beyond those described in [RFC3344]. 275 Despite its name, the GRE Key extension has little to do with 276 security. The word "Key" here is not used in the cryptographic sense 277 of a shared secret that must be protected, but rather is used in the 278 sense of an "index" or demultiplexing value that can be used to 279 distinguish packets belonging to a given flow within a GRE tunnel. 281 8. Acknowledgements 283 Thanks to Jun Wang, Gopal Dommety and Sri Gundavelli for their 284 helpful comments, offline discussions and reviewing the initial 285 draft. Also, Pete McCann and Simon Mizikovsky provided valuable 286 review comments. 288 9. Normative references 290 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 291 Requirement Levels", BCP 14, RFC 2119, March 1997. 293 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 294 RFC 2890, September 2000. 296 [RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP, 297 revised", RFC 3024, January 2001. 299 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 300 August 2002. 302 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 303 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 304 March 2000. 306 Authors' Addresses 308 Parviz Yegani 309 Juniper Netowrks 310 1194 North Mathilda Ave. 311 Sunnyvale, California 94089 312 U.S.A 314 Phone: +1 408-759-1973 315 Email: pyegani@juniper.net 317 Kent Leung 318 Cisco Systems Incorporated 319 170 West Tasman Drive 320 San Jose, California 95134 321 U.S.A 323 Phone: +1 408 526 5030 324 Email: kleung@cisco.com 326 Avi Lior 327 Bridgewater Systems Corporation 328 303 Terry Fox Drive 329 Ottawa, Ontario K2K 3J1 330 Canada 332 Phone: +1 613-591-6655 333 Email: avi@bridgewatersystems.com 335 Kuntal Chowdhury 336 Cisco Systems Incorporated 337 170 West Tasman Drive 338 San Jose, California 95134 339 U.S.A 341 Email: kchowdhu@cisco.com 342 Jay Navali 343 Cisco Systems Incorporated 344 170 West Tasman Drive 345 San Jose, California 95134 346 U.S.A 348 Email: jnavali@cisco.com