idnits 2.17.1 draft-ietf-mip4-gre-key-extension-03.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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Oct 15, 2010) is 4935 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 (~~), 3 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: April 18, 2011 Cisco Systems 6 A. Lior 7 Bridgewater Systems 8 K. Chowdhury 9 J. Navali 10 Cisco Systems 11 Oct 15, 2010 13 GRE Key Extension for Mobile IPv4 14 draft-ietf-mip4-gre-key-extension-03.txt 16 Abstract 18 The GRE specification contains a Key field, which MAY contain a value 19 that is used to identify a particular GRE data stream. This 20 specification defines a new Mobile IP extension that is used to 21 exchange the value to be used in the GRE Key field. This extension 22 further allows the Mobility Agents to set up the necessary protocol 23 interfaces prior to receiving the mobile's traffic. The new 24 extension allows a foreign agent to request GRE tunneling without 25 disturbing the Home Agent behavior specified for Mobile IPv4. GRE 26 tunneling with the Key field allows the operators to have home 27 networks that consist of multiple Virtual Private Networks (VPNs), 28 which may have overlapping home addresses. When the tuple < Care of 29 Address, Home Address and Home Agent Address > is the same across 30 multiple subscriber sessions, GRE tunneling will provide a means for 31 the FA and HA to identify data streams for the individual sessions 32 based on the GRE key. In the absence of this key identifier, the 33 data streams cannot be distinguished from each other, a significant 34 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 April 18, 2011. 53 Copyright Notice 55 Copyright (c) 2010 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 This document may contain material from IETF Documents or IETF 69 Contributions published or made publicly available before November 70 10, 2008. The person(s) controlling the copyright in some of this 71 material may not have granted the IETF Trust the right to allow 72 modifications of such material outside the IETF Standards Process. 73 Without obtaining an adequate license from the person(s) controlling 74 the copyright in such materials, this document may not be modified 75 outside the IETF Standards Process, and derivative works of it may 76 not be created outside the IETF Standards Process, except to format 77 it for publication as an RFC or to translate it into languages other 78 than English. 80 Table of Contents 82 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 83 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 84 3. GRE-Key Extension . . . . . . . . . . . . . . . . . . . . . . . 4 85 4. Operation and Use of the GRE-Key Extension . . . . . . . . . . 4 86 4.1. Foreign Agent Requirements for GRE Tunneling Support . . . 4 87 4.2. Home Agent Requirements for GRE Tunneling Support . . . . . 5 88 4.3. Mobile Node Requirements for GRE Tunneling Support . . . . 6 89 5. GRE Key Extension and Tunneling Procedures . . . . . . . . . . 6 90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 92 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 93 9. Normative references . . . . . . . . . . . . . . . . . . . . . 8 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 96 1. Introduction 98 This document specifies a new extension for use by Foreign Agents 99 operating Mobile IP for IPv4. The new extension allows a foreign 100 agent to request GRE tunneling without disturbing the Home Agent 101 behavior specified for Mobile IPv4 [RFC3344]. This extension 102 contains the GRE key [RFC2890] required for establishing a GRE tunnel 103 between the FA and the HA. 105 GRE tunneling with the Key field allows the operators to have home 106 networks that consist of multiple Virtual Private Networks (VPNs), 107 which may have overlapping home addresses. When the tuple < Care of 108 Address, Home Address and Home Agent Address > is the same across 109 multiple subscriber sessions, GRE tunneling will provide a means for 110 the FA and the HA to identify data streams for the individual 111 sessions based on the GRE key. In the absence of this key 112 identifier, the data streams cannot be distinguished from each other, 113 a significant drawback when using IP-in-IP tunneling. 115 2. Terminology 117 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. Other 120 terminology is used as already defined in [RFC3344]. 122 3. GRE-Key Extension 124 The format of the GRE-Key Extension conforms to the Extension format 125 specified for Mobile IPv4 [RFC3344]. This extension option is used 126 by the Foreign Agent to supply GRE key and other necessary 127 information to the Home Agent to establish a GRE tunnel between the 128 FA and the HA. 130 4. Operation and Use of the GRE-Key Extension 132 4.1. Foreign Agent Requirements for GRE Tunneling Support 134 The FA MUST support IP-in-IP tunneling of datagrams for Mobile IPv4 135 [RFC3344]. The FA may support GRE tunneling that can be used, for 136 example, to allow for overlapping private home IP addresses 137 [X.S0011-D]. If the FA is capable of supporting GRE encapsulation, 138 it should set the 'G' bit in the Flags field in the Agent 139 Advertisement message sent to the MN during the Mobile IP session 140 establishment. 142 If the MN does not set the 'G' bit, the FA MAY fall back to using IP- 143 in-IP encapsulation for the session per [RFC3344]. 145 If the MN does not set both the 'G' bit and the 'D' bit (i.e., the 146 mobile node is not using a co-located care-of address), and the local 147 policy allows the FA to override the 'G' bit setting received from 148 the MS, the FA MUST include the GRE-Key Extension as defined in this 149 memo in the Registration Request that it propogates to the HA. The 150 presence of this extension is a request for GRE encapsulation that 151 takes precedence over the setting of the 'G' bit in the Registration 152 Request. The FA MUST NOT modify the 'G' bit in the Registration 153 Request because it is protected by the Mobile-Home Authentication 154 Extension. 156 If the FA does not support GRE encapsulation, the FA MUST reset the 157 'G' bit in the Agent Advertisement message. In this case, if the MN 158 sets the 'G' bit in the Registration Request message, the FA returns 159 a Registration Reply message to the MN with code 'Requested 160 Encapsulation Unavailable' (72) per [RFC3344]. 162 If the FA allows GRE encapsulation, and either the MN requested GRE 163 encapsulation or local policy dictates using GRE encapsulation for 164 the session and the 'D' bit is not set (i.e., the mobile node is not 165 using a co-located care-of address, the FA MUST include the GRE Key 166 in the GRE Key Extension in all Mobile IP Registration Requests 167 (including initial, renewal and de-registration requests) before 168 forwarding the request to the HA. The FA may include a GRE key of 169 value zero in the GRE Key Extension to signal that the HA assign GRE 170 keys in both directions. The GRE key assignment in the FA and the HA 171 is outside the scope of this memo. 173 The GRE Key Extension SHALL follow the format defined in [RFC3344]. 174 This extension SHALL be added after the MN-HA and MN-FA Challenge and 175 MN-AAA extensions (if any) and before the FA-HA Auth extension (if 176 any). 178 4.2. Home Agent Requirements for GRE Tunneling Support 179 [RFC3344] 181 The HA MUST follow the procedures specified in RFC 3344 in processing 182 this extension in Registration Request messages. If the HA receives 183 the GRE Key Extension in a Registration Request and does not 184 recognize this non-skippable extension, it MUST silently discard the 185 message. The HA MUST use other alternative forms of encapsulation 186 (e.g., IP-in-IP tunneling), when requested by the mobile node per 187 [RFC3344]. 189 If the HA receives the GRE Key Extension in a Registration Request 190 and recognizes the GRE Key Extension but is not configured to support 191 GRE encapsulation, it MUST send an RRP with code 'Requested 192 Encapsulati on Unavailable (139)' [RFC3024] . 194 If the HA receives a Registration Request with a GRE Key Extension 195 but without the 'G' bit set, the HA SHOULD treat this as if 'G' bit 196 is set in the Registration Request i.e., the presence of GRE Key 197 Extension indicates a request for GRE encapsulation. 199 If the HA receives the GRE Key Extension in a Registration Request 200 and recognizes the GRE Key Extension as well as supports GRE 201 encapsulation, the following procedures should apply: 203 The HA SHOULD accept the RRQ and send a RRP with code 'Accepted (0)'. 204 The HA MUST assign a GRE key and include the GRE Key Extension in the 205 RRP before sending it to the FA. The HA MUST include the GRE Key 206 Extension in all RRPs in response to any RRQ that included GRE Key 207 Extension, when a GRE key is available for the registration. 209 If the HA receives the GRE Key Extension in the initial Registration 210 Request and recognizes the GRE Key Extension carrying a GRE key value 211 of zero, it SHOULD accept the RRQ and send a RRP with code 'Accepted 212 (0)'. The HA MUST assign GRE keys for both directions and include 213 these keys in the GRE Key Extension in the RRP before sending it to 214 the FA. The HA MUST include the GRE Key Extension in the RRP in 215 response to the initial RRQ that included GRE Key Extension, when a 216 GRE key is available for the registration. 218 4.3. Mobile Node Requirements for GRE Tunneling Support 220 If the MN is capable of supporting GRE encapsulation, it SHOULD set 221 the 'G' bit in the Flags field in the Registration Request per 222 [RFC3344]. 224 5. GRE Key Extension and Tunneling Procedures 226 GRE tunneling support for Mobile IP will permit asymmetric GRE keying 227 i.e., the FA assigns a GRE key for use in encapsulated traffic and 228 the HA can assign its own GRE key. Once the GRE keys have been 229 exchanged, the FA uses the HA-assigned key in the encapsulating GRE 230 header for reverse tunneling and the HA uses the FA-assigned key in 231 the encapsulating GRE header. 233 The format of the GRE Key Extension is as shown below. 235 The GRE Key extension MAY be included in Registration Requests 236 [RFC3344]. The GRE Key extension is used to inform the recipient of 237 the Mobile IP request of the value to be used in GRE's Key field. 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Type | Sub-Type | Length | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Key Identifier | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 Figure 1: GRE Key Extension 249 Type 250 To be assigned by IANA. An 8-bit identifier of the GRE Key 251 Extension type (non-skippable) 253 Sub-Type 254 0 256 Length 257 4 259 Key Identifier 260 This is a four octet value assigned during registration and 261 inserted in every GRE packet of the user traffic. 263 6. IANA Considerations 265 The GRE Key extension defined in this memo is a Mobile IP extension 266 as defined in [RFC3344]. IANA should assign a Type value for this 267 Extension from the non-skippable range (0-127). 269 7. Security Considerations 271 This specification does not introduce any new security 272 considerations, beyond those described in [RFC3344] 274 Despite its name, the GRE Key extension has little to do with 275 security. The word "Key" here is not used in the cryptographic sense 276 of a shared secret that must be protected, but rather is used in the 277 sense of an "index" or demultiplexing value that can be used to 278 distinguish packets belonging to a given flow within a GRE tunnel. 280 8. Acknowledgements 282 Thanks to Jun Wang, Gopal Dommety and Sri Gundavelli for their 283 helpful comments, offline discussions and reviewing the initial 284 draft. Also, Pete McCann and Simon Mizikovsky provided valuable 285 review comments. 287 9. Normative references 289 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 290 Requirement Levels", BCP 14, RFC 2119, March 1997. 292 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 293 RFC 2890, September 2000. 295 [RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP, 296 revised", RFC 3024, January 2001. 298 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 299 August 2002. 301 Authors' Addresses 303 Parviz Yegani 304 Juniper Netowrks 305 1194 North Mathilda Ave. 306 Sunnyvale, California 94089 307 U.S.A 309 Phone: +1 408-759-1973 310 Email: pyegani@juniper.net 312 Kent Leung 313 Cisco Systems Incorporated 314 170 West Tasman Drive 315 San Jose, California 95134 316 U.S.A 318 Phone: +1 408 526 5030 319 Email: kleung@cisco.com 320 Avi Lior 321 Bridgewater Systems Corporation 322 303 Terry Fox Drive 323 Ottawa, Ontario K2K 3J1 324 Canada 326 Phone: +1 613-591-6655 327 Email: avi@bridgewatersystems.com 329 Kuntal Chowdhury 330 Cisco Systems Incorporated 331 170 West Tasman Drive 332 San Jose, California 95134 333 U.S.A 335 Email: kchowdhu@cisco.com 337 Jay Navali 338 Cisco Systems Incorporated 339 170 West Tasman Drive 340 San Jose, California 95134 341 U.S.A 343 Email: jnavali@cisco.com