draft-ietf-sfc-multi-layer-oam-14.txt   draft-ietf-sfc-multi-layer-oam-15.txt 
SFC WG G. Mirsky SFC WG G. Mirsky
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 8300 (if approved) W. Meng Updates: 8300 (if approved) W. Meng
Intended status: Standards Track ZTE Corporation Intended status: Standards Track ZTE Corporation
Expires: 11 April 2022 T. Ao Expires: 18 April 2022 T. Ao
Individual contributor Individual contributor
K. Leung K. Leung
Cisco System Cisco System
G. Mishra G. Mishra
Verizon Inc. Verizon Inc.
8 October 2021 15 October 2021
Active OAM for Service Function Chaining Active OAM for Service Function Chaining
draft-ietf-sfc-multi-layer-oam-14 draft-ietf-sfc-multi-layer-oam-15
Abstract Abstract
A set of requirements for active Operation, Administration, and A set of requirements for active Operation, Administration, and
Maintenance (OAM) of Service Function Chains (SFCs) in a network is Maintenance (OAM) of Service Function Chains (SFCs) in a network is
presented in this document. Based on these requirements, an presented in this document. Based on these requirements, an
encapsulation of active OAM messages in SFC and a mechanism to detect encapsulation of active OAM messages in SFC and a mechanism to detect
and localize defects are described. and localize defects are described.
This document updates RFC 8300. Particularly, it updates the This document updates RFC 8300. Particularly, it updates the
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 11 April 2022. This Internet-Draft will expire on 18 April 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 48 skipping to change at page 2, line 48
6.5.3. SFC Echo Reply Reception . . . . . . . . . . . . . . 18 6.5.3. SFC Echo Reply Reception . . . . . . . . . . . . . . 18
6.5.4. Tracing an SFP . . . . . . . . . . . . . . . . . . . 19 6.5.4. Tracing an SFP . . . . . . . . . . . . . . . . . . . 19
6.6. Verification of the SFP Consistency . . . . . . . . . . . 19 6.6. Verification of the SFP Consistency . . . . . . . . . . . 19
6.6.1. SFP Consistency Verification packet . . . . . . . . . 19 6.6.1. SFP Consistency Verification packet . . . . . . . . . 19
6.6.2. SFF Information Record TLV . . . . . . . . . . . . . 20 6.6.2. SFF Information Record TLV . . . . . . . . . . . . . 20
6.6.3. SF Information Sub-TLV . . . . . . . . . . . . . . . 21 6.6.3. SF Information Sub-TLV . . . . . . . . . . . . . . . 21
6.6.4. SF Information Sub-TLV Construction . . . . . . . . . 22 6.6.4. SF Information Sub-TLV Construction . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9.1. SFC Active OAM Protocol . . . . . . . . . . . . . . . . . 25 9.1. SFC Active OAM Protocol . . . . . . . . . . . . . . . . . 24
9.2. SFC Active OAM . . . . . . . . . . . . . . . . . . . . . 25 9.2. SFC Active OAM . . . . . . . . . . . . . . . . . . . . . 25
9.2.1. Version in the Active SFC OAM Header . . . . . . . . 25 9.2.1. Version in the Active SFC OAM Header . . . . . . . . 25
9.2.2. SFC Active OAM Message Type . . . . . . . . . . . . . 25 9.2.2. SFC Active OAM Message Type . . . . . . . . . . . . . 25
9.2.3. SFC Active OAM Header Flags . . . . . . . . . . . . . 26 9.2.3. SFC Active OAM Header Flags . . . . . . . . . . . . . 26
9.3. SFC Echo Request/Echo Reply Parameters . . . . . . . . . 27 9.3. SFC Echo Request/Echo Reply Parameters . . . . . . . . . 27
9.3.1. SFC Echo Request/Reply Version . . . . . . . . . . . 27 9.3.1. SFC Echo Request/Reply Version . . . . . . . . . . . 27
9.3.2. SFC Echo Request Flags . . . . . . . . . . . . . . . 27 9.3.2. SFC Echo Request Flags . . . . . . . . . . . . . . . 27
9.3.3. SFC Echo Request/Echo Reply Message Types . . . . . . 28 9.3.3. SFC Echo Request/Echo Reply Message Types . . . . . . 28
9.3.4. SFC Echo Reply Modes . . . . . . . . . . . . . . . . 29 9.3.4. SFC Echo Reply Modes . . . . . . . . . . . . . . . . 29
skipping to change at page 12, line 12 skipping to change at page 12, line 12
Table 1: SFC Echo Return Codes Table 1: SFC Echo Return Codes
6.2. Authentication in Echo Request/Reply 6.2. Authentication in Echo Request/Reply
Authentication can be used to protect the integrity of the Authentication can be used to protect the integrity of the
information in SFC Echo Request and/or Echo Reply. In the information in SFC Echo Request and/or Echo Reply. In the
[I-D.ietf-sfc-nsh-integrity] a variable-length Context Header has [I-D.ietf-sfc-nsh-integrity] a variable-length Context Header has
been defined to protect the integrity of the NSH and the payload. been defined to protect the integrity of the NSH and the payload.
The header can also be used for the optional encryption of sensitive The header can also be used for the optional encryption of sensitive
metadata. MAC#1 Context Header is more suitable for the integrity metadata. MAC#1 (Message Authentication Code) Context Header is more
protection of active SFC OAM, particularly of the defined in this suitable for the integrity protection of active SFC OAM, particularly
document SFC Echo Request and Echo Reply. On the other hand, using of the defined in this document SFC Echo Request and Echo Reply. On
MAC#2 Context Header allows the detection of mishandling of the O-bit the other hand, using MAC#2 Context Header allows the detection of
by a transient SFC element. mishandling of the O-bit by a transient SFC element.
6.3. SFC Echo Request Transmission 6.3. SFC Echo Request Transmission
SFC Echo Request control packet MUST use the appropriate transport SFC Echo Request control packet MUST use the appropriate transport
encapsulation of the monitored SFP. If the NSH is used, Echo Request encapsulation of the monitored SFP. If the NSH is used, Echo Request
MUST set O bit, as defined in [RFC8300]. NSH MUST be immediately MUST set O bit, as defined in [RFC8300]. NSH MUST be immediately
followed by the SFC Active OAM Header defined in Section 4. The followed by the SFC Active OAM Header defined in Section 4. The
Message Type field's value in the SFC Active OAM Header MUST be set Message Type field's value in the SFC Active OAM Header MUST be set
to SFC Echo Request/Echo Reply value (TBA2) per Section 9.2.2. to SFC Echo Request/Echo Reply value (TBA2) per Section 9.2.2.
skipping to change at page 16, line 7 skipping to change at page 16, line 7
should be sent. The Echo Request sender MAY use TLVs to request that should be sent. The Echo Request sender MAY use TLVs to request that
the corresponding Echo Reply be transmitted over the specified path. the corresponding Echo Reply be transmitted over the specified path.
Section 6.5.1 provides an example of a TLV that specifies the return Section 6.5.1 provides an example of a TLV that specifies the return
path of the Echo Reply. Value TBA3 is the "Do not reply" mode and path of the Echo Reply. Value TBA3 is the "Do not reply" mode and
suppresses the Echo Reply packet transmission. The default value suppresses the Echo Reply packet transmission. The default value
(TBA6) for the Reply mode field requests the responder to send the (TBA6) for the Reply mode field requests the responder to send the
Echo Reply packet out-of-band as IPv4 or IPv6 UDP packet. Echo Reply packet out-of-band as IPv4 or IPv6 UDP packet.
6.5.1. SFC Reply Path TLV 6.5.1. SFC Reply Path TLV
While SFC Echo Request always traverses the SFP, it is directed to, While SFC Echo Request always traverses the SFP, it is directed to
the corresponding Echo Reply usually is sent over an IP network. using NSH, the corresponding Echo Reply usually is sent without NSH.
There are scenarios when it is beneficial to direct the responder to In some cases, an operator might choose to direct the responder to
use a path other than the IP network. This section defines a new send the Echo Reply with NSH over a particular SFP. This section
Type-Length-Value (TLV), Reply Service Function Path TLV, for Reply defines a new Type-Length-Value (TLV), Reply Service Function Path
via Specified Path mode of SFC Echo Reply. TLV, for Reply via Specified Path mode of SFC Echo Reply.
The Reply Service Function Path TLV can provide an efficient The Reply Service Function Path TLV can provide an efficient
mechanism to test SFCs, such as bidirectional and hybrid SFC, as mechanism to test SFCs, such as bidirectional and hybrid SFC, as
defined in Section 2.2 [RFC7665]. For example, it allows an operator defined in Section 2.2 [RFC7665]. For example, it allows an operator
to test both directions of the bidirectional or hybrid SFP with a to test both directions of the bidirectional or hybrid SFP with a
single SFC Echo Request/Echo Reply operation. single SFC Echo Request/Echo Reply operation.
The SFC Reply Path TLV carries the information that sufficiently The SFC Reply Path TLV carries the information that sufficiently
identifies the return SFP that the SFC Echo Reply message is expected 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 7. to follow. The format of SFC Reply Path TLV is shown in Figure 7.
skipping to change at page 17, line 35 skipping to change at page 17, line 35
TLV included in the SFC Echo Request message MUST sufficiently TLV included in the SFC Echo Request message MUST sufficiently
identify the SFP that the sender of the Echo Request message expects identify the SFP that the sender of the Echo Request message expects
the receiver to use for the corresponding SFC Echo Reply. the receiver to use for the corresponding SFC Echo Reply.
When sending an Echo Request, the sender MUST set the value of Reply When sending an Echo Request, the sender MUST set the value of Reply
Mode field to "Reply via Specified Path", defined in Section 6.3, and Mode field to "Reply via Specified Path", defined in Section 6.3, and
if the specified path is an SFC path, the Request MUST include SFC if the specified path is an SFC path, the Request MUST include SFC
Reply Path TLV. The SFC Reply Path TLV consists of the identifier of Reply Path TLV. The SFC Reply Path TLV consists of the identifier of
the reverse SFP and an appropriate Service Index. the reverse SFP and an appropriate Service Index.
The Message Authentication Code (MAC) Context Header that is defined If the NSH of the received SFC Echo Request includes the MAC Context
in [I-D.ietf-sfc-nsh-integrity] MAY be used to protect the SFC Echo Header, the packet's authentication MUST be verified before using any
Request's integrity when using the SFC Return Path TLV. If the NSH data. If the verification fails, the receiver MUST stop processing
of the received SFC Echo Request includes the MAC Context Header, the the SFC Return Path TLV and MUST send the SFC Echo Reply with the
packet's authentication MUST be verified before using any data. If Return Codes value set to the value Authentication failed from the
the verification fails, the receiver MUST stop processing the SFC IANA's Return Codes sub-registry of the SFC Echo Request/Echo Reply
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. Parameters registry.
The destination SFF of the SFP being tested or the SFF at which SFC The destination SFF of the SFP being tested or the SFF at which SFC
TTL expired (as per [RFC8300]) may be sending the Echo Reply. The TTL expired (as per [RFC8300]) may be sending the Echo Reply. The
processing described below equally applies to both cases and is processing described below equally applies to both cases and is
referred to as responding SFF. referred to as responding SFF.
If the Echo Request message with SFC Reply Path TLV, received by the If the Echo Request message with SFC Reply Path TLV, received by the
responding SFF, has Reply Mode value of "Reply via Specified Path" responding SFF, has Reply Mode value of "Reply via Specified Path"
but no SFC Reply Path TLV is present, then the responding SFF MUST but no SFC Reply Path TLV is present, then the responding SFF MUST
skipping to change at page 20, line 9 skipping to change at page 20, line 9
following values detailed in Table 10: following values detailed in Table 10:
* TBA16 - SFP Consistency Verification Request * TBA16 - SFP Consistency Verification Request
* TBA17 - SFP Consistency Verification Reply * TBA17 - SFP Consistency Verification Reply
Upon receiving the CVReq, the SFF MUST respond with the Consistency Upon receiving the CVReq, the SFF MUST respond with the Consistency
Verification Reply (CVRep). The SFF MUST include the SFs Verification Reply (CVRep). The SFF MUST include the SFs
information, as described in Section 6.6.3 and Section 6.6.2. information, as described in Section 6.6.3 and Section 6.6.2.
The initiator of CVReq MAY require the collected information in the The initiator of CVReq MAY require the collected information in the
CVRep be sent in the integrity-protected mode using the Message CVRep be sent in the integrity-protected mode using the MAC Context
Authentication Code (MAC) Context Header, defined in Header, defined in [I-D.ietf-sfc-nsh-integrity]. If the NSH of the
[I-D.ietf-sfc-nsh-integrity]. If the NSH of the received SFC Echo received SFC Echo Reply includes the MAC Context Header, the
Reply includes the MAC Context Header, the authentication of the authentication of the packet MUST be verified before using any data.
packet MUST be verified before using any data. If the verification If the verification fails, the receiver MUST stop processing the SFF
fails, the receiver MUST stop processing the SFF Information Record Information Record TLV and notify an operator. Specification of the
TLV and notify an operator. Specification of the notification notification mechanism is outside the scope of this document.
mechanism is outside the scope of this document.
6.6.2. SFF Information Record TLV 6.6.2. SFF Information Record TLV
For CVReq, the SFF MUST include the Information of SFs into the SF For CVReq, the SFF MUST include the Information of SFs into the SF
Information Record TLV in the CVRep message. Every SFF sends back a Information Record TLV in the CVRep message. Every SFF sends back a
single CVRep message, including information on all the SFs attached single CVRep message, including information on all the SFs attached
to the SFF on the SFP as requested in the CVReq message. to the SFF on the SFP as requested in the CVReq message.
0 1 2 3 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 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
skipping to change at page 23, line 43 skipping to change at page 23, line 32
<............ <............... <............ <...............
CVRep1({SF1a,SF1b}) CVRep2({SF2a,SF2b}) CVRep1({SF1a,SF1b}) CVRep2({SF2a,SF2b})
Figure 12: Example 2 for CVRep with multiple SFs Figure 12: Example 2 for CVRep with multiple SFs
7. Security Considerations 7. Security Considerations
When the integrity protection for SFC active OAM, and SFC Echo When the integrity protection for SFC active OAM, and SFC Echo
Request/Reply in particular, is required, it is RECOMMENDED to use Request/Reply in particular, is required, it is RECOMMENDED to use
one of the Context Headers defined in [I-D.ietf-sfc-nsh-integrity]. one of the Context Headers defined in [I-D.ietf-sfc-nsh-integrity].
MAC#1 (Message Authentication Code) Context Header could be more MAC#1 Context Header could be more suitable for active SFC OAM
suitable for active SFC OAM because it does not require re- because it does not require re-calculation of the MAC when the value
calculation of the MAC when the value of the NSH Base Header's TTL of the NSH Base Header's TTL field is changed. The integrity
field is changed. The integrity protection for SFC active OAM can protection for SFC active OAM can also be achieved using mechanisms
also be achieved using mechanisms in the underlay data plane. For in the underlay data plane. For example, if the underlay is an IPv6
example, if the underlay is an IPv6 network, IP Authentication Header network, IP Authentication Header [RFC4302] or IP Encapsulating
[RFC4302] or IP Encapsulating Security Payload Header [RFC4303] can Security Payload Header [RFC4303] can be used to provide integrity
be used to provide integrity protection. Confidentiality for the SFC protection. Confidentiality for the SFC Echo Request/Reply exchanges
Echo Request/Reply exchanges can be achieved using the IP can be achieved using the IP Encapsulating Security Payload Header
Encapsulating Security Payload Header [RFC4303]. Also, the security [RFC4303]. Also, the security needs for SFC Echo Request/Reply are
needs for SFC Echo Request/Reply are similar to those of ICMP ping similar to those of ICMP ping [RFC0792], [RFC4443] and MPLS LSP ping
[RFC0792], [RFC4443] and MPLS LSP ping [RFC8029]. [RFC8029].
There are at least three approaches to attacking a node in the There are at least three approaches to attacking a node in the
overlay network using the mechanisms defined in the document. One is overlay network using the mechanisms defined in the document. One is
a Denial-of-Service attack, sending an SFC Echo Request to overload a Denial-of-Service attack, sending an SFC Echo Request to overload
an element of the SFC. The second may use spoofing, hijacking, an element of the SFC. The second may use spoofing, hijacking,
replying, or otherwise tampering with SFC Echo Requests and/or replying, or otherwise tampering with SFC Echo Requests and/or
replies to misrepresent, alter the operator's view of the state of replies to misrepresent, alter the operator's view of the state of
the SFC. The third is an unauthorized source using an SFC Echo the SFC. The third is an unauthorized source using an SFC Echo
Request/Reply to obtain information about the SFC and/or its Request/Reply to obtain information about the SFC and/or its
elements, e.g., SFF or SF. elements, e.g., SFF or SF.
 End of changes. 10 change blocks. 
45 lines changed or deleted 41 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/