Internet Engineering Task Force J. Lemon, Ed.
Internet-Draft Broadcom
Intended status: Informational F. Maino
Expires: November 1, 2019 M. Smith
Cisco
A. Isaac
Juniper
April 30, 2019

Group Policy Encoding with VXLAN-GPE and LISP-GPE
draft-lemon-vxlan-lisp-gpe-gbp-02

Abstract

This document defines shim headers for the Generic Protocol Extension for Virtual eXtensible Local Area Network (VXLAN-GPE) and for the Locator/ID Separation Protocol (LISP) Generic Protocol Extension (LISP-GPE) that are used to carry a Group Policy Identifier for the purposes of policy enforcement.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on November 1, 2019.

Copyright Notice

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

1. Introduction

This document defines the group-based policy (GBP) shim header for VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe] and the GBP shim header for LISP-GPE [I-D.ietf-lisp-gpe]. The GBP shim header carries a group policy ID that is semantically equivalent to the group policy ID defined in [I-D.smith-vxlan-group-policy].

Group-based policy provides a more scalable alternative to access control lists (ACLs) by allowing separation of source marking and destination enforcement. This allows a decrease in the amount of information needed at each entry node, rather than a cross product of every possible source and every possible destination. It also allows assigning source marking based many different possibilities, not just the source address. It also allows not having to know where the packet will end up since whatever the destination is can enforce the policy specific to the destination service.

1.1. Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

1.2. Abbreviations used in this document

GBP:
Group-Based Policy
LISP-GPE:
Locator/ID Separation Protocol Generic Protocol Extension [I-D.ietf-lisp-gpe]
VXLAN-GPE:
Virtual eXtensible Local Area Network, Generic Protocol Extension [I-D.ietf-nvo3-vxlan-gpe]

2. Treatment By Intermediate Nodes

Any receiving device may use the group policy information contained in the Group-Based Policy (GBP) shim header. If an intermediate device applies policy based upon the GBP shim header, then it must set the Policy Applied Bit, described below.

Because the group policy information is associated with the payload (rather than the tunnel or other means by which it is conveyed), if an intermediate device terminates the VXLAN-GPE or LISP-GPE tunnel and reencapsulates the data in a new tunnel with the ability to convey the group policy information, it SHOULD propagate the group policy information and the Policy Applied bit into the new tunnel, unless there is an explicit policy not to do so. If an intermediate device can propagate only some of the group policy IDs, it SHOULD propagate as many as it can, and it MUST select which ones to propagate by the sequence that the GBP IDs are placed in the VXLAN-GPE or LISP-GPE header.

3. Group Based Policy shim header

In the case of VXLAN-GPE, the Group-Based Policy (GBP) shim header follows the VXLAN-GPE header, or a previous VXLAN-GPE shim header. Similarly, in the case of LISP-GPE, the Group-Based Policy (GBP) shim header follows the LISP-GPE header, or a previous LISP-GPE shim header.

3.1. Common GBP shim header Format

The format of the GBP shim header in either a VXLAN-GPE header or a LISP-GPE header is shown in Figure 1.

       
    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |   Hdr Len     |    Reserved   | Next Protocol |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|   Rsvd  |Ver|    Reserved   |       Group Policy ID         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           

Figure 1: Narrow Group Based Policy as a GPE Option Shim

An example frame format using VXLAN-GPE encapsulation is as shown below:

       
 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Outer Ethernet Header                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Outer IP Header                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Outer UDP Header                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|R|Ver|I|P|R|O|          Reserved             | NP = GBP      |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ VXLAN
|     Virtual Network Identifier (VNI)          | Reserved      |  -GPE
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |   Hdr Len     |    Reserved   | Next Protocol |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GBP
|A|   Rsvd  |Ver|    Reserved   |       Group Policy ID         |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
:                        Next Protocol                          :
|                                                               |
+---------------------------------------------------------------+

           

An example frame format using LISP-GPE encapsulation is as shown below:

       
 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Outer Ethernet Header                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Outer IP Header                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Outer UDP Header                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|P|K|K|        Nonce/Map-Version      | NP = GBP      |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LISP
|                 Instance ID/Locator-Status-Bits               | -GPE
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |   Hdr Len     |    Reserved   | Next Protocol |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GBP
|A|   Rsvd  |Ver|    Reserved   |       Group Policy ID         |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
:                        Next Protocol                          :
|                                                               |
+---------------------------------------------------------------+

           

4. Use Of Multiple GBP shim headers

A tunnel header MAY carry multiple GBP shim headers where each GBP shim header carries a unique GBP type. There MUST be only one shim header of a specific GBP type per tunneled packet.

5. IANA Considerations

5.1. VXLAN-GPE Next Protocol Value

IANA is requested to allocate a VXLAN-GPE "Next Protocol" number for GBP, which is defined in [I-D.ietf-nvo3-vxlan-gpe].

            +---------------+-------------+---------------+
            | Next Protocol | Description | Reference     |
            +---------------+-------------+---------------+
            | 0x80          | GBP_ID      | This document |
            +---------------+-------------+---------------+

5.2. LISP-GPE Next Protocol Value

IANA is requested to allocate a LISP-GPE "Next Protocol" number for GBP, which is defined in [I-D.ietf-lisp-gpe].

            +---------------+-------------+---------------+
            | Next Protocol | Description | Reference     |
            +---------------+-------------+---------------+
            | 0x80          | GBP_ID      | This document |
            +---------------+-------------+---------------+

5.3. GBP Type Values

IANA is requested to set up a registry of "GBP Type". These are 8-bit values. GBP Type values in the table below are defined in this draft. New values in the range of 0x02 through 0x7F are assigned via Standards Action [RFC5226].

            +----------------+--------------------+---------------+
            | GBP Type Value | Description        | Reference     |
            +----------------+--------------------+---------------+
            | 0x00           | GBP_Source_ID      | This document |
            +----------------+--------------------+---------------+
            | 0x01           | GBP_Destination_ID | This document |
            +----------------+--------------------+---------------+
            | 0x02 - 0x7F    | Unassigned         |               |
            +----------------+--------------------+---------------+
            | 0x80 - 0xFF    | Local assignment   |               |
            +----------------+--------------------+---------------+

6. Security Considerations

The same security considerations applied to [I-D.ietf-nvo3-vxlan-gpe], [I-D.ietf-lisp-gpe], and to [I-D.smith-vxlan-group-policy] apply to this document.

Additionally, the security policy value carried in the GBP shim header impacts security directly. There is a risk that this identifier could be altered. Accordingly, the network should be designed such that this shim header can be inserted only by trusted entities, and can not be altered before reaching the destination. This can be mitigated through physical security of the network and/or by encryption or validation of the entire packet, including the GBP.

7. Normative References

[I-D.ietf-lisp-gpe] Maino, F., Lemon, J., Agarwal, P., Lewis, D. and M. Smith, "LISP Generic Protocol Extension", Internet-Draft draft-ietf-lisp-gpe-06, September 2018.
[I-D.ietf-nvo3-vxlan-gpe] Maino, F., Kreeger, L. and U. Elzur, "Generic Protocol Extension for VXLAN", Internet-Draft draft-ietf-nvo3-vxlan-gpe-07, April 2019.
[I-D.smith-vxlan-group-policy] Smith, M. and L. Kreeger, "VXLAN Group Policy Option", Internet-Draft draft-smith-vxlan-group-policy-05, October 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, DOI 10.17487/RFC5226, May 2008.

Authors' Addresses

John Lemon (editor) Broadcom Inc. 270 Innovation Drive San Jose, CA 95134 USA EMail: john.lemon@broadcom.com
Fabio Maino Cisco Systems EMail: fmaino@cisco.com
Michael Smith Cisco Systems EMail: michsmit@cisco.com
Aldrin Isaac Juniper Networks 1133 Innovation Way Sunnyvale, CA 94089 USA EMail: aldrin.isaac@gmail.com