HTTP Origin-Bound Authentication (HOBA)
draft-ietf-httpauth-hoba-10

Internet Engineering Task Force (IETF)                            B. Wen
Request for Comments: 8466                                       Comcast
Category: Standards Track                               G. Fioccola, Ed.
ISSN: 2070-1721                                           Telecom Italia
                                                                  C. Xie
                                                           China Telecom
                                                                L. Jalil
                                                                 Verizon
                                                            October 2018

                         A YANG Data Model for
        Layer 2 Virtual Private Network (L2VPN) Service Delivery

Abstract

   This document defines a YANG data model that can be used to configure
   a Layer 2 provider-provisioned VPN service.  It is up to a management
   system to take this as an input and generate specific configuration
   models to configure the different network elements to deliver the
   service.  How this configuration of network elements is done is out
   of scope for this document.

   The YANG data model defined in this document includes support for
   point-to-point Virtual Private Wire Services (VPWSs) and multipoint
   Virtual Private LAN Services (VPLSs) that use Pseudowires signaled
   using the Label Distribution Protocol (LDP) and the Border Gateway
   Protocol (BGP) as described in RFCs 4761 and 6624.

   The YANG data model defined in this document conforms to the Network
   Management Datastore Architecture defined in RFC 8342.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8466.

Wen, et al.                  Standards Track                    [Page 1]
RFC 8466               L2VPN Service Model (L2SM)           October 2018

Copyright Notice

   Copyright (c) 2018 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  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
       1.1.1.  Requirements Language . . . . . . . . . . . . . . . .   5
     1.2.  Tree Diagrams . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  The Layer 2 VPN Service Model . . . . . . . . . . . . . . . .   7
     3.1.  Layer 2 VPN Service Types . . . . . . . . . . . . . . . .   7
     3.2.  Layer 2 VPN Physical Network Topology . . . . . . . . . .   7
   4.  Service Data Model Usage  . . . . . . . . . . . . . . . . . .   9
   5.  Design of the Data Model  . . . . . . . . . . . . . . . . . .  11
     5.1.  Features and Augmentation . . . . . . . . . . . . . . . .  20
     5.2.  VPN Service Overview  . . . . . . . . . . . . . . . . . .  20
       5.2.1.  VPN Service Type  . . . . . . . . . . . . . . . . . .  21
       5.2.2.  VPN Service Topologies  . . . . . . . . . . . . . . .  22
         5.2.2.1.  Route Target Allocation . . . . . . . . . . . . .  22
         5.2.2.2.  Any-to-Any  . . . . . . . . . . . . . . . . . . .  22
         5.2.2.3.  Hub-and-Spoke . . . . . . . . . . . . . . . . . .  22
         5.2.2.4.  Hub-and-Spoke Disjoint  . . . . . . . . . . . . .  23
       5.2.3.  Cloud Access  . . . . . . . . . . . . . . . . . . . .  24
       5.2.4.  Extranet VPNs . . . . . . . . . . . . . . . . . . . .  27
       5.2.5.  Frame Delivery Service  . . . . . . . . . . . . . . .  28
     5.3.  Site Overview . . . . . . . . . . . . . . . . . . . . . .  30
       5.3.1.  Devices and Locations . . . . . . . . . . . . . . . .  31
       5.3.2.  Site Network Accesses . . . . . . . . . . . . . . . .  32
         5.3.2.1.  Bearer  . . . . . . . . . . . . . . . . . . . . .  33
         5.3.2.2.  Connection  . . . . . . . . . . . . . . . . . . .  33
     5.4.  Site Roles  . . . . . . . . . . . . . . . . . . . . . . .  38

Wen, et al.                  Standards Track                    [Page 2]
RFC 8466               L2VPN Service Model (L2SM)           October 2018

     quot;.well-known/hoba/getchal".  If successful,
   the response MUST contain a fresh (base64url encoded) HOBA challenge
   for this origin in the body of the response.  Whitespace in the
   response MUST be ignored.

7.  Mandatory-to-Implement Algorithms

   RSA-SHA256 MUST be supported.  HOBA implementations MUST use RSA-
   SHA256 if it is provided by the underlying cryptographic libraries.
   RSA-SHA1 MAY be used.  RSA modulus lengths of at least 2048 bits
   SHOULD be used.  RSA indicates the RSASSA-PKCS1-v1_5 algorithm
   defined in Section 8.2 of [RFC3447], and SHA-1 and SHA-256 are
   defined in [SHS].  Keys with moduli shorter than 2048 bits SHOULD

