idnits 2.17.1 draft-lemon-vxlan-lisp-gpe-gbp-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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: o Policy Applied bit (A bit): The A bit MUST be set on a specific GBP shim header if a frame is returned to a forwarding instance that it has already visited after having been redirected at a forwarding instance along the native forwarding path to its destination by a redirection policy that matched on the value in that specific GBP shim header. If a GBP option type has the A bit set, a redirection policy that matches on this GBP option type MUST not be applied. Redirection policies MAY continue to be applied so long as they only match on GBP option types that do not have the A bit set. This procedure is necessary to prevent forwarding loops. The method that ensures that on returned frames the A bit is applied only to GBP option types involved in the match at the original redirection policy is outside the scope of this draft. Once an A bit is set on a GBP shim header, it MUST remain set. Additionally, once a GBP ID is set for a GBP option type it SHOULD not be changed to avoid redirection related loops. -- The document date (April 30, 2019) is 1815 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-19) exists of draft-ietf-lisp-gpe-06 == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-07 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Lemon, Ed. 3 Internet-Draft Broadcom 4 Intended status: Informational F. Maino 5 Expires: November 1, 2019 M. Smith 6 Cisco 7 A. Isaac 8 Juniper 9 April 30, 2019 11 Group Policy Encoding with VXLAN-GPE and LISP-GPE 12 draft-lemon-vxlan-lisp-gpe-gbp-02 14 Abstract 16 This document defines shim headers for the Generic Protocol Extension 17 for Virtual eXtensible Local Area Network (VXLAN-GPE) and for the 18 Locator/ID Separation Protocol (LISP) Generic Protocol Extension 19 (LISP-GPE) that are used to carry a Group Policy Identifier for the 20 purposes of policy enforcement. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on November 1, 2019. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.2. Abbreviations used in this document . . . . . . . . . . . 3 59 2. Treatment By Intermediate Nodes . . . . . . . . . . . . . . . 3 60 3. Group Based Policy shim header . . . . . . . . . . . . . . . 3 61 3.1. Common GBP shim header Format . . . . . . . . . . . . . . 3 62 4. Use Of Multiple GBP shim headers . . . . . . . . . . . . . . 7 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 64 5.1. VXLAN-GPE Next Protocol Value . . . . . . . . . . . . . . 7 65 5.2. LISP-GPE Next Protocol Value . . . . . . . . . . . . . . 7 66 5.3. GBP Type Values . . . . . . . . . . . . . . . . . . . . . 8 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 7. Normative References . . . . . . . . . . . . . . . . . . . . 8 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 This document defines the group-based policy (GBP) shim header for 74 VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe] and the GBP shim header for LISP- 75 GPE [I-D.ietf-lisp-gpe]. The GBP shim header carries a group policy 76 ID that is semantically equivalent to the group policy ID defined in 77 [I-D.smith-vxlan-group-policy]. 79 Group-based policy provides a more scalable alternative to access 80 control lists (ACLs) by allowing separation of source marking and 81 destination enforcement. This allows a decrease in the amount of 82 information needed at each entry node, rather than a cross product of 83 every possible source and every possible destination. It also allows 84 assigning source marking based many different possibilities, not just 85 the source address. It also allows not having to know where the 86 packet will end up since whatever the destination is can enforce the 87 policy specific to the destination service. 89 1.1. Conventions 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC 2119 [RFC2119]. 95 1.2. Abbreviations used in this document 97 GBP: Group-Based Policy 99 LISP-GPE: Locator/ID Separation Protocol Generic Protocol Extension 100 [I-D.ietf-lisp-gpe] 102 VXLAN-GPE: Virtual eXtensible Local Area Network, Generic Protocol 103 Extension [I-D.ietf-nvo3-vxlan-gpe] 105 2. Treatment By Intermediate Nodes 107 Any receiving device may use the group policy information contained 108 in the Group-Based Policy (GBP) shim header. If an intermediate 109 device applies policy based upon the GBP shim header, then it must 110 set the Policy Applied Bit, described below. 112 Because the group policy information is associated with the payload 113 (rather than the tunnel or other means by which it is conveyed), if 114 an intermediate device terminates the VXLAN-GPE or LISP-GPE tunnel 115 and reencapsulates the data in a new tunnel with the ability to 116 convey the group policy information, it SHOULD propagate the group 117 policy information and the Policy Applied bit into the new tunnel, 118 unless there is an explicit policy not to do so. If an intermediate 119 device can propagate only some of the group policy IDs, it SHOULD 120 propagate as many as it can, and it MUST select which ones to 121 propagate by the sequence that the GBP IDs are placed in the VXLAN- 122 GPE or LISP-GPE header. 124 3. Group Based Policy shim header 126 In the case of VXLAN-GPE, the Group-Based Policy (GBP) shim header 127 follows the VXLAN-GPE header, or a previous VXLAN-GPE shim header. 128 Similarly, in the case of LISP-GPE, the Group-Based Policy (GBP) shim 129 header follows the LISP-GPE header, or a previous LISP-GPE shim 130 header. 132 3.1. Common GBP shim header Format 134 The format of the GBP shim header in either a VXLAN-GPE header or a 135 LISP-GPE header is shown in Figure 1. 137 0 1 2 3 138 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 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Type | Hdr Len | Reserved | Next Protocol | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 |A| Rsvd |Ver| Reserved | Group Policy ID | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 Figure 1: Narrow Group Based Policy as a GPE Option Shim 147 o Type: 8-bit unsigned integer defining the GBP ID type. The 148 following values are defined: 150 0x00: GBP_Source_ID. A value of 0 indicates that this shim header 151 carries the Group Policy ID associated with the source of the 152 packet. 154 0x01: GBP_Destination_ID. A value of 1 indicates that this shim 155 header carries the Group Policy ID associated with the end 156 destination of the packet. 158 0x02 to 0x7F: Unassigned. For assignment by IANA, as described in 159 Section 5. 161 0x80 to 0xFF: Locally Assigned. For local assignment. 163 o If a packet carries a GBP_Destination_ID, it SHOULD also carry a 164 GBP_Source_ID. 166 o Hdr Len: 8-bit identifier that indicates the length of this GBP 167 shim header in 4-octet units excluding the option header. The 168 value of this field is 1 for this version. 170 o Reserved: The 8-bit field MUST be set to zero on transmission and 171 ignored on receipt. 173 o Next Protocol: The 8-bit field indicates the protocol header 174 immediately following this shim header. Next Protocol types are 175 encoded as specified in [I-D.ietf-nvo3-vxlan-gpe] and 176 [I-D.ietf-lisp-gpe]. 178 o Policy Applied bit (A bit): The A bit MUST be set on a specific 179 GBP shim header if a frame is returned to a forwarding instance 180 that it has already visited after having been redirected at a 181 forwarding instance along the native forwarding path to its 182 destination by a redirection policy that matched on the value in 183 that specific GBP shim header. If a GBP option type has the A bit 184 set, a redirection policy that matches on this GBP option type 185 MUST not be applied. Redirection policies MAY continue to be 186 applied so long as they only match on GBP option types that do not 187 have the A bit set. This procedure is necessary to prevent 188 forwarding loops. The method that ensures that on returned frames 189 the A bit is applied only to GBP option types involved in the 190 match at the original redirection policy is outside the scope of 191 this draft. Once an A bit is set on a GBP shim header, it MUST 192 remain set. Additionally, once a GBP ID is set for a GBP option 193 type it SHOULD not be changed to avoid redirection related loops. 195 o Reserved (Rsvd): The 5-bit field MUST be set to zero on 196 transmission and ignored on receipt. 198 o Version (Ver): The 2-bit field indicates the Version of the Group 199 Policy shim header. The initial version is 0. 201 o Reserved: These 8 bits are reserved for future use and MUST be set 202 to zero on transmission and ignored on receipt. 204 o Group Policy ID: 16-bit identifier that indicates the Group Policy 205 ID being encapsulated by this GBP shim header. The Default GBP ID 206 value is special and indicates that the GBP option was not set. 207 Packet filters SHOULD be able to match on the Default GBP ID value 208 as a way to match packets that do not have the GBP option set. 209 The default Default GBP ID is 0, but MAY be configured to be a 210 value other than 0. The allocation of Group Policy ID values is 211 outside the scope of this document. 213 An example frame format using VXLAN-GPE encapsulation is as shown 214 below: 216 0 1 2 3 217 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 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Outer Ethernet Header | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Outer IP Header | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Outer UDP Header | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 |R|R|Ver|I|P|R|O| Reserved | NP = GBP | | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ VXLAN 227 | Virtual Network Identifier (VNI) | Reserved | -GPE 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Type | Hdr Len | Reserved | Next Protocol | | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GBP 231 |A| Rsvd |Ver| Reserved | Group Policy ID | | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | | 234 : Next Protocol : 235 | | 236 +---------------------------------------------------------------+ 238 An example frame format using LISP-GPE encapsulation is as shown 239 below: 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Outer Ethernet Header | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Outer IP Header | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Outer UDP Header | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 |N|L|E|V|I|P|K|K| Nonce/Map-Version | NP = GBP | | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LISP 252 | Instance ID/Locator-Status-Bits | -GPE 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Type | Hdr Len | Reserved | Next Protocol | | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GBP 256 |A| Rsvd |Ver| Reserved | Group Policy ID | | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | | 259 : Next Protocol : 260 | | 261 +---------------------------------------------------------------+ 263 4. Use Of Multiple GBP shim headers 265 A tunnel header MAY carry multiple GBP shim headers where each GBP 266 shim header carries a unique GBP type. There MUST be only one shim 267 header of a specific GBP type per tunneled packet. 269 5. IANA Considerations 271 5.1. VXLAN-GPE Next Protocol Value 273 IANA is requested to allocate a VXLAN-GPE "Next Protocol" number for 274 GBP, which is defined in [I-D.ietf-nvo3-vxlan-gpe]. 276 +---------------+-------------+---------------+ 277 | Next Protocol | Description | Reference | 278 +---------------+-------------+---------------+ 279 | 0x80 | GBP_ID | This document | 280 +---------------+-------------+---------------+ 282 5.2. LISP-GPE Next Protocol Value 284 IANA is requested to allocate a LISP-GPE "Next Protocol" number for 285 GBP, which is defined in [I-D.ietf-lisp-gpe]. 287 +---------------+-------------+---------------+ 288 | Next Protocol | Description | Reference | 289 +---------------+-------------+---------------+ 290 | 0x80 | GBP_ID | This document | 291 +---------------+-------------+---------------+ 293 5.3. GBP Type Values 295 IANA is requested to set up a registry of "GBP Type". These are 296 8-bit values. GBP Type values in the table below are defined in this 297 draft. New values in the range of 0x02 through 0x7F are assigned via 298 Standards Action [RFC5226]. 300 +----------------+--------------------+---------------+ 301 | GBP Type Value | Description | Reference | 302 +----------------+--------------------+---------------+ 303 | 0x00 | GBP_Source_ID | This document | 304 +----------------+--------------------+---------------+ 305 | 0x01 | GBP_Destination_ID | This document | 306 +----------------+--------------------+---------------+ 307 | 0x02 - 0x7F | Unassigned | | 308 +----------------+--------------------+---------------+ 309 | 0x80 - 0xFF | Local assignment | | 310 +----------------+--------------------+---------------+ 312 6. Security Considerations 314 The same security considerations applied to 315 [I-D.ietf-nvo3-vxlan-gpe], [I-D.ietf-lisp-gpe], and to 316 [I-D.smith-vxlan-group-policy] apply to this document. 318 Additionally, the security policy value carried in the GBP shim 319 header impacts security directly. There is a risk that this 320 identifier could be altered. Accordingly, the network should be 321 designed such that this shim header can be inserted only by trusted 322 entities, and can not be altered before reaching the destination. 323 This can be mitigated through physical security of the network and/or 324 by encryption or validation of the entire packet, including the GBP. 326 7. Normative References 328 [I-D.ietf-lisp-gpe] 329 Maino, F., Lemon, J., Agarwal, P., Lewis, D., and M. 330 Smith, "LISP Generic Protocol Extension", draft-ietf-lisp- 331 gpe-06 (work in progress), September 2018. 333 [I-D.ietf-nvo3-vxlan-gpe] 334 Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol 335 Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-07 (work 336 in progress), April 2019. 338 [I-D.smith-vxlan-group-policy] 339 Smith, M. and L. Kreeger, "VXLAN Group Policy Option", 340 draft-smith-vxlan-group-policy-05 (work in progress), 341 October 2018. 343 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 344 Requirement Levels", BCP 14, RFC 2119, 345 DOI 10.17487/RFC2119, March 1997, 346 . 348 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 349 IANA Considerations Section in RFCs", RFC 5226, 350 DOI 10.17487/RFC5226, May 2008, 351 . 353 Authors' Addresses 355 John Lemon (editor) 356 Broadcom Inc. 357 270 Innovation Drive 358 San Jose, CA 95134 359 USA 361 Email: john.lemon@broadcom.com 363 Fabio Maino 364 Cisco Systems 366 Email: fmaino@cisco.com 368 Michael Smith 369 Cisco Systems 371 Email: michsmit@cisco.com 372 Aldrin Isaac 373 Juniper Networks 374 1133 Innovation Way 375 Sunnyvale, CA 94089 376 USA 378 Email: aldrin.isaac@gmail.com