RFC 7886

Advertising Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators in the Layer Two Tunneling Protocol Version 3 (L2TPv3)

📅 published July 2016, from ietf

RFC 7886: Advertising S-BFD Discriminators in L2TPv3 💖

Advertising Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators in the Layer Two Tunneling Protocol Version 3 (L2TPv3)

  • Who wrote it: V. Govindan and C. Pignataro, both from Cisco 🎀
  • Category: Standards Track 🧚
  • Date: July 2016 📅
  • Series: Internet Engineering Task Force (IETF), ISSN 2070-1721 🌸
  • Obsoletes or updates: the title block doesn't list anything this RFC obsoletes or updates 🦋

Abstract ✨

okay so this doc defines a brand new Attribute-Value Pair (AVP) 💅 that lets L2TP Control Connection Endpoints (LCCEs) advertise one or more Seamless Bidirectional Forwarding Detection (S-BFD) Discriminator values using the Layer Two Tunneling Protocol version 3 (L2TPv3). it's giving "tell everyone who you are" energy 🫶

Status of This Memo 📜

this is an Internet Standards Track document 🔥

it's a product of the Internet Engineering Task Force (IETF). it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 👑 more on Internet Standards is in Section 2 of RFC 7841.

info about the current status, any errata, and how to give feedback is at http://www.rfc-editor.org/info/rfc7886 🌈

Copyright (c) 2016 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 (http://trustee.ietf.org/license-info) as they stand on the date of publication. please read these carefully, because they spell out your rights and restrictions for this document 🙈 Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License.

Table of Contents 🗺️

   1. Introduction ....................................................2
      1.1. Terminology ................................................2
   2. S-BFD Target Discriminator ID AVP ...............................2
      2.1. Encoding Format ............................................3
   3. IANA Considerations .............................................4
   4. Security Considerations .........................................4
   5. References ......................................................5
      5.1. Normative References .......................................5
      5.2. Informative References .....................................5
   Acknowledgements ...................................................6
   Contributors .......................................................6
   Authors' Addresses .................................................6

1. Introduction 🦋

okay so [RFC7880] defines a simplified mechanism for using Bidirectional Forwarding Detection (BFD) [RFC5880], and it's called Seamless Bidirectional Forwarding Detection (S-BFD) 💖 the S-BFD mechanism depends on network nodes knowing the BFD Discriminators that each node in the network has reserved for this purpose. S-BFD needs unique discriminators within an administrative domain, no exceptions 🙅‍♀️ and the Layer Two Tunneling Protocol version 3 (L2TPv3) [RFC3931] is one possible way to advertise these discriminators.

this document is the spec for the encoding you use when S-BFD Discriminators get advertised over L2TPv3 🧚

1.1. Terminology 📖

you're expected to already know the terminology and protocol constructs from S-BFD (see Section 2 of [RFC7880]) and L2TPv3 (see Section 1.3 of [RFC3931]). no cap, you'll need them 💅

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]. ✨

2. S-BFD Target Discriminator ID AVP 🎀

the S-BFD Target Discriminator Identifier (ID) Attribute Value Pair (AVP) gets exchanged using the ICRQ (Incoming-Call-Request), ICRP (Incoming-Call-Reply), OCRQ (Outgoing-Call-Request), and OCRP (Outgoing-Call-Reply) control messages during session negotiation. it's the main character of session setup 👑

2.1. Encoding Format 🍓

the S-BFD Target Discriminator ID AVP, Attribute Type 102, is an identifier used to advertise the S-BFD target discriminator(s) that an L2TP Control Connection Endpoint (LCCE) supports for the S-BFD reflector operation. this AVP says the advertiser implements an S-BFD reflector that supports the specified target discriminator(s) and is ready for S-BFD reflector operation 🔥 The receiving LCCE MAY use this AVP if it wants to monitor connectivity to the advertising LCCE using S-BFD. 🦋

the Attribute Value field for this AVP has the following format 🌸

S-BFD Target Discriminator ID (ICRQ, ICRP, OCRQ, OCRP):

                                       No. of octets
   +-----------------------------+
   | Discriminator Value(s)      |     4/Discriminator
   :                             :
   +-----------------------------+

An LCCE MAY include the S-BFD Target Discriminator ID AVP advertisement in an L2TP control message (ICRQ, ICRP, OCRQ, OCRP) [RFC3931]. If the other LCCE doesn't want to monitor connectivity using S-BFD, it MAY safely discard this AVP without affecting the rest of session negotiation. 🫶 while [RFC7880] only deals with advertising one discriminator unless the mapping of discriminators to entities is specified, the AVP encoding lets you specify an arbitrary number of S-BFD Discriminators (at least one) for extensibility. so future-proof 💖

When an LCCE uses the S-BFD Target Discriminator ID AVP advertisement, multiple S-BFD Discriminators MAY be included, and at least one S-BFD Discriminator MUST be included. ‼️ When one S-BFD Discriminator is advertised, it's associated with the L2TPv3 session. When multiple S-BFD Discriminators are advertised, how a given discriminator maps to a specific use case is out of scope for this document. 🙈

the S-BFD Target Discriminator ID AVP lets you advertise at least one S-BFD Discriminator value 🧚

   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                         Discriminator 1                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                    Discriminator 2 (Optional)                 |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                               ...                             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                    Discriminator n (Optional)                 |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The M bit of the L2TP control message (ICRQ, ICRP, OCRQ, OCRP) [RFC3931] MUST NOT be set inside the S-BFD Target Discriminator ID AVP. 🚫 this one's a hard rule, bestie 💀

3. IANA Considerations 🗂️

IANA maintains the "Control Message Attribute Value Pairs" sub-registry as per [RFC3438]. IANA has assigned the following value to the S-BFD Target Discriminator ID 🌈

Control Message Attribute Value Pairs

      Attribute
      Type          Description
      -----------   ------------------
      102           S-BFD Target Discriminator ID

4. Security Considerations 🔐

this part is serious, so listen up 🙏 security concerns for L2TP are covered in [RFC3931]. Introducing the S-BFD Target Discriminator ID AVP advertisement adds no new security risks for L2TP. 💖

BUT 😭 advertising the S-BFD Discriminators makes it possible for attackers to start S-BFD sessions using the advertised information. The vulnerabilities this creates, and how to mitigate them, are discussed in the Security Considerations section of [RFC7880]. ⚠️ go read it, it's giving "lock your doors" energy

5. References 📚

5.1. Normative References 🧷

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

[RFC3438]  Townsley, W., "Layer Two Tunneling Protocol (L2TP)
           Internet Assigned Numbers Authority (IANA) Considerations
           Update", BCP 68, RFC 3438, DOI 10.17487/RFC3438,
           December 2002, <http://www.rfc-editor.org/info/rfc3438>.

[RFC3931]  Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed.,
           "Layer Two Tunneling Protocol - Version 3 (L2TPv3)",
           RFC 3931, DOI 10.17487/RFC3931, March 2005,
           <http://www.rfc-editor.org/info/rfc3931>.

[RFC7880]  Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S.
           Pallagatti, "Seamless Bidirectional Forwarding Detection
           (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016,
           <http://www.rfc-editor.org/info/rfc7880>.

5.2. Informative References 🧠

[RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
           (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
           <http://www.rfc-editor.org/info/rfc5880>.

Acknowledgements 💜

the authors want to thank Nobo Akiya, Stewart Bryant, and Pawel Sowinski for providing core inputs for the document, doing thorough reviews, and leaving a bunch of comments 🫶 they also thank Nagendra Kumar for his reviews. the real MVPs 👑

Contributors 🎀

Mallik Mudigonda Cisco Systems, Inc. Email: mmudigon@cisco.com

Authors' Addresses 🦋

Vengada Prasad Govindan Cisco Systems, Inc. Email: venggovi@cisco.com

Carlos Pignataro Cisco Systems, Inc. Email: cpignata@cisco.com

📦 where this page comes from