Farrell, et al.           Expires July 12, 2015                [Page 17]
Internet-Draft        HTTP Origin-Bound Auth (HOBA)         January 2015

   only be used in cases where generating 2048-bit (or longer) keys is
   impractical, e.g. on very constrained or old devices.

8.  Security Considerations

   Binding my CPK with someone else's account would be fun and
   profitable so SHOULD be appropriately hard.  In particular URLs or
   other values generated by the server as part of any CPK binding
   process MUST be hard to guess, for whatever level of difficulty is
   chosen by the server.  The server SHOULD NOT allow a random guess to
   reveal whether or not an account exists.

   If key binding was server-selected then a bad actor could bind
   different accounts belonging to the user from the network with
   possible bad consequences, especially if one of the private keys was
   compromised somehow.

   When the max-age parameter is not zero, then a HOBA signature has a
   property that is like a bearer token for the relevant number of
   seconds: it can be replayed for a server-selected duration.
   Similarly, for HOBA-js, signatures might be replayable depending on
   the specific implementation.  The security considerations of
   [RFC6750] therefore apply in any case where the HOBA signature can be
   replayed.  Server administrators can set the max-age to the minimum
   acceptable value in such cases, which would often be expected to be
   just a few seconds.  There seems to be no reason to ever set the max-
   age more than a few minutes; the value ought also decrease over time
   as device capabilities improve.  The administrator will most likely
   want to set the max-age to something that is not too short for the
   slowest signing device that is significant for that site.

8.1.  Privacy considerations

   HOBA does impact to some extent on privacy and could be considered to
   represent a super-cookie to the server, or to any entity on the path
   from UA to HTTP server that can see the HOBA signature.  This is
   because we need to send a key identifier as part of the signature and
   that will not vary for a given key.  For this reason, and others, it
   is strongly RECOMMENDED to only use HOBA over server-authenticated
   TLS and to migrate web sites using HOBA to only use "https" URLs.

Farrell, et al.           Expires July 12, 2015                [Page 18]
Internet-Draft        HTTP Origin-Bound Auth (HOBA)         January 2015

   UAs SHOULD provide users a way to manage their CPKs.  Ideally, there
   would be a way for a user to maintain their HOBA details for a site
   while at the same time deleting other site information such as
   cookies or non-HOBA HTML5 LocalStorage.  However, as this is likely
   to be complex and appropriate user interfaces counter intutitive, we
   expect that UAs that implement HOBA will likely treat HOBA
   information as just some more site data, that would disappear should
   the user choose to "forget" that site.

   Device identifiers are intended to specify classes of device in a way
   that can assist with registration and with presentation to the user
   of information about previous sessions, e.g.  last login time.
   Device identifier types MUST NOT be privacy sensitive, with values
   that would allow tracking a user in unexpected ways.  In particular,
   using an device identifier type that is analogous to the
   International Mobile Equipment Identifier (IMEI) would be a really
   bad idea and is the reason for the MUST NOT above.  In that case
   "mobile phone" could be an acceptable choice.

   If possible, implementations ought encourage use of device identifier
   values that are not personally identifying except for the user
   concerned, for example "Alice's mobile" is likely to be chosen and is
   somewhat identifying but "Alice's phone: UUID 1234-5567-89abc-def0"
   would be a very bad choice.

8.2.  localStorage Security for Javascript

   The use of localStorage (likely with a non-WebCrypto implementation
   of HOBA-js) will undoubtedly be a cause for concern. localStorage
   uses the same-origin model which says that the scheme, domain and
   port define a localStorage instance.  Beyond that, any code executing
   will have access to private keying material.  Of particular concern
   are XSS attacks which could conceivably take the keying material and
   use it to create UAs under the control of an attacker.  But XSS
   attacks are in reality across the board devastating since they can
   and do steal credit card information, passwords, perform illicit
   acts, etc, etc.  It's not clear that we introduce unique threats from
   which clear text passwords don't already suffer.

