draft-ietf-sfc-multi-layer-oam-07.txt   draft-ietf-sfc-multi-layer-oam-08.txt 
SFC WG G. Mirsky SFC WG G. Mirsky
Internet-Draft ZTE Corp. Internet-Draft ZTE Corp.
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: June 17, 2021 B. Khasnabish Expires: July 23, 2021 B. Khasnabish
C. Wang C. Wang
Individual contributor Individual contributor
December 14, 2020 January 19, 2021
Active OAM for Service Function Chains in Networks Active OAM for Service Function Chains in Networks
draft-ietf-sfc-multi-layer-oam-07 draft-ietf-sfc-multi-layer-oam-08
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 networks is Maintenance (OAM) of Service Function Chains (SFCs) in networks is
presented. Based on these requirements, an encapsulation of active presented. Based on these requirements, an encapsulation of active
OAM message in SFC and a mechanism to detect and localize defects OAM message in SFC and a mechanism to detect and localize defects
described. Also, this document updates RFC 8300 in the definition of described. Also, this document updates RFC 8300 in the definition of
O (OAM) bit in the Network Service Header (NSH) and defines how the O (OAM) bit in the Network Service Header (NSH) and defines how the
active OAM message is identified in SFC NSH. active OAM message is identified in SFC NSH.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 June 17, 2021. This Internet-Draft will expire on July 23, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 22 skipping to change at page 2, line 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements for Active OAM in SFC Network . . . . . . . . . 4 3. Requirements for Active OAM in SFC Network . . . . . . . . . 4
4. Active OAM Identification in SFC NSH . . . . . . . . . . . . 5 4. Active OAM Identification in SFC NSH . . . . . . . . . . . . 5
5. Echo Request/Echo Reply for SFC in Networks . . . . . . . . . 7 5. Echo Request/Echo Reply for SFC in Networks . . . . . . . . . 7
5.1. Return Codes . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Return Codes . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Authentication in Echo Request/Reply . . . . . . . . . . 9 5.2. Authentication in Echo Request/Reply . . . . . . . . . . 9
5.3. SFC Echo Request Transmission . . . . . . . . . . . . . . 10 5.3. SFC Echo Request Transmission . . . . . . . . . . . . . . 9
5.4. SFC Echo Request Reception . . . . . . . . . . . . . . . 11 5.4. SFC Echo Request Reception . . . . . . . . . . . . . . . 10
5.4.1. Errored TLVs TLV . . . . . . . . . . . . . . . . . . 11 5.4.1. Errored TLVs TLV . . . . . . . . . . . . . . . . . . 10
5.5. SFC Echo Reply Transmission . . . . . . . . . . . . . . . 12 5.5. SFC Echo Reply Transmission . . . . . . . . . . . . . . . 11
5.6. SFC Echo Reply Reception . . . . . . . . . . . . . . . . 13 5.6. SFC Echo Reply Reception . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8.1. SFC Active OAM Protocol . . . . . . . . . . . . . . . . . 15 8.1. SFC Active OAM Protocol . . . . . . . . . . . . . . . . . 14
8.2. SFC Active OAM Message Type . . . . . . . . . . . . . . . 15 8.2. SFC Active OAM Message Type . . . . . . . . . . . . . . . 14
8.3. SFC Echo Request/Echo Reply Parameters . . . . . . . . . 16 8.3. SFC Echo Request/Echo Reply Parameters . . . . . . . . . 15
8.4. SFC Echo Request/Echo Reply Message Types . . . . . . . . 16 8.4. SFC Echo Request/Echo Reply Message Types . . . . . . . . 15
8.5. SFC Echo Reply Modes . . . . . . . . . . . . . . . . . . 16 8.5. SFC Echo Reply Modes . . . . . . . . . . . . . . . . . . 15
8.6. SFC Echo Return Codes . . . . . . . . . . . . . . . . . . 17 8.6. SFC Echo Return Codes . . . . . . . . . . . . . . . . . . 16
8.7. SFC TLV Type . . . . . . . . . . . . . . . . . . . . . . 18 8.7. SFC TLV Type . . . . . . . . . . . . . . . . . . . . . . 17
8.8. SFC OAM UDP Port . . . . . . . . . . . . . . . . . . . . 19 8.8. SFC OAM UDP Port . . . . . . . . . . . . . . . . . . . . 18
8.9. HMAC Type Sub-registry . . . . . . . . . . . . . . . . . 19 8.9. HMAC Type Sub-registry . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
[RFC7665] defines components necessary to implement a Service [RFC7665] defines components necessary to implement a Service
Function Chain (SFC). These include a classifier that performs the Function Chain (SFC). These include a classifier that performs the
classification of incoming packets. A Service Function Forwarder classification of incoming packets. A Service Function Forwarder
(SFF) is responsible for forwarding traffic to one or more connected (SFF) is responsible for forwarding traffic to one or more connected
Service Functions (SFs) according to the information carried in the Service Functions (SFs) according to the information carried in the
SFC encapsulation. SFF also handles traffic coming back from the SF SFC encapsulation. SFF also handles traffic coming back from the SF
and transports the data packets to the next SFF. And the SFF serves and transports the data packets to the next SFF. And the SFF serves
skipping to change at page 4, line 22 skipping to change at page 4, line 22
SMI Structure of Management Information SMI Structure of Management Information
SF: Service Function SF: Service Function
SFC: Service Function Chain SFC: Service Function Chain
SFF: Service Function Forwarder SFF: Service Function Forwarder
SFP: Service Function Path SFP: Service Function Path
MAC: Message Authentication Code
3. Requirements for Active OAM in SFC Network 3. Requirements for Active OAM in SFC Network
To perform the OAM task of fault management (FM) in an SFC, that To perform the OAM task of fault management (FM) in an SFC, that
includes failure detection, defect characterization and localization, includes failure detection, defect characterization and localization,
this document defines the set of requirements for active OAM this document defines the set of requirements for active OAM
mechanisms to be used on an SFC. mechanisms to be used on an SFC.
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
|SF1| |SF2| |SF3| |SF4| |SF5| |SF6| |SF1| |SF2| |SF3| |SF4| |SF5| |SF6|
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
skipping to change at page 7, line 15 skipping to change at page 7, line 15
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | Msg Type | Flags | Length | | V | Msg Type | Flags | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SFC Active OAM Control Packet ~ ~ SFC Active OAM Control Packet ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: SFC Active OAM Header Figure 2: SFC Active OAM Header
V - two bits long field indicates the current version of the SFC V - two-bit-long field indicates the current version of the SFC
active OAM header. The current value is 0. active OAM header. The current value is 0.
Msg Type - six bits long field identifies OAM protocol, e.g., Echo Msg Type - six bits long field identifies OAM protocol, e.g., Echo
Request/Reply or Bidirectional Forwarding Detection. Request/Reply or Bidirectional Forwarding Detection.
Flags - eight bits long field carries bit flags that define Flags - eight bits long field carries bit flags that define
optional capability and thus processing of the SFC active OAM optional capability and thus processing of the SFC active OAM
control packet, e.g., optional timestamping. control packet, e.g., optional timestamping.
Length - two octets long field that is the length of the SFC Length - two octets long field that is the length of the SFC
skipping to change at page 7, line 40 skipping to change at page 7, line 40
Echo Request/Reply is a well-known active OAM mechanism that is Echo Request/Reply is a well-known active OAM mechanism that is
extensively used to detect inconsistencies between a state in control extensively used to detect inconsistencies between a state in control
and the data planes, localize defects in the data plane. The format and the data planes, localize defects in the data plane. The format
of the Echo request/Echo reply control packet is to support ping and of the Echo request/Echo reply control packet is to support ping and
traceroute functionality in SFC in networks Figure 3 resembles the traceroute functionality in SFC in networks Figure 3 resembles the
format of MPLS LSP Ping [RFC8029] with some exceptions. format of MPLS LSP Ping [RFC8029] with some exceptions.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Number | Global Flags | | V | Reserved | Global Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Reply mode | Return Code | Return S.code | | Message Type | Reply mode | Return Code | Return S.code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Handle | | Sender's Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~ ~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: SFC Echo Request/Reply Format Figure 3: SFC Echo Request/Reply Format
The interpretation of the fields is as follows: The interpretation of the fields is as follows:
The Version reflects the current version. The version number is Version (V) is a two-bit-long field indicates the current version
to be incremented whenever a change is made that affects the of the SFC Echo Request/Reply. The current value is 0. The
ability of an implementation to parse or process control packet version number is to be incremented whenever a change is made that
correctly. affects the ability of an implementation to parse or process
control packet correctly.
Reserved - fourteen-bit-long field. It MUST be zeroed on
transmission and ignored on receipt.
The Global Flags is a bit vector field. The Global Flags is a bit vector field.
The Message Type field reflects the type of the packet. Value The Message Type field reflects the type of the packet. Value
TBA3 identifies Echo Request and TBA4 - Echo Reply TBA3 identifies Echo Request and TBA4 - Echo Reply
The Reply Mode defines the type of the return path requested by The Reply Mode defines the type of the return path requested by
the sender of the Echo Request. the sender of the Echo Request.
Return Codes and Subcodes can be used to inform the sender about Return Codes and Subcodes can be used to inform the sender about
skipping to change at page 9, line 30 skipping to change at page 9, line 33
5.1. Return Codes 5.1. Return Codes
The value of the Return Code field is set to zero by the sender of an The value of the Return Code field is set to zero by the sender of an
Echo Request. The receiver of said Echo Request can set it to one of Echo Request. The receiver of said Echo Request can set it to one of
the values listed in Table 9 in the corresponding Echo Reply that it the values listed in Table 9 in the corresponding Echo Reply that it
generates. generates.
5.2. Authentication in Echo Request/Reply 5.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. This document information in SFC Echo Request and/or Echo Reply. In the
defines the Authentication TLV to provide the integrity protection [I-D.ietf-sfc-nsh-integrity] a variable-length Context Header has
for SFC Echo Request/Reply. The format of the Authentication TLV is been defined to protect the integrity of the NSH and the payload.
displayed in Figure 5. The header can also be used for the optional encryption of the
sensitive metadata. MAC#1 Context Header is more suitable for the
0 1 2 3 integrity protection of active SFC OAM, particularly of the defined
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 in this document SFC Echo Request and Echo Reply. On the other hand,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ using MAC#2 Context Header allows the detection of mishandling of the
| Authentication| HMAC Type | Length | O-bit by a transient SFC element.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Digest |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Authentication TLV
where fields are defined as follows:
o Authentication Type - is a one-octet-long field, value TBA15
allocated by IANA Section 8.7.
o HMAC Type - is a one-octet-long field that identifies the type of
the HMAC and the length of the digest and the length of the digest
according to the HTS HMAC Type sub-registry (see Section 8.9).
o Length - two-octet-long field, set equal to the length of the HMAC
field in octets.
o Digest - is a variable-length field that carries HMAC digest of
the text that includes the encompassing TLV.
This specification defines the use of HMAC-SHA-256 truncated to 128
bits ([RFC4868]) in HTS. Future specifications may define the use in
HTS of more advanced cryptographic algorithms or the use of digest of
a different length. HMAC is calculated as defined in [RFC2104] over
text as the concatenation of the Sequence Number, Sender's Handle
fields of the SFC Echo Request/Reply packet (see Figure 3) and, if
present, the preceding TLVs. The digest then MUST be truncated to
128 bits and written into the Digest field. HMAC MUST be verified
before using any data in the included SFC Echo Request or Reply. If
HMAC verification of an SFC Echo Request fails, the system MUST stop
processing it and respond with the SFC Echo Reply setting the value
of the Return Code field to Authentication failed (see Section 5.1).
If HMAC verification of an SFC Echo Reply fails, the system MUST stop
processing it and notify the operator. Specification of the
notification mechanism is outside the scope of this document.
5.3. SFC Echo Request Transmission 5.3. SFC Echo Request Transmission
SFC Echo Request control packet MUST use the appropriate SFC Echo Request control packet MUST use the appropriate
encapsulation of the monitored SFP. If Network Service Header (NSH) encapsulation of the monitored SFP. If Network Service Header (NSH)
is used, Echo Request MUST set O bit, as defined in [RFC8300]. SFC is used, Echo Request MUST set O bit, as defined in [RFC8300]. SFC
NSH MUST be immediately followed by the SFC Active OAM Header defined NSH MUST be immediately followed by the SFC Active OAM Header defined
in Section 4. The Message Type field's value in the SFC Active OAM in Section 4. The Message Type field's value in the SFC Active OAM
Header MUST be set to SFC Echo Request/Echo Reply value (TBA2) per Header MUST be set to SFC Echo Request/Echo Reply value (TBA2) per
Section 8.2. Section 8.2.
skipping to change at page 12, line 17 skipping to change at page 11, line 17
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Errored TLVs | Reserved | Length | | Errored TLVs | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Value |
. . . .
. . . .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Errored TLVs TLV Figure 5: Errored TLVs TLV
where where
The Errored TLVs Type MUST be set to TBA14 Section 8.7. The Errored TLVs Type MUST be set to TBA14 Section 8.7.
Reserved - one-octet-long field. Reserved - one-octet-long field.
Length - two-octet-long field equal to the length of the Value Length - two-octet-long field equal to the length of the Value
field in octets. field in octets.
skipping to change at page 12, line 47 skipping to change at page 11, line 47
and suppresses transmission of Echo Reply packet. The default value and suppresses transmission of Echo Reply packet. 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.
Responder to the SFC Echo Request sends the Echo Reply over IP Responder to the SFC Echo Request sends the Echo Reply over IP
network if the Reply mode is Reply via an IPv4/IPv6 UDP Packet. network if the Reply mode is Reply via an IPv4/IPv6 UDP Packet.
Because SFC NSH does not identify the ingress of the SFP the Echo Because SFC NSH does not identify the ingress of the SFP the Echo
Request, the source ID MUST be included in the message and used as Request, the source ID MUST be included in the message and used as
the IP destination address for IP/UDP encapsulation of the SFC Echo the IP destination address for IP/UDP encapsulation of the SFC Echo
Reply. The sender of the SFC Echo Request MUST include SFC Source Reply. The sender of the SFC Echo Request MUST include SFC Source
TLV Figure 7. TLV Figure 6.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ID | Reserved | Length | | Source ID | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: SFC Source TLV Figure 6: SFC Source TLV
where where
Source ID Type is a one-octet-long field and has the value of Source ID Type is a one-octet-long field and has the value of
TBA13 Section 8.7. TBA13 Section 8.7.
Reserved - one-octet-long field. Reserved - one-octet-long field.
Length is a two-octets-long field, and the value equals the length Length is a two-octets-long field, and the value equals the length
of the Value field in octets. of the Value field in octets.
Value field contains the IP address of the sender of the SFC OAM Value field contains the IP address of the sender of the SFC OAM
control message, IPv4 or IPv6. control message, IPv4 or IPv6.
The UDP destination port for SFC Echo Reply TBA16 will be allocated The UDP destination port for SFC Echo Reply TBA15 will be allocated
by IANA Section 8.8. by IANA Section 8.8.
5.6. SFC Echo Reply Reception 5.6. SFC Echo Reply Reception
An SFF SHOULD NOT accept SFC Echo Reply unless the received passes An SFF SHOULD NOT accept SFC Echo Reply unless the received passes
the following checks: the following checks:
o the received SFC Echo Reply is well-formed; o the received SFC Echo Reply is well-formed;
o it has outstanding SFC Echo Request sent from the UDP port that o it has outstanding SFC Echo Request sent from the UDP port that
skipping to change at page 14, line 7 skipping to change at page 13, line 7
o if the matching to the Echo Request found, the value of the o if the matching to the Echo Request found, the value of the
Sender's Handle n the Echo Request sent is equal to the value of Sender's Handle n the Echo Request sent is equal to the value of
Sender's Handle in the Echo Reply received; Sender's Handle in the Echo Reply received;
o if all checks passed, the SFF checks if the Sequence Number in the o if all checks passed, the SFF checks if the Sequence Number in the
Echo Request sent matches to the Sequence Number in the Echo Reply Echo Request sent matches to the Sequence Number in the Echo Reply
received. received.
6. Security Considerations 6. Security Considerations
This document defines the Authentication TLV (Section 5.2) that can When the integrity protection for SFC active OAM, and SFC Echo
be used to protect the integrity of SFC Echo Request/Reply. The Request/Reply in particular, is required, it is RECOMMENDED to use
integrity protection for SFC Echo Request/Reply can also be achieved one of Context Headers defined in [I-D.ietf-sfc-nsh-integrity].
using mechanisms in the underlay data plane. For example, if the MAC#1 (Message Authentication Code) Context Header could be more
underlay is an IPv6 network, IP Authentication Header [RFC4302] or IP suitable for active SFC OAM because it does not require re-
Encapsulating Security Payload Header [RFC4303] can be used to calculation of the MAC when the value of the NSH Base Header's TTL
provide integrity protection. Confidentiality for the SFC Echo field is changed. The integrity protection for SFC active OAM can
Request/Reply exchanges can be achieved using the IP Encapsulating also be achieved using mechanisms in the underlay data plane. For
Security Payload Header [RFC4303]. Also, the security needs for SFC example, if the underlay is an IPv6 network, IP Authentication Header
Echo Request/Reply are similar to those of ICMP ping [RFC0792], [RFC4302] or IP Encapsulating Security Payload Header [RFC4303] can
[RFC4443] and MPLS LSP ping [RFC8029]. be used to provide integrity protection. Confidentiality for the SFC
Echo Request/Reply exchanges can be achieved using the IP
Encapsulating Security Payload Header [RFC4303]. Also, the security
needs for SFC Echo Request/Reply are similar to those of ICMP ping
[RFC0792], [RFC4443] and MPLS LSP ping [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.
skipping to change at page 19, line 14 skipping to change at page 18, line 14
This document defines the following new values in SFC OAM TLV Type This document defines the following new values in SFC OAM TLV Type
registry: registry:
+-------+--------------------+---------------+ +-------+--------------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+--------------------+---------------+ +-------+--------------------+---------------+
| TBA12 | Multiple TLVs Used | This document | | TBA12 | Multiple TLVs Used | This document |
| TBA13 | Source ID TLV | This document | | TBA13 | Source ID TLV | This document |
| TBA14 | Errored TLVs | This document | | TBA14 | Errored TLVs | This document |
| TBA15 | Authentication TLV | This document |
+-------+--------------------+---------------+ +-------+--------------------+---------------+
Table 11: SFC OAM Type Values Table 11: SFC OAM Type Values
8.8. SFC OAM UDP Port 8.8. SFC OAM UDP Port
IANA is requested to allocate UDP port number according to IANA is requested to allocate UDP port number according to
+--------+-------+-----------+-------------+------------+-----------+ +--------+-------+-----------+-------------+------------+-----------+
| Servic | Port | Transport | Description | Semantics | Reference | | Servic | Port | Transport | Description | Semantics | Reference |
| e Name | Numbe | Protocol | | Definition | | | e Name | Numbe | Protocol | | Definition | |
| | r | | | | | | | r | | | | |
+--------+-------+-----------+-------------+------------+-----------+ +--------+-------+-----------+-------------+------------+-----------+
| SFC | TBA16 | UDP | SFC OAM | Section 5. | This docu | | SFC | TBA15 | UDP | SFC OAM | Section 5. | This docu |
| OAM | | | | 5 | ment | | OAM | | | | 5 | ment |
+--------+-------+-----------+-------------+------------+-----------+ +--------+-------+-----------+-------------+------------+-----------+
Table 12: SFC OAM Port Table 12: SFC OAM Port
8.9. HMAC Type Sub-registry 8.9. HMAC Type Sub-registry
IANA is requested to create the HMAC Type sub-registry as part of the IANA is requested to create the HMAC Type sub-registry as part of the
SFC OAM TLV Type registry. All code points in the range 1 through SFC OAM TLV Type registry. All code points in the range 1 through
127 in this registry shall be allocated according to the "IETF 127 in this registry shall be allocated according to the "IETF
skipping to change at page 20, line 33 skipping to change at page 19, line 33
+-------+-----------------------------+---------------+ +-------+-----------------------------+---------------+
| 1 | HMAC-SHA-256 16 octets long | This document | | 1 | HMAC-SHA-256 16 octets long | This document |
+-------+-----------------------------+---------------+ +-------+-----------------------------+---------------+
Table 14: HMAC Types Table 14: HMAC Types
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300, "Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018, DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>. <https://www.rfc-editor.org/info/rfc8300>.
9.2. Informative References 9.2. Informative References
[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.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981, RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>. <https://www.rfc-editor.org/info/rfc792>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005, DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>. <https://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005, RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>. <https://www.rfc-editor.org/info/rfc4303>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89, Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006, RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>. <https://www.rfc-editor.org/info/rfc4443>.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
384, and HMAC-SHA-512 with IPsec", RFC 4868,
DOI 10.17487/RFC4868, May 2007,
<https://www.rfc-editor.org/info/rfc4868>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665, Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015, DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>. <https://www.rfc-editor.org/info/rfc7665>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/info/rfc7799>. May 2016, <https://www.rfc-editor.org/info/rfc7799>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
 End of changes. 22 change blocks. 
106 lines changed or deleted 72 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/