One document matched: draft-ietf-l2tpext-sbfd-discriminator-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-l2tpext-sbfd-discriminator-00.txt"
     ipr="pre5378Trust200902">
  <front>
    <title abbrev="l2tpext-sbfd-discriminator">Advertising S-BFD Discriminators in L2TPv3</title>

    <author fullname="Vengada Prasad Govindan" initials="V."
            surname="Govindan">
      <organization>Cisco Systems</organization>
      <address>
        <email>venggovi@cisco.com</email>
      </address>
    </author>

    <author fullname="Carlos Pignataro" initials="C."
            surname="Pignataro">
      <organization>Cisco Systems</organization>
      <address>
        <email>cpignata@cisco.com</email>
      </address>
    </author>
 
    <date year="2015"/>

    <area>Routing Area</area>

    <workgroup>Networking Working Group</workgroup>

    <keyword>Sample</keyword>

    <abstract>
      <t>This document defines a new AVP for advertising one or more S-BFD
      Discriminators using the L2TPv3 Control Protocol AVP.</t>
    </abstract>

    <note title="Requirements Language">
      <t>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].</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t><xref target="I-D.ietf-bfd-seamless-base"/> defines a simplified mechanism to use Bidirectional Forwarding Detection (BFD)[RFC5880]. This mechanism depends on network nodes knowing the BFD discriminators which each node in the network has reserved for this purpose. Use of the Layer2 Tunneling protocol Version 3 (L2TPv3) <xref target="RFC3931"/> is one possible means of advertising these discriminators. S-BFD requires the usage of unique discriminators within an administrative domain.</t>
      <t>This document specifies the encoding to be used when S-BFD discriminators are advertised using L2TPv3.</t>
    </section>

    <section title="S-BFD Target Discriminator ID AVP">
    <t>   This AVP is exchanged during session negotiation (ICRQ, ICRP, OCRQ, OCRP). </t>
    <section title=" Encoding Format">
      <t> The S-BFD Target Discriminator ID AVP, Attribute Type TBD, is an identifier used to advertise the S-BFD target discriminators supported by an LCCE for S-BFD Reflector operation. This AVP indicates that the advertiser implements a S-BFD reflector supporting the specified target discriminators 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 or BFD.</t>
      <t>The Attribute Value field for this AVP has the following format:</t>

            <t>S-BFD Discriminator Advertisement (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN):</t>



      <t><figure>
          <artwork><![CDATA[                                                  No. of octets
              +-----------------------------+
              | Discriminator Value(s)      |     4/Discriminator
              :                             :
              +-----------------------------+

]]></artwork>
        </figure></t>

      <t>An LCCE MAY include the S-BFD Discriminator Advertisement AVP in a L2TP Control Protocol message (ICRQ, ICRP, OCRQ, OCRP) <xref target="RFC3931"/>. Multiple S-BFD Discriminators AVPs MAY be advertised by a LCCE. If the other LCCE does not wish to monitor connectivity using S-BFD, it MAY safely discard this AVP without affecting the rest of session negotiation. While current use-cases <xref target="I-D.ietf-bfd-seamless-use-case"/> of S-BFD require advertisement of only one discriminator, the AVP encoding allows specification an arbitrary number of discrminators for extensibility. When multiple S-BFD discriminators are advertised, the mechanism to choose a subset of specific discriminator(s) is out of scope for this document.</t>
      <t>The M bit of the L2TP Control Protocol Message (ICRQ, ICRP, OCRQ, OCRP) <xref target="RFC3931"/> MUST NOT be set inside the S-BFD Target Discriminator ID AVP advertisement.</t>

    </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This number space is managed by IANA as per <xref target="RFC3438"/>.</t>
      <t>A summary of the new AVPs requested for Attribute Type 0 follows:</t>
      <t>      Control Message Attribute Value Pairs</t>


      <figure>
        <artwork><![CDATA[ 
      Attribute
      Type        Description
      ---------   ------------------
      TBD         S-BFD Discriminators
   
]]></artwork>
      </figure>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>Security concerns for L2TP are addressed in <xref target="RFC3931"/>.
      Introduction of the S-BFD Discriminator Advertisement AVP introduces no new security risks for L2TP.</t>

      <t>Advertisement of the S-BFD discriminators does make it possible for
      attackers to initiate S-BFD sessions using the advertised information.
      The vulnerabilities this poses and how to mitigate them are discussed in
      the Security Considerations section of <xref target="I-D.ietf-bfd-seamless-base"/>.</t>
    </section>

    <section title="Acknowledgements">
    <t>Authors would like to thank Nobo Akiya, Stewart Bryant and Pawel Sowinski for providing core inputs for the document and for performing thorough reviews and providing number of comments. Authors would like to thank Nagendra Kumar for his reviews.</t>
    </section>

    <section title="Contributing Authors">

	<t>Mallik Mudigonda
    <vspace blankLines="0" />
	Cisco Systems
    <vspace blankLines="0" />
    Email: mmudigon@cisco.com</t>

    </section>


  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
      <?rfc include="reference.RFC.3438"?>
      <?rfc include="reference.RFC.3931"?>
      <?rfc include='reference.RFC.5880'?>
       <?rfc include="reference.I-D.ietf-bfd-seamless-base"?>
    </references>
    <references title="Informative References">
       <?rfc include="reference.I-D.ietf-bfd-seamless-use-case"?>
    </references>
  </back>
</rfc>