Farrell, et al.           Expires July 12, 2015                [Page 19]
Internet-Draft        HTTP Origin-Bound Auth (HOBA)         January 2015

   Another source of concern is local access to the keys.  That is, if
   an attacker has access to the UA itself, they could snoop on the key
   through a javascript console, or find the file(s) that implement
   localStorage on the host computer.  Again it's not clear that we are
   worse in this regard because the same attacker could get at browser
   password files, etc too.  One possible mitigation is to encrypt the
   keystore with a password/pin the user supplies.  This may sound
   counter intuitive, but the object here is to keep passwords off of
   servers to mitigate the multiplier effect of a large scale compromise
   [bland] because of shared passwords across sites.

   It's worth noting that HOBA uses asymmetric keys and not passwords
   when evaluating threats.  As various password database leaks have
   shown, the real threat of a password breach is not just to the site
   that was breached, it's all of the sites a user used the same
   password on too.  That is, the collateral damage is severe because
   password reuse is common.  Storing a password in localStorage would
   also have a similar multiplier effect for an attacker, though perhaps
   on a smaller scale than a server-side compromise: one successful
   crack gains the attacker potential access to hundreds if not
   thousands of sites the user visits.  HOBA does not suffer from that
   attack multiplier since each asymmetric key pair is unique per site/
   UA/user.

8.3.  Multiple Accounts on One User Agent

   A shared UA with multiple accounts is possible if the account
   identifier is stored along with the asymmetric key pair binding them
   to one another.  Multiple entries can be kept, one for each account,
   and selected by the current user.  This, of course, is fraught with
   the possibility for abuse, since a server is potentially enrolling
   the device for a long period and the user may not want to have to be
   responsible for the credential for that long.  To alleviate this
   problem, the user could request that the credential be erased from
   the browser.  Similarly, during the enrollment phase, a user could
   request that the key pair only be kept for a certain amount of time,
   or that it not be stored beyond the current browser session.
   However, all such features really ought be part of the operating
   system or platform and not part of a HOBA implementation so those are
   not discussed further.

8.4.  Injective Mapping for HOBA-TBS

   The repeated length fields in the HOBA-TBS structure are present in
   order to ensure that there is no possibility that the catenation of
   different input values can cause confusion that might lead to an
   attack, either against HOBA as specified here, or else an attack
   against some other protocol that re-used this to-be-signed structure.

Farrell, et al.           Expires July 12, 2015                [Page 20]
Internet-Draft        HTTP Origin-Bound Auth (HOBA)         January 2015

   Those fields ensure that the mapping from input fields to the HOBA-
   TBS string is an injective mapping.

9.  IANA Considerations

   IANA is requested to make registrations and create new registries as
   described below.

   For all new registries requested by this document, please place those
   beneath a new "HTTP Origin-Bound Authentication (HOBA) Parameters"
   category.

9.1.  HOBA Authentication Scheme

   Please register a new scheme in the HTTP Authentication Scheme
   Registry registry as follows:

   Authentication Scheme Name: HOBA

   Pointer to specification text: Section 3 of [[ this document ]]

   Notes (optional): The HOBA scheme can be used with either HTTP
   servers or proxies.  When used in response to a 407 Proxy
   Authentication Required indication, the appropriate proxy
   authentication header fields are used instead, as with any other HTTP
   authentication scheme.

9.2.  .well-known URI

   Please register a new .well-known URI in the Well-Known URIs registry
   as described below.

   URI suffix: hoba

   Change controller: IETF

   Specification document(s): Section 6 of [[ this document ]]

   Related information: N/A

9.3.  Algorithm Names

   Please create a new HOBA signature algorithms registry as follows,
   with the specification required rule for updates.  New HOBA signature
   algorithms SHOULD be in use with other IETF standards track protocols
   before being added to this registry.

Farrell, et al.           Expires July 12, 2015                [Page 21]
Internet-Draft        HTTP Origin-Bound Auth (HOBA)         January 2015

   Number       Meaning
   -----------  --------------------------------------------
   0            RSA-SHA256
   1            RSA-SHA1

   RSA is defined in Section 8.2 of [RFC3447], and SHA-1 and SHA-256 are
   defined in [SHS].

   For this registry the number column should contain a small positive
   integer.  Following the ABNF above, the maximum value for this is
   decimal 99.

9.4.  Key Identifier Types

   Please create a new HOBA Key Identifier Types registry as follows,
   with the specification required rule for updates.

   Number       Meaning
   -----------  --------------------------------------------
   0            a hashed public key [RFC6698]
   1            a URI [RFC3986]
   2            an unformatted string, at the user's/UA's whim

   For the number 0, hashed public keys are as done in DANE.  [RFC6698]

   For this registry the number column should contain a small positive
   integer.

9.5.  Device Identifier Types

   Please create a new HOBA Device Identifier Types registry as follows,
   with the specification required rule for updates.

   The designated expert for this registry is to carefully pay attention
   to the notes on this field in Section 8.1, in particular the "MUST
   NOT" stated therein.

   Number       Meaning
   -----------  --------------------------------------------
   0            an unformatted UTF8 string, at the user's/UA's whim

   For this registry the number column should contain a small positive
   integer.

