[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09                                 
SFC WG                                                         G. Mirsky
Internet-Draft                                                 ZTE Corp.
Intended status: Standards Track                                   T. Ao
Expires: July 23, 2021                            Individual contributor
                                                                 Z. Chen
                                                           China Telecom
                                                               G. Mishra
                                                            Verizon Inc.
                                                        January 19, 2021


      Controlled Return Path for Service Function Chain (SFC) OAM
               draft-ao-sfc-oam-return-path-specified-08

Abstract

   This document defines an extension to the Service Function Chain
   (SFC) Operation, Administration and Maintenance (OAM) that enables
   control of the Echo Reply return path directing it over a Reverse
   Service Function Path.  Enforcing the specific return path can be
   used to verify the bidirectional connectivity of SFC and increase the
   robustness of SFC OAM.

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 July 23, 2021.

Copyright Notice

   Copyright (c) 2021 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



Mirsky, et al.            Expires July 23, 2021                 [Page 1]


Internet-Draft     Controlled Return Path for SFC OAM       January 2021


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions used in this document . . . . . . . . . . . . . .   3
     2.1.  Acronyms  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   3.  Extension . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  SFC Reply Path TLV  . . . . . . . . . . . . . . . . . . . . .   4
   5.  Theory of Operation . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Bi-directional SFC Case . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  SFC Return Path Type  . . . . . . . . . . . . . . . . . .   6
     7.2.  New Return Codes  . . . . . . . . . . . . . . . . . . . .   7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   While Service Function Chain (SFC) Echo Request, defined in
   [I-D.ietf-sfc-multi-layer-oam], always traverses the SFC it directed
   to, the corresponding Echo Reply is sent over IP network
   [I-D.ietf-sfc-multi-layer-oam].  There are scenarios when it is
   beneficial to direct the responder to use a path other than the IP
   network.  This document extends Service Function Chain (SFC)
   Operation, Administration and Maintenance (OAM) by enabling control
   of the Echo Reply return path to be directed over a Reply Service
   Function Path (SFP).  Such an extension is based on the analysis of
   SFC OAM, active OAM protocols, in particular, provided in [RFC8924].
   This document defines a new Type-Length-Value (TLV), Reply Service
   Function Path TLV, for Reply via Specified Path mode of SFC Echo
   Reply (Section 4).

   The Reply Service Function Path TLV can provide an efficient
   mechanism to test SFCs, such as bidirectional and hybrid SFC, as
   defined in Section 2.2 [RFC7665].  For example, it allows an operator
   to test both directions of the bidirectional or hybrid SFP with a
   single SFC Echo Request/Echo Reply operation.




Mirsky, et al.            Expires July 23, 2021                 [Page 2]


Internet-Draft     Controlled Return Path for SFC OAM       January 2021


2.  Conventions used in this document

2.1.  Acronyms

   SF - Service Function

   SFF - Service Function Forwarder

   SFC - Service Function Chain, an ordered set of some abstract SFs.

   SFP - Service Function Path

   SPI - Service Path Index

   OAM - Operation, Administration, and Maintenance

   MAC - Message Authentication Code

2.2.  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.

3.  Extension

   The following reply modes had been defined in
   [I-D.ietf-sfc-multi-layer-oam]:

   o  Do Not Reply

   o  Reply via an IPv4/IPv6 UDP Packet

   o  Reply via Application Level Control Channel

   o  Reply via Specified Path

   The Reply via Specified Path mode is intended to enforce the use of
   the particular return path specified in the included TLV.  This mode
   may help verify bidirectional continuity or increase SFC monitoring's
   robustness by selecting a more stable path.  In SFC's case, the
   sender of Echo Request instructs the destination SFF to send Echo
   Reply message along the SFP specified in the SFC Reply Path TLV, as
   described in Section 4.





Mirsky, et al.            Expires July 23, 2021                 [Page 3]


Internet-Draft     Controlled Return Path for SFC OAM       January 2021


4.  SFC Reply Path TLV

   The SFC Reply Path TLV carries the information that sufficiently
   identifies the return SFP that the SFC Echo Reply message is expected
   to follow.  The format of SFC Reply Path TLV 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |SFC Reply Path |    Reserved   |          Length               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Reply Service Function Path                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 1: SFC Reply TLV Format

   where:

   o  Reply Path TLV Type: is a one-octet-long, indicates the TLV that
      contains information about the SFC Reply path.

   o  Reserved - one-octet-long field.

   o  Length: is two octets long, MUST be equal to 4

   o  Reply Service Function Path is used to describe the return path
      that an SFC Echo Reply is requested to follow.

   The format of the Reply Service Function Path field displayed in
   Figure 2

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Reply Service Function Path Identifier     | Service Index |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 2: Reply Service Function Path Field Format

   where:

   o  Reply Service Function Path Identifier: SFP identifier for the
      path that the SFC Echo Reply message is requested to be sent over.

   o  Service Index: the value for the Service Index field in the NSH of
      the SFC Echo Reply message.





Mirsky, et al.            Expires July 23, 2021                 [Page 4]


Internet-Draft     Controlled Return Path for SFC OAM       January 2021


5.  Theory of Operation

   [RFC7110] defined mechanism to control return path for MPLS LSP Echo
   Reply.  In SFC's case, the return path is an SFP along which the SFC
   Echo Reply message MUST be transmitted.  Hence, the SFC Reply Path
   TLV included in the SFC Echo Request message MUST sufficiently
   identify the SFP that the sender of the Echo Request message expects
   the receiver to use for the corresponding SFC Echo Reply.

   When sending an Echo Request, the sender MUST set the value of Reply
   Mode field to "Reply via Specified Path", defined in
   [I-D.ietf-sfc-multi-layer-oam], and if the specified path is SFC
   path, the Request MUST include SFC Reply Path TLV.  The SFC Reply
   Path TLV includes the identifier of the reverse SFP and an
   appropriate Service Index.

   The Message Authentication Code (MAC) Context Header that is defined
   in [I-D.ietf-sfc-nsh-integrity] MAY be used to protect the SFC Echo
   Request's integrity when using the SFC Return Path TLV.  If the NSH
   of the received SFC Echo Request includes the MAC Context Header, the
   packet's authentication MUST be verified before using any data.  If
   the verification fails, the receiver MUST stop processing the SFC
   Return Path TLV and MUST send the SFC Echo Reply with the Return
   Codes value set to the value Authentication failed from the IANA's
   Return Codes sub-registry of the SFC Echo Request/Echo Reply
   Parameters registry.

   Echo Reply is expected to be sent by the destination SFF of the SFP
   being tested or by the SFF at which SFC TTL expires as defined
   [RFC8300].  The processing described below equally applies to both
   cases and is referred to as responding SFF.

   If the Echo Request message with SFC Reply Path TLV, received by the
   responding SFF, has Reply Mode value of "Reply via Specified Path"
   but no SFC Reply Path TLV is present, then the responding SFF MUST
   send Echo Reply with Return Code set to "Reply Path TLV is missing"
   value (TBA2).  If the responding SFF cannot find the requested SFP it
   MUST send Echo Reply with Return Code set to "Reply SFP was not
   found" (TBA3) and include the SFC Reply Path TLV from the Echo
   Request message.

   Suppose the SFC Echo Request receiver cannot determine whether the
   specified return path SFP has the route to the initiator.  In that
   case, it SHOULD set the value of the Return Codes field to
   "Unverifiable Reply Path" (TBA4).  The receiver MAY drop the Echo
   Request when it cannot determine whether SFP's return path has the
   route to the initiator.  That means, when sending Echo Request, the




Mirsky, et al.            Expires July 23, 2021                 [Page 5]


Internet-Draft     Controlled Return Path for SFC OAM       January 2021


   sender SHOULD choose a proper source address according to specified
   return path SFP to help the receiver to make the decision.

5.1.  Bi-directional SFC Case

   The ability to specify the return path for an Echo Reply might be
   used in the case of bi-directional SFC.  The egress SFF of the
   forward SFP might not be co-located with a classifier of the reverse
   SFP, and thus the egress SFF has no information about the reverse
   path of an SFC.  Because of that, even for bi-directional SFC, a
   reverse SFP needs to be indicated in a Reply Path TLV in the Echo
   Request message.

6.  Security Considerations

   Security considerations discussed in [RFC8300] apply to this
   document.

   The SFC Return Path extension, defined in this document, can be used
   for potential "proxying" attacks.  For example, the Echo Request
   initiator may specify a return path with a destination different from
   that of the initiator.  Such attacks will usually not happen in an
   SFC domain where the initiators and receivers belong to the same
   domain, as specified in [RFC7665].  Even if the attack occurs, to
   prevent using the SFC Return Path extension for proxying any possible
   attacks, the return path SFP SHOULD have a path to reach the sender
   of the Echo Request, identified in SFC Source TLV
   [I-D.ietf-sfc-multi-layer-oam].  The MAC Context Header that is
   defined in [I-D.ietf-sfc-nsh-integrity] MAY be used to protect the
   integrity of the SFC Echo Request/Reply when using the SFC Return
   Path TLV.

7.  IANA Considerations

7.1.  SFC Return Path Type

   IANA is requested to assign from its SFC Echo Request/Echo Reply TLV
   registry new type as follows:

             +-------+----------------------+---------------+
             | Value | Description          | Reference     |
             +-------+----------------------+---------------+
             | TBA1  | SFC Reply Path Type  | This document |
             +-------+----------------------+---------------+

                       Table 1: SFC Return Path Type





Mirsky, et al.            Expires July 23, 2021                 [Page 6]


Internet-Draft     Controlled Return Path for SFC OAM       January 2021


7.2.  New Return Codes

   IANA is requested to assign new return codes from the SFC Echo
   Request/Echo Reply Return Codes sub-registry of the SFC Echo Request/
   Echo Reply Parameters registry as defined in Table 2.

          +-------+----------------------------+---------------+
          | Value | Description                | Reference     |
          +-------+----------------------------+---------------+
          | TBA2  | Reply Path TLV is missing  | This document |
          | TBA3  | Reply SFP was not found    | This document |
          | TBA4  | Unverifiable Reply Path    | This document |
          +-------+----------------------------+---------------+

                   Table 2: SFC Echo Reply Return Codes

8.  References

8.1.  Normative References

   [I-D.ietf-sfc-multi-layer-oam]
              Mirsky, G., Meng, W., Khasnabish, B., and C. Wang, "Active
              OAM for Service Function Chains in Networks", draft-ietf-
              sfc-multi-layer-oam-07 (work in progress), December 2020.

   [I-D.ietf-sfc-nsh-integrity]
              Boucadair, M., Reddy.K, T., and D. Wing, "Integrity
              Protection for the Network Service Header (NSH) and
              Encryption of Sensitive Context Headers", draft-ietf-sfc-
              nsh-integrity-02 (work in progress), January 2021.

   [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>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8300]  Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
              "Network Service Header (NSH)", RFC 8300,
              DOI 10.17487/RFC8300, January 2018,
              <https://www.rfc-editor.org/info/rfc8300>.







Mirsky, et al.            Expires July 23, 2021                 [Page 7]


Internet-Draft     Controlled Return Path for SFC OAM       January 2021


8.2.  Informative References

   [RFC7110]  Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord,
              "Return Path Specified Label Switched Path (LSP) Ping",
              RFC 7110, DOI 10.17487/RFC7110, January 2014,
              <https://www.rfc-editor.org/info/rfc7110>.

   [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
              Chaining (SFC) Architecture", RFC 7665,
              DOI 10.17487/RFC7665, October 2015,
              <https://www.rfc-editor.org/info/rfc7665>.

   [RFC8924]  Aldrin, S., Pignataro, C., Ed., Kumar, N., Ed., Krishnan,
              R., and A. Ghanwani, "Service Function Chaining (SFC)
              Operations, Administration, and Maintenance (OAM)
              Framework", RFC 8924, DOI 10.17487/RFC8924, October 2020,
              <https://www.rfc-editor.org/info/rfc8924>.

Authors' Addresses

   Greg Mirsky
   ZTE Corp.
   1900 McCarthy Blvd. #205
   Milpitas, CA  95035
   USA

   Email: gregimirsky@gmail.com


   Ting Ao
   Individual contributor
   No.889, BiBo Road
   Shanghai  201203
   China

   Phone: +86 17721209283
   Email: 18555817@qq.com


   Zhonghua Chen
   China Telecom
   No.1835, South PuDong Road
   Shanghai  201203
   China

   Phone: +86 18918588897
   Email: 18918588897@189.cn




Mirsky, et al.            Expires July 23, 2021                 [Page 8]


Internet-Draft     Controlled Return Path for SFC OAM       January 2021


   Gyan Mishra
   Verizon Inc.

   Email: gyan.s.mishra@verizon.com















































Mirsky, et al.            Expires July 23, 2021                 [Page 9]