idnits 2.17.1 draft-ietf-mip4-gre-key-extension-02.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 (Sep 27, 2010) is 4954 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: March 31, 2011 Cisco Systems 6 A. Lior 7 Bridgewater Systems 8 K. Chowdhury 9 J. Navali 10 Cisco Systems 11 Sep 27, 2010 13 GRE Key Extension for Mobile IPv4 14 draft-ietf-mip4-gre-key-extension-02.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 March 31, 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 . . . . . . . . . . . . . . . . . . . . . . . 7 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 the 'G' bit, and the local policy allows the 146 FA to override the 'G' bit setting received from the MS, the FA MUST 147 include the GRE-Key Extension as defined in this memo in the 148 Registration Request that it progates to the HA. The presence of 149 this extension is a request for GRE encapsulation that takes 150 precedence over the setting of the 'G' bit in the Registration 151 Request. The FA MUST NOT modify the 'G' bit in the Registration 152 Request because it is protected by the Mobile-Home Authentication 153 Extension. 155 If the FA does not support GRE encapsulation, the FA MUST reset the 156 'G' bit in the Agent Advertisement message. In this case, if the MN 157 sets the 'G' bit in the Registration Request message, the FA returns 158 a Registration Reply message to the MN with code 'Requested 159 Encapsulation Unavailable' (72) per [RFC3344]. 161 If the FA allows GRE encapsulation, and either the MN requested GRE 162 encapsulation or local policy dictates using GRE encapsulation for 163 the session, the FA MUST include the GRE Key in the GRE Key Extension 164 in all Mobile IP Registration Requests (including initial, renewal 165 and de-registration requests) before forwarding the request to the 166 HA. The FA may include a GRE key of value zero in the GRE Key 167 Extension to signal that the HA assign GRE keys in both directions. 168 The GRE key assignment in the FA and the HA is outside the scope of 169 this memo. 171 The GRE Key Extension SHALL follow the format defined in [RFC3344]. 172 This extension SHALL be added after the MN-HA and MN-FA Challenge and 173 MN-AAA extensions (if any) and before the FA-HA Auth extension (if 174 any). 176 4.2. Home Agent Requirements for GRE Tunneling Support 178 The HA MUST follow the procedures specified in RFC 3344 in processing 179 this extension in Registration Request messages. If the HA receives 180 the GRE Key Extension in a Registration Request and does not 181 recognize this non-skippable extension, it MUST silently discard the 182 message per [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 RRP with code 'Requested 187 Encapsulati on 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 231 [RFC3344]. The GRE Key extension is used to inform the recipient of 232 the Mobile IP request of the value to be used in GRE's Key field. 234 0 1 2 3 235 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 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Type | Sub-Type | Length | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Key Identifier | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 Figure 1: GRE Key Extension 244 Type 245 To be assigned by IANA. An 8-bit identifier of the GRE Key 246 Extension type (non-skippable) 248 Sub-Type 249 0 251 Length 252 4 254 Key Identifier 255 This is a four octet value assigned during registration and 256 inserted in every GRE packet of the user traffic. 258 6. IANA Considerations 260 The GRE Key extension defined in this memo is a Mobile IP extension 261 as defined in [RFC3344]. IANA should assign a Type value for this 262 Extension from the non-skippable range (0-127). 264 7. Security Considerations 266 This specification does not introduce any new security 267 considerations, beyond those described in [RFC3344] 269 Despite its name, the GRE Key extension has little to do with 270 security. The word "Key" here is not used in the cryptographic sense 271 of a shared secret that must be protected, but rather is used in the 272 sense of an "index" or demultiplexing value that can be used to 273 distinguish packets belonging to a given flow within a GRE tunnel. 275 8. Acknowledgements 277 Thanks to Jun Wang, Gopal Dommety and Sri Gundavelli for their 278 helpful comments, offline discussions and reviewing the initial 279 draft. Also, Pete McCann and Simon Mizikovsky provided valuable 280 review comments. 282 9. Normative references 284 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 285 Requirement Levels", BCP 14, RFC 2119, March 1997. 287 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 288 RFC 2890, September 2000. 290 [RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP, 291 revised", RFC 3024, January 2001. 293 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 294 August 2002. 296 Authors' Addresses 298 Parviz Yegani 299 Juniper Netowrks 300 1194 North Mathilda Ave. 301 Sunnyvale, California 94089 302 U.S.A 304 Phone: +1 408-759-1973 305 Email: pyegani@juniper.net 307 Kent Leung 308 Cisco Systems Incorporated 309 170 West Tasman Drive 310 San Jose, California 95134 311 U.S.A 313 Phone: +1 408 526 5030 314 Email: kleung@cisco.com 315 Avi Lior 316 Bridgewater Systems Corporation 317 303 Terry Fox Drive 318 Ottawa, Ontario K2K 3J1 319 Canada 321 Phone: +1 613-591-6655 322 Email: avi@bridgewatersystems.com 324 Kuntal Chowdhury 325 Cisco Systems Incorporated 326 170 West Tasman Drive 327 San Jose, California 95134 328 U.S.A 330 Email: kchowdhu@cisco.com 332 Jay Navali 333 Cisco Systems Incorporated 334 170 West Tasman Drive 335 San Jose, California 95134 336 U.S.A 338 Email: jnavali@cisco.com