9.6.  Hobareg HTTP Header Field

Farrell, et al.           Expires July 12, 2015                [Page 22]
Internet-Draft        HTTP Origin-Bound Auth (HOBA)         January 2015

   Please register a new identifier in the Permanent Message Header
   Field Names registry as described below.

   Header field name: Hobareg

   Applicable protocol: HTTP (RFC 7230)

   Status: Experimental

   Author/Change controller: IETF

   Specification document(s): Section 6.1.1 of [[ this document ]]

   Related information: N/A

10.  Implementation Status

   [[ Note to RFC editor - please delete this section before
   publication. ]]

   This section records the status of known implementations of the
   protocol defined by this specification at the time of posting of this
   Internet-Draft, and is based on a proposal described in [RFC6982].
   The description of implementations in this section is intended to
   assist the IETF in its decision processes in progressing drafts to
   RFCs.  Please note that the listing of any individual implementation
   here does not imply endorsement by the IETF.  Furthermore, no effort
   has been spent to verify the information presented here that was
   supplied by IETF contributors.  This is not intended as, and must not
   be construed to be, a catalog of available implementations or their
   features.  Readers are advised to note that other implementations may
   exist.

   According to [RFC6982] "this will allow reviewers and working groups
   to assign due consideration to documents that have the benefit of
   running code, by considering the running code as evidence of valuable
   experimentation and feedback that has made the implemented protocols
   more mature.  It is up to the individual working groups to use this
   information as they see fit".

   At the time of writing there are three known implementations.

      One done by Stephen Farrell of HOBA-http and a HOBA-JS variant
      implements the current version of HOBA and is available from
      https://hoba.ie/ which site also includes a demonstration of HOBA.

      There is another implementation by Michael Thomas of a HOBA-JS
      variant.

Farrell, et al.           Expires July 12, 2015                [Page 23]
Internet-Draft        HTTP Origin-Bound Auth (HOBA)         January 2015

      The most recent (Dec 2014) implementation is by Portugal Telecom
      and is available from https://github.com/razevedo/hoba-
      authentication

11.  Acknowledgements

   Thanks to the following for good comments received during the
   preparation of this specification: Richard Barnes, David Black,
   Alissa Cooper, Donald Eastlake, Amos Jeffries, Benjamin Kaduk, Watson
   Ladd, Barry Leiba, Matt Lepinski, Ilari Liusvaara, James Manger,
   Alexey Melnikov, Kathleen Moriarty, Yoav Nir, Mark Nottingham, Julian
   Reschke, Pete Resnick, Michael Richardson, Yaron Sheffer, and Michael
   Sweet.  All errors and stupidities are of course the editors' fault.

12.  References

12.1.  Normative References

   [RFC0020]  Cerf, V., "ASCII format for network interchange", RFC 20,
              October 1969.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
              Standards (PKCS) #1: RSA Cryptography Specifications
              Version 2.1", RFC 3447, February 2003.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66, RFC
              3986, January 2005.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, October 2006.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
              Uniform Resource Identifiers (URIs)", RFC 5785, April
              2010.

   [RFC6454]  Barth, A., "The Web Origin Concept", RFC 6454, December
              2011.

Farrell, et al.           Expires July 12, 2015                [Page 24]
Internet-Draft        HTTP Origin-Bound Auth (HOBA)         January 2015

   [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
              of Named Entities (DANE) Transport Layer Security (TLS)
              Protocol: TLSA", RFC 6698, August 2012.

   [RFC6750]  Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
              Framework: Bearer Token Usage", RFC 6750, October 2012.

   [RFC7231]  Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
              (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.

   [RFC7235]  Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
              (HTTP/1.1): Authentication", RFC 7235, June 2014.

   [SHS]      NIST, , "Secure Hash Standard (SHS), FIPS PUB 180-4", NIST
              Special Publications , March 2012.

12.2.  Informative References

   [MI93]     Mitchell, and Thomas, "Standardising Authentication
              Protocols Based on Public-Key Techniques.", Journal of
              Computer Security 2 (1993): 23-36. , 1993.

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

   [RFC6265]  Barth, A., "HTTP State Management Mechanism", RFC 6265,
              April 2011.

   [RFC6376]  Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys
              Identified Mail (DKIM) Signatures", STD 76, RFC 6376,
              September 2011.

   [RFC6982]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", RFC 6982, July
              2013.

   [bland]    Sophos, , "Security Threat Report 2013", January 2013,
              <http://www.sophos.com/en-us/medialibrary/pdfs/other/
              sophossecuritythreatreport2013.pdf>.

   [bonneau]  Bonneau, , "The science of guessing: analyzing an
              anonymized corpus of 70 million passwords.", IEEE
              Symposium on Security and Privacy , 2012.

Appendix A.  Problems with Passwords

   By far the most common mechanism for web authentication is passwords
   that can be remembered by the user, called "human-memorable

Farrell, et al.           Expires July 12, 2015                [Page 25]
Internet-Draft        HTTP Origin-Bound Auth (HOBA)         January 2015

   passwords".  There is plenty of good research on how users typically
   use human-memorable passwords (e.g. see [bonneau]), but some of the
   highlights are that users typically try hard to reuse passwords on as
   many web sites as possible, and that web sites often use either email
   addresses or users' names as the identifier that goes with these
   passwords.

   If an attacker gets access to the database of memorizable passwords,
   that attacker can impersonate any of the users.  Even if the breach
   is discovered, the attacker can still impersonate users until every
   password is changed.  Even if all the passwords are changed or at
   least made unusable, the attacker now possesses a list of likely
   username/password pairs that might exist on other sites.

   Using memorizable passwords on unencrypted channels also poses risks
   to the users.  If a web site uses either the HTTP Basic
   authentication method, or an HTML form that does no cryptographic
   protection of the password in transit, a passive attacker can see the
   password and immediately impersonate the user.  If a hash-based
   authentication scheme such as HTTP Digest authentication is used, a
   passive attacker still has a high chance of being able to determine
   the password using a dictionary of known passwords.

   Note that passwords that are not human-memorable are still subject to
   database attack, though are of course unlikely to be re-used across
   many systems.  Similarly, database attacks of some form or other will
   work against any password based authentication scheme, regardless of
   the crytographic protocol used.  So for example, zero-knowledge or
   PAKE schemes, though making use of elegant cryptographic protocols,
   remain as vulnerable to what is clearly the most common exploit seen
   when it comes to passwords.  HOBA is however not vulnerable to
   database theft.

Appendix B.  Example

   The following values show an example of HOBA-http authentication to
   the origin https://example.com:443.  Carriage-returns have been added
   and need to be removed to validate the example.

   Public Key:

   -----BEGIN PUBLIC KEY-----
   MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAviE8fMrGIPZN9up94M28
   6o38B99fsz5cUqYHXXJlnHIi6gGKjqLgn3P7n4snUSQswLExrkhSr0TPhRDuPH_t
   fXLKLBbh17ofB7t7shnPKxmyZ69hCLbe7pB1HvaBzTxPC2KOqskDiDBOQ6-JLHQ8
   egXB14W-641RQt0CsC5nXzo92kPCdV4NZ45MW0ws3twCIUDCH0nibIG9SorrBbCl
   DPHQZS5Dk5pgS7P5hrAr634Zn4bzXhUnm7cON2x4rv83oqB3lRqjF4T9exEMyZBS
   L26m5KbK860uSOKywI0xp4ymnHMc6Led5qfEMnJC9PEI90tIMcgdHrmdHC_vpldG

Farrell, et al.           Expires July 12, 2015                [Page 26]
5.5.  Site Belonging to Multiple VPNs . . . . . . . . . . . . .  38
       5.5.1.  Site VPN Flavors  . . . . . . . . . . . . . . . . . .  38
         5.5.1.1.  Single VPN Attachment: site-vpn-flavor-single . .  39
         5.5.1.2.  Multi-VPN Attachment: site-vpn-flavor-multi . . .  39
         5.5.1.3.  NNI: site-vpn-flavor-nni  . . . . . . . . . . . .  40
         5.5.1.4.  E2E: site-vpn-flavor-e2e  . . . . . . . . . . . .  41
       5.5.2.  Attaching a Site to a VPN . . . . . . . . . . . . . .  41
         5.5.2.1.  Referencing a VPN . . . . . . . . . . . . . . . .  41
         5.5.2.2.  VPN Policy  . . . . . . . . . . . . . . . . . . .  43
     5.6.  Deciding Where to Connect the Site  . . . . . . . . . . .  48
       5.6.1.  Constraint: Device  . . . . . . . . . . . . . . . . .  49
       5.6.2.  Constraint/Parameter: Site Location . . . . . . . . .  50
       5.6.3.  Constraint/Parameter: Access Type . . . . . . . . . .  51
       5.6.4.  Constraint: Access Diversity  . . . . . . . . . . . .  52
     5.7.  Route Distinguisher and Network Instance Allocation . . .  53
     5.8.  Site-Network-Access Availability  . . . . . . . . . . . .  54
     5.9.  SVC MTU . . . . . . . . . . . . . . . . . . . . . . . . .  56
     5.10. Service . . . . . . . . . . . . . . . . . . . . . . . . .  56
       5.10.1.  Bandwidth  . . . . . . . . . . . . . . . . . . . . .  56
       5.10.2.  QoS  . . . . . . . . . . . . . . . . . . . . . . . .  57
         5.10.2.1.  QoS Classification . . . . . . . . . . . . . . .  57
         5.10.2.2.  QoS Profile  . . . . . . . . . . . . . . . . . .  58
       5.10.3.  Support for BUM  . . . . . . . . . . . . . . . . . .  59
     5.11. Site Management . . . . . . . . . . . . . . . . . . . . .  60
     5.12. MAC Loop Protection . . . . . . . . . . . . . . . . . . .  61
     5.13. MAC Address Limit . . . . . . . . . . . . . . . . . . . .  61
     5.14. Enhanced VPN Features . . . . . . . . . . . . . . . . . .  62
       5.14.1.  Carriers' Carriers . . . . . . . . . . . . . . . . .  62
     5.15. External ID References  . . . . . . . . . . . . . . . . .  63
     5.16. Defining NNIs and Inter-AS Support  . . . . . . . . . . .  64
       5.16.1.  Defining an NNI with the Option A Flavor . . . . . .  66
       5.16.2.  Defining an NNI with the Option B Flavor . . . . . .  70
       5.16.3.  Defining an NNI with the Option C Flavor . . . . . .  73
     5.17. Applicability of L2SM in Inter-provider and Inter-domain
           Orchestration . . . . . . . . . . . . . . . . . . . . . .  74
   6.  Interaction with Other YANG Modules . . . . . . . . . . . . .  76
   7.  Service Model Usage Example . . . . . . . . . . . . . . . . .  77
   8.  YANG Module . . . . . . . . . . . . . . . . . . . . . . . . .  82
   9.  Security Considerations . . . . . . . . . . . . . . . . . . . 152
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 153
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . . 153
     11.1.  Normative References . . . . . . . . . . . . . . . . . . 153
     11.2.  Informative References . . . . . . . . . . . . . . . . . 155
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . . 157
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 158

Wen, et al.                  Standards Track                    [Page 3]
RFC 8466               L2VPN Service Model (L2SM)           October 2018

1.  Introduction

   This document defines a YANG data model for the Layer 2 VPN (L2VPN)
   service.  This model defines service configuration elements that can
   be used in communication protocols between customers and network
   operators.  Those elements can also be used as input to automated
   control and configuration applications and can generate specific
   configuration models to configure the different network elements to
   deliver the service.  How this configuration of network elements is
   done is out of scope for this document.

   Further discussion of the way that services are modeled in YANG and
   the relationship between "customer service models" like the one
   described in this document and configuration models can be found in
   [RFC8309] and [RFC8199].  Sections 4 and 6 also provide more
   information on how this service model could be used and how it fits
   into the overall modeling architecture.

   The YANG data model defined in this document includes support for
   point-to-point Virtual Private Wire Services (VPWSs) and multipoint
   Virtual Private LAN Services (VPLSs) that use Pseudowires signaled
   using the Label Distribution Protocol (LDP) and the Border Gateway
   Protocol (BGP) as described in [RFC4761] and [RFC6624].  It also
   conforms to the Network Management Datastore Architecture (NMDA)
   [RFC8342].

1.1.  Terminology

   The following terms are defined in [RFC6241] and are not redefined
   here:

   o  client

   o  configuration data

   o  server

   o  state data

   The following terms are defined in [RFC7950] and are not redefined
   here:

   o  augment

   o  data model

   o  data node

Wen, et al.                  Standards Track                    [Page 4]
RFC 8466               L2VPN Service Model (L2SM)           October 2018

   The terminology for describing YANG data models is found in
   [RFC7950].

1.1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

1.2.  Tree Diagrams

   Tree diagrams used in this document follow the notation defined in
   [RFC8340].

2.  Definitions

   This document uses the following terms:

   Service Provider (SP):  The organization (usually a commercial
      undertaking) responsible for operating the network that offers VPN
      services to clients and customers.

   Customer Edge (CE) Device:  Equipment that is dedicated to a
      particular customer and is directly connected to one or more PE
      devices via Attachment Circuits (ACs).  A CE is usually located at
      the customer premises and is usually dedicated to a single VPN,
      although it may support multiple VPNs if each one has separate
      ACs.  The CE devices can be routers, bridges, switches, or hosts.

   Provider Edge (PE) Device:  Equipment managed by the SP that can
      support multiple VPNs for different customers and is directly
      connected to one or more CE devices via ACs.  A PE is usually
      located at an SP Point of Presence (POP) and is managed by the SP.

   Virtual Private LAN Service (VPLS):  A VPLS is a provider service
      that emulates the full functionality of a traditional LAN.  A VPLS
      makes it possible to interconnect several LAN segments over a
      packet switched network (PSN) and makes the remote LAN segments
      behave as one single LAN.

   Virtual Private Wire Service (VPWS):  A VPWS is a point-to-point
      circuit (i.e., link) connecting two CE devices.  The link is
      established as a logical Layer 2 circuit through a PSN.  The CE in
      the customer network is connected to a PE in the provider network
      via an AC: the AC is either a physical or logical circuit.  A VPWS

Wen, et al.                  Standards Track                    [Page 5]
RFC 8466               L2VPN Service Model (L2SM)           October 2018

      differs from a VPLS in that the VPLS is point-to-multipoint while
      the VPWS is point-to-point.  In some implementations, a set of
      VPWSs is used to create a multi-site L2VPN network.

   Pseudowire (PW):  A Pseudowire is an emulation of a native service
      over a PSN.  The native service may be ATM, Frame Relay, Ethernet,
      low-rate Time-Division Multiplexing (TDM), or Synchronous Optical
      Network / Synchronous Digital Hierarchy (SONET/SDH), while the PSN
      may be MPLS, IP (either IPv4 or IPv6), or Layer 2 Tunneling
      Protocol version 3 (L2TPv3).

   MAC-VRF:  A Virtual Routing and Forwarding table for Media Access
      Control (MAC) addresses on a PE.  It is sometimes also referred to
      as a Virtual Switching Instance (VSI).

   UNI:  User-to-Network Interface.  The physical demarcation point
      between the customer's area of responsibility and the provider's
      area of responsibility.

   NNI:  Network-to-Network Interface.  A reference point representing
      the boundary between two networks that are operated as separate
      administrative domains.  The two networks may belong to the same
      provider or to two different providers.

   This document uses the following abbreviations:

   BSS:  Business Support System

   BUM:  Broadcast, Unknown Unicast, or Multicast

   CoS:  Class of Service

   LAG:  Link Aggregation Group

   LLDP:  Link Layer Discovery Protocol

   OAM:  Operations, Administration, and Maintenance

   OSS:  Operations Support System

   PDU:  Protocol Data Unit

   QoS:  Quality of Service

Wen, et al.                  Standards Track                    [Page 6]
RFC 8466               L2VPN Service Model (L2SM)           October 2018

3.  The Layer 2 VPN Service Model

   A Layer 2 VPN (L2VPN) service is a collection of sites that are
   authorized to exchange traffic between each other over a shared
   infrastructure of a common technology.  The L2VPN Service Model
   (L2SM) described in this document provides a common understanding of
   how the corresponding L2VPN service is to be deployed over the shared
   infrastructure.

   This document presents the L2SM using the YANG data modeling language
   [RFC7950] as a formal language that is both human readable and
   parsable by software for use with protocols such as the Network
   Configuration Protocol (NETCONF) [RFC6241] and RESTCONF [RFC8040].

   This service model is limited to VPWS-based VPNs and VPLS-based VPNs
   as described in [RFC4761] and [RFC6624] and to Ethernet VPNs (EVPNs)
   as described in [RFC7432].

3.1.  Layer 2 VPN Service Types

   From a technology perspective, a set of basic L2VPN service types
   include:

   o  Point-to-point VPWSs that use LDP-signaled Pseudowires or
      L2TP-signaled Pseudowires [RFC6074].

   o  Multipoint VPLSs that use LDP-signaled Pseudowires or
      L2TP-signaled Pseudowires [RFC6074].

   o  Multipoint VPLSs that use a BGP control plane as described in
      [RFC4761] and [RFC6624].

   o  IP-only LAN Services (IPLSs) that are a functional subset of VPLS
      services [RFC7436].

   o  BGP MPLS-based EVPN services as described in [RFC7432] and
      [RFC7209].

   o  EVPN VPWSs as specified in [RFC8214].

3.2.  Layer 2 VPN Physical Network Topology

   Figure 1 below depicts a typical SP's physical network topology.
   Most SPs have deployed an IP, MPLS, or Segment Routing (SR)
   multi-service core infrastructure.  Ingress Layer 2 service frames
   will be mapped to either an Ethernet Pseudowire (e.g., Pseudowire
   Emulation Edge to Edge (PWE3)) or a Virtual Extensible Local Area

Wen, et al.                  Standards Track                    [Page 7]
RFC 8466               L2VPN Service Model (L2SM)           October 2018

   Network (VXLAN) PE-to-PE tunnel.  The details of these tunneling
   mechanisms are left to the provider's discretion and are not part of
   the L2SM.

   An L2VPN provides end-to-end Layer 2 connectivity over this
   multi-service core infrastructure between two or more customer
   locations or a collection of sites.  ACs are placed between CE
   devices and PE devices that backhaul Layer 2 service frames from the
   customer over the access network to the provider network or remote
   site.  The demarcation point (i.e., UNI) between the customer and the
   SP can be placed between either (1) customer nodes and the CE device
   or (2) the CE device and the PE device.  The actual bearer connection
   between the CE and the PE will be described in the L2SM.

   The SP may also choose a Internet-Draft        HTTP Origin-Bound Auth (HOBA)         January 2015

   DQIDAQAB
   -----END PUBLIC KEY-----

   Origin: https://example.com:443

   Key Identifier: vesscamS2Kze4FFOg3e2UyCJPhuQ6_3_gzN-k_L6t3w

   Challenge: pUE77w0LylHypHKhBqAiQHuGC751GiOVv4/7pSlo9jc=

   Signature algorithm: RSA-SHA256 ("0")

   Nonce: Pm3yUW-sW5Q

   Signature:

   VD-0LGVBVEVjfq4xEd35FjnOrIqzJ2OQMx5w8E52dgVvxFD6R0ryEsHcD31ykh0i
   4YIzIHXirx7bE4x9yP-9fMBCEwnHJsYwYQhfRpmScwAz-Ih1Hn4yORTb-U66miUz
   q04ZgTHm4jAj45afU20wYpGXY2r3W-FRKc6J6Glv_zI_ROghERalxgXG-QVGZrKP
   tG0V593Yf9IPnFSpLyW6fnxscCMWUA9T-4NjMdypI-Ze4HsC9J06tRTOunQdofr9
   6ZJ2i9LE6uKSUDLCD2oeEeSEvUR--4OGtrgjzYysHZkdVSxAi7OoQBK34EUWg9kI
   S13qQA43m4IMExkbApqrSg

   Authorization Header:

   Authorization: HOBA result="vesscamS2Kze4FFOg3e2UyCJPhuQ6_3_gzN-
   k_L6t3w.pUE77w0LylHypHKhBqAiQHuGC751GiOVv4/7pSlo9jc=.Pm3yUW-sW5Q
   .VD-0LGVBVEVjfq4xEd35FjnOrIqzJ2OQMx5w8E52dgVvxFD6R0ryEsHcD31ykh0
   i4YIzIHXirx7bE4x9yP-9fMBCEwnHJsYwYQhfRpmScwAz-Ih1Hn4yORTb-U66miU
   zq04ZgTHm4jAj45afU20wYpGXY2r3W-FRKc6J6Glv_zI_ROghERalxgXG-QVGZrK
   PtG0V593Yf9IPnFSpLyW6fnxscCMWUA9T-4NjMdypI-Ze4HsC9J06tRTOunQdofr
   96ZJ2i9LE6uKSUDLCD2oeEeSEvUR--4OGtrgjzYysHZkdVSxAi7OoQBK34EUWg9k
   IS13qQA43m4IMExkbApqrSg"

Authors' Addresses

   Stephen Farrell
   Trinity College Dublin
   Dublin  2
   Ireland

   Phone: +353-1-896-2354
   Email: stephen.farrell@cs.tcd.ie

   Paul Hoffman
   VPN Consortium

   Email: paul.hoffman@vpnc.org

Farrell, et al.           Expires July 12, 2015                [Page 27]
Internet-Draft        HTTP Origin-Bound Auth (HOBA)         January 2015

   Michael Thomas
   Phresheez

   Email: mike@phresheez.com

Farrell, et al.           Expires July 12, 2015                [Page 28]