[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-lemon-vxlan-gpe-gbp) 00 01 02

Internet Engineering Task Force                            J. Lemon, Ed.
Internet-Draft                                                  Broadcom
Intended status: Informational                                  F. Maino
Expires: September 12, 2019                                     M. Smith
                                                                   Cisco
                                                                A. Isaac
                                                                 Juniper
                                                          March 11, 2019


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

Abstract

   This document defines header companions 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 September 12, 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



Lemon, et al.          Expires September 12, 2019               [Page 1]


Internet-Draft       GBP with VXLAN-GPE and LISP-GPE          March 2019


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Conventions . . . . . . . . . . . . . . . . . . . . . . .   2
     1.2.  Abbreviations used in this document . . . . . . . . . . .   2
   2.  Treatment By Intermediate Nodes . . . . . . . . . . . . . . .   3
   3.  Group Based Policy Sub-header . . . . . . . . . . . . . . . .   3
     3.1.  Common GBP Sub-Header Format  . . . . . . . . . . . . . .   3
   4.  Use Of Multiple GBP Sub-options . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   This document defines the group-based policy (GBP) sub-header for
   VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe] and the GBP sub-header for LISP-
   GPE [I-D.ietf-lisp-gpe].  The GBP sub-header carries a 16-bit group
   policy ID that is semantically equivalent to the 16-bit 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 [RFC2119].

1.2.  Abbreviations used in this document

   GBP:       Group-Based Policy





Lemon, et al.          Expires September 12, 2019               [Page 2]


Internet-Draft       GBP with VXLAN-GPE and LISP-GPE          March 2019


   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) sub-header.  If an intermediate
   device applies policy based upon the GBP sub-header, then it must set
   the Policy Applied Bit, described below.

   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.

3.  Group Based Policy Sub-header

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

3.1.  Common GBP Sub-Header Format

   The format of the GBP sub-header in either a VXLAN-GPE header or a
   LISP-GPE header 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Group Policy ID          |A|D|E| Res |Ver| Next Protocol |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   o  Group Policy ID: 16-bit identifier that indicates the Group Policy
      ID being encapsulated by this GBP sub-header.  The allocation of
      Group Policy ID values is outside the scope of this document.

   o  Policy Applied bit (A bit): The A bit is set to 0 to indicate that
      the group policy has not (yet) been applied to this packet.  Group
      policies MUST be applied by devices when the A bit is set to 0 and
      the destination Group has been determined.  Devices that apply the



Lemon, et al.          Expires September 12, 2019               [Page 3]


Internet-Draft       GBP with VXLAN-GPE and LISP-GPE          March 2019


      group policy MUST set the A bit to 1 after the policy has been
      applied.  The A bit is set to 1 to indicate that the group policy
      has already been applied to this packet.  Policies that redirect
      the packet MUST NOT be applied by devices when the A bit is set.
      Policies that cause the packet to be dropped MAY be applied.

   o  Don't Learn bit (D bit): The D bit is set to 1 to indicate that
      the egress VTEP or the Egress Tunnel Router MUST NOT learn the
      source address of the encapsulated frame.

   o  End Destination bit (E bit): The E bit is set to 0 to represent
      the Group Policy ID associated with the source of the packet.  The
      E bit is set to 1 to represent the Group Policy ID associated with
      the end destination of the packet.  Note that if the packet
      carryies a destination group sub-header, it MUST also carry a
      source group sub-header.

   o  Reserved (Res): The 3-bit field MUST be set to zero on
      transmission and ignored on receipt.

   o  Version (Ver): The 2-bit field indicates the Version of the Group
      Policy sub-header.  The initial version is 0.

   o  Next Protocol: The 8-bit field indicates the protocol header
      immediately following this sub-header.  Next Protocol types are
      encoded as specified in [I-D.ietf-nvo3-vxlan-gpe] and
      [I-D.ietf-lisp-gpe].

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





















Lemon, et al.          Expires September 12, 2019               [Page 4]


Internet-Draft       GBP with VXLAN-GPE and LISP-GPE          March 2019


  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
 |      Group Policy ID          |A|D|E| Res |Ver| Next Protocol | GBP
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
 |                                                               |
 :                        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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
  |      Group Policy ID          |A|D|E| Res |Ver| Next Protocol | GBP
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
  |                                                               |
  :                        Next Protocol                          :
  |                                                               |
  +---------------------------------------------------------------+







Lemon, et al.          Expires September 12, 2019               [Page 5]


Internet-Draft       GBP with VXLAN-GPE and LISP-GPE          March 2019


4.  Use Of Multiple GBP Sub-options

   A tunnel header MAY carry multiple GBP option headers where each GBP
   option header is of a unique GBP type.  However, only one header of a
   specific GBP type is allowed per tunneled packet.

5.  IANA Considerations

   IANA is requested to add a new value to registry of "Next Protocol",
   which is defined in [I-D.ietf-nvo3-vxlan-gpe].  The new value of 6
   will signify a GBP sub-header as the next protocol.

   IANA is requested to add a new value to registry of "Next Protocol",
   which is defined in [I-D.ietf-lisp-gpe].  The new value of 6 will
   signify a GBP sub-header as the next protocol.

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 sub-header
   impacts security directly.  There is a risk that this identifier
   could be altered.  Accordingly, the network should be designed such
   that this sub-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", draft-ietf-lisp-
              gpe-06 (work in progress), September 2018.

   [I-D.ietf-nvo3-vxlan-gpe]
              Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
              Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (work
              in progress), April 2018.

   [I-D.smith-vxlan-group-policy]
              Smith, M. and L. Kreeger, "VXLAN Group Policy Option",
              draft-smith-vxlan-group-policy-05 (work in progress),
              October 2018.





Lemon, et al.          Expires September 12, 2019               [Page 6]


Internet-Draft       GBP with VXLAN-GPE and LISP-GPE          March 2019


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

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
















Lemon, et al.          Expires September 12, 2019               [Page 7]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/