< draft-ietf-6man-segment-routing-header-14.txt   draft-ietf-6man-segment-routing-header-15.txt >
Network Working Group C. Filsfils, Ed. Network Working Group C. Filsfils, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track S. Previdi Intended status: Standards Track S. Previdi
Expires: December 30, 2018 Individual Expires: April 25, 2019 Huawei
J. Leddy J. Leddy
Comcast Individual
S. Matsushima S. Matsushima
Softbank Softbank
D. Voyer, Ed. D. Voyer, Ed.
Bell Canada Bell Canada
June 28, 2018 October 22, 2018
IPv6 Segment Routing Header (SRH) IPv6 Segment Routing Header (SRH)
draft-ietf-6man-segment-routing-header-14 draft-ietf-6man-segment-routing-header-15
Abstract Abstract
Segment Routing can be applied to the IPv6 data plane using a new Segment Routing can be applied to the IPv6 data plane using a new
type of Routing Extension Header. This document describes the type of Routing Extension Header. This document describes the
Segment Routing Extension Header and how it is used by Segment Segment Routing Extension Header and how it is used by Segment
Routing capable nodes. Routing capable nodes.
Requirements Language Requirements Language
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 December 30, 2018. This Internet-Draft will expire on April 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Segment Routing Extension Header . . . . . . . . . . . . . . 4 2. Segment Routing Extension Header . . . . . . . . . . . . . . 4
2.1. SRH TLVs . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. SRH TLVs . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Padding TLVs . . . . . . . . . . . . . . . . . . . . 6 2.1.1. Padding TLVs . . . . . . . . . . . . . . . . . . . . 6
2.1.2. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . 8 2.1.2. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . 7
3. SR Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. SR Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 9 3.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 10
3.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 11
3.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 9 3.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 11
4. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 9 4. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 9 4.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 11
4.1.1. Reduced SRH . . . . . . . . . . . . . . . . . . . . . 10 4.1.1. Reduced SRH . . . . . . . . . . . . . . . . . . . . . 12
4.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 12
4.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 11 4.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 12
4.3.1. FIB Entry Is Locally Instantiated SRv6 END SID . . . 11 4.3.1. FIB Entry Is Locally Instantiated SRv6 END SID . . . 12
4.3.2. FIB Entry is a Local Interface . . . . . . . . . . . 13 4.3.2. FIB Entry is a Local Interface . . . . . . . . . . . 14
4.3.3. FIB Entry Is A Non-Local Route . . . . . . . . . . . 13 4.3.3. FIB Entry Is A Non-Local Route . . . . . . . . . . . 15
4.3.4. FIB Entry Is A No Match . . . . . . . . . . . . . . . 13 4.3.4. FIB Entry Is A No Match . . . . . . . . . . . . . . . 15
4.3.5. Load Balancing and ECMP . . . . . . . . . . . . . . . 13 4.3.5. Load Balancing and ECMP . . . . . . . . . . . . . . . 15
5. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Abstract Representation of an SRH . . . . . . . . . . . . 14 5.1. Abstract Representation of an SRH . . . . . . . . . . . . 15
5.2. Example Topology . . . . . . . . . . . . . . . . . . . . 15 5.2. Example Topology . . . . . . . . . . . . . . . . . . . . 16
5.3. Source SR Node . . . . . . . . . . . . . . . . . . . . . 15 5.3. Source SR Node . . . . . . . . . . . . . . . . . . . . . 17
5.3.1. Intra SR Domain Packet . . . . . . . . . . . . . . . 15 5.3.1. Intra SR Domain Packet . . . . . . . . . . . . . . . 17
5.3.2. Transit Packet Through SR Domain . . . . . . . . . . 16 5.3.2. Transit Packet Through SR Domain . . . . . . . . . . 17
5.4. Transit Node . . . . . . . . . . . . . . . . . . . . . . 16 5.4. Transit Node . . . . . . . . . . . . . . . . . . . . . . 18
5.5. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 16 5.5. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Threat model . . . . . . . . . . . . . . . . . . . . . . 17 6.1. Nodes Within the SR domain . . . . . . . . . . . . . . . 18
6.1.1. Source routing threats . . . . . . . . . . . . . . . 17 6.2. Nodes Outside the SR Domain . . . . . . . . . . . . . . . 18
6.1.2. Applicability of RFC 5095 to SRH . . . . . . . . . . 18 6.2.1. SR Source Nodes Not Directly Connected . . . . . . . 19
6.1.3. Service stealing threat . . . . . . . . . . . . . . . 19
6.1.4. Topology disclosure . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6.1.5. ICMP Generation . . . . . . . . . . . . . . . . . . . 19 7.1. Source Routing Attacks . . . . . . . . . . . . . . . . . 21
6.2. Security fields in SRH . . . . . . . . . . . . . . . . . 19 7.2. Service Theft . . . . . . . . . . . . . . . . . . . . . . 21
6.2.1. Selecting a hash algorithm . . . . . . . . . . . . . 21 7.3. Topology Disclosure . . . . . . . . . . . . . . . . . . . 22
6.2.2. Performance impact of HMAC . . . . . . . . . . . . . 21 7.4. ICMP Generation . . . . . . . . . . . . . . . . . . . . . 22
6.2.3. Pre-shared key management . . . . . . . . . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
6.3. Deployment Models . . . . . . . . . . . . . . . . . . . . 22 8.1. Segment Routing Header Flags Register . . . . . . . . . . 23
6.3.1. Nodes within the SR domain . . . . . . . . . . . . . 22 8.2. Segment Routing Header TLVs Register . . . . . . . . . . 23
6.3.2. Nodes outside of the SR domain . . . . . . . . . . . 22 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 23
6.3.3. SR path exposure . . . . . . . . . . . . . . . . . . 23 9.1. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.3.4. Impact of BCP-38 . . . . . . . . . . . . . . . . . . 23 9.2. Cisco Systems . . . . . . . . . . . . . . . . . . . . . . 24
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 9.3. FD.io . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. Segment Routing Header Flags Register . . . . . . . . . . 24 9.4. Barefoot . . . . . . . . . . . . . . . . . . . . . . . . 24
7.2. Segment Routing Header TLVs Register . . . . . . . . . . 24 9.5. Juniper . . . . . . . . . . . . . . . . . . . . . . . . . 24
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 25 9.6. Huawei . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 25 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25
8.2. Cisco Systems . . . . . . . . . . . . . . . . . . . . . . 25 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
8.3. FD.io . . . . . . . . . . . . . . . . . . . . . . . . . . 25 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.4. Barefoot . . . . . . . . . . . . . . . . . . . . . . . . 25 12.1. Normative References . . . . . . . . . . . . . . . . . . 25
8.5. Juniper . . . . . . . . . . . . . . . . . . . . . . . . . 26 12.2. Informative References . . . . . . . . . . . . . . . . . 26
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
Segment Routing can be applied to the IPv6 data plane using a new Segment Routing can be applied to the IPv6 data plane using a new
type of Routing Extension Header (SRH). This document describes the type of Routing Extension Header (SRH). This document describes the
Segment Routing Extension Header and how it is used by Segment Segment Routing Extension Header and how it is used by Segment
Routing capable nodes. Routing capable nodes.
The Segment Routing Architecture [I-D.ietf-spring-segment-routing] The Segment Routing Architecture [RFC8402] describes Segment Routing
describes Segment Routing and its instantiation in two data planes and its instantiation in two data planes MPLS and IPv6.
MPLS and IPv6.
SR with the MPLS data plane is defined in SR with the MPLS data plane is defined in
[I-D.ietf-spring-segment-routing-mpls]. [I-D.ietf-spring-segment-routing-mpls].
SR with the IPv6 data plane is defined in SR with the IPv6 data plane is defined in
[I-D.filsfils-spring-srv6-network-programming]. [I-D.filsfils-spring-srv6-network-programming].
The encoding of MPLS labels and label stacking are defined in The encoding of MPLS labels and label stacking are defined in
[RFC3032]. [RFC3032].
The encoding of IPv6 segments in the Segment Routing Extension Header The encoding of IPv6 segments in the Segment Routing Extension Header
is defined in this document. is defined in this document.
Terminology used within this document is defined in detail in Terminology used within this document is defined in detail in
[I-D.ietf-spring-segment-routing]. Specifically, these terms: [RFC8402]. Specifically, these terms: Segment Routing, SR Domain,
Segment Routing, SR Domain, SRv6, Segment ID (SID), SRv6 SID, Active SRv6, Segment ID (SID), SRv6 SID, Active Segment, and SR Policy.
Segment, and SR Policy.
2. Segment Routing Extension Header 2. Segment Routing Extension Header
Routing Headers are defined in [RFC8200]. The Segment Routing Header Routing Headers are defined in [RFC8200]. The Segment Routing Header
has a new Routing Type (suggested value 4) to be assigned by IANA. has a new Routing Type (suggested value 4) to be assigned by IANA.
The Segment Routing Header (SRH) is defined as follows: The Segment Routing Header (SRH) is defined as follows:
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 8, line 10 skipping to change at page 7, line 49
Padding: Length octets of padding. Padding bits have no Padding: Length octets of padding. Padding bits have no
semantics. They MUST be set to 0 on transmission and ignored on semantics. They MUST be set to 0 on transmission and ignored on
receipt. receipt.
The PadN TLV MUST be used when more than one byte of padding is The PadN TLV MUST be used when more than one byte of padding is
required. required.
2.1.2. HMAC TLV 2.1.2. HMAC TLV
HMAC TLV is OPTIONAL and contains the HMAC information. The HMAC TLV The keyed Hashed Message Authentication Code (HMAC) TLV is OPTIONAL
has the following format: and has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | RESERVED | | Type | Length | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC Key ID (4 octets) | | HMAC Key ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| // | //
| HMAC (32 octets) // | HMAC (32 octets) //
skipping to change at page 8, line 34 skipping to change at page 8, line 26
where: where:
o Type: to be assigned by IANA (suggested value 5). o Type: to be assigned by IANA (suggested value 5).
o Length: 38. o Length: 38.
o RESERVED: 2 octets. MUST be 0 on transmission and ignored on o RESERVED: 2 octets. MUST be 0 on transmission and ignored on
receipt. receipt.
o HMAC Key ID: 4 octets. o HMAC Key ID: A 4 octet opaque number which uniquely identifies the
pre-shared key and algorithm used to generate the HMAC. If 0, the
HMAC is not included.
o HMAC: 32 octets. o HMAC: 32 octets of keyed HMAC, not present if Key ID is 0.
o HMAC and HMAC Key ID usage is described in Section 6 The HMAC TLV is used to verify the source of a packet is permitted to
use the current segment in the destination address of the packet, and
ensure the segment list is not modified in transit.
The Following applies to the HMAC TLV: 2.1.2.1. HMAC generation
o Local policy determines when to check for an HMAC and potentially The HMAC field is the output of the HMAC computation as defined in
a requirement on where the HMAC TLV must appear (e.g. first TLV). [RFC2104], using:
This local policy is outside the scope of this document. It may
be based on the active segment at an SR Segment endpoint node, the o key: the pre-shared key identified by HMAC Key ID
result of an ACL that considers incoming interface, or other
packet fields. o HMAC algorithm: identified by the HMAC Key ID
o Text: a concatenation of the following fields from the IPv6 header
and the SRH, as it would be received at the node verifying the
HMAC:
* IPv6 header: source address (16 octets)
* IPv6 header: destination address (16 octets)
* SRH: Segments Left (1 octet)
* SRH: Last Entry (1 octet)
* SRH: Flags (1 octet)
* SRH: HMAC Key-id (4 octets)
* SRH: all addresses in the Segment List (variable octets)
The HMAC digest is truncated to 32 octets and placed in the HMAC
field of the HMAC TLV.
For HMAC algorithms producing digests less than 32 octets, the digest
is placed in the lowest order octets of the HMAC field. Remaining
octets MUST be set to zero.
2.1.2.2. HMAC Verification
Local policy determines when to check for an HMAC and potentially a
requirement on where the HMAC TLV must appear (e.g. first TLV).
This local policy is outside the scope of this document. It may be
based on the active segment at an SR Segment endpoint node, the
result of an ACL that considers incoming interface, or other packet
fields.
If HMAC verification is successful, the packet is forwarded to the
next segment.
If HMAC verification fails, an ICMP error message (parameter problem,
error code 0, pointing to the HMAC TLV) SHOULD be generated (but rate
limited) and SHOULD be logged.
2.1.2.3. HMAC Pre-Shared Key Algorithm
The HMAC Key ID field allows for the simultaneous existence of
several hash algorithms (SHA-256, SHA3-256 ... or future ones) as
well as pre-shared keys.
The HMAC Key ID field is opaque, i.e., it has neither syntax nor
semantic except as an identifier of the right combination of pre-
shared key and hash algorithm, and except that a value of 0 means
that there is no HMAC field.
At the HMAC TLV verification node the Key ID uniquely identifies the
pre-shared key and HMAC algorithm.
At the HMAC TLV generating node the Key ID and destination address
uniquely identify the pre-shared key and HMAC algorithm. Utilizing
the destination address with the Key ID allows for overlapping key
IDs amongst different HMAC verification nodes. The Text for the HMAC
computation is set to the IPv6 header fields and SRH fields as they
would appear at the verification node, not necessarily the same as
the source node sending a packet with the HMAC TLV.
Pre-shared key roll-over is supported by having two key IDs in use
while the HMAC TLV generating node and verifying node converge to a
new key.
SRH implementations can support multiple hash functions but MUST
implement SHA-2 [FIPS180-4] in its SHA-256 variant.
The selection of pre-shared key and algorithm, and their distribution
is outside the scope of this document, some options may include:
o in the configuration of the HMAC generating or verifying nodes,
either by static configuration or any SDN oriented approach
o dynamically using a trusted key distribution protocol such as
[RFC6407]
3. SR Nodes 3. SR Nodes
There are different types of nodes that may be involved in segment There are different types of nodes that may be involved in segment
routing networks: source SR nodes originate packets with a segment in routing networks: source SR nodes originate packets with a segment in
the destination address of the IPv6 header, transit nodes that the destination address of the IPv6 header, transit nodes that
forward packets destined to a remote segment, and SR segment endpoint forward packets destined to a remote segment, and SR segment endpoint
nodes that process a local segment in the destination address of an nodes that process a local segment in the destination address of an
IPv6 header. IPv6 header.
skipping to change at page 10, line 26 skipping to change at page 11, line 49
The first element of the SRH Segment List is the ultimate segment. The first element of the SRH Segment List is the ultimate segment.
The second element is the penultimate segment and so on. The second element is the penultimate segment and so on.
The Segments Left field is set to n-1 where n is the number of The Segments Left field is set to n-1 where n is the number of
elements in the SR Policy. elements in the SR Policy.
The Last Entry field is set to n-1 where n is the number of The Last Entry field is set to n-1 where n is the number of
elements in the SR Policy. elements in the SR Policy.
HMAC TLV may be set according to Section 6. HMAC TLV may be set according to Section 7.
The packet is forwarded toward the packet's Destination Address The packet is forwarded toward the packet's Destination Address
(the first segment). (the first segment).
4.1.1. Reduced SRH 4.1.1. Reduced SRH
When a source does not require the entire SID list to be preserved in When a source does not require the entire SID list to be preserved in
the SRH, a reduced SRH may be used. the SRH, a reduced SRH may be used.
A reduced SRH does not contain the first segment of the related SR A reduced SRH does not contain the first segment of the related SR
skipping to change at page 13, line 20 skipping to change at page 14, line 29
For any packet received from interface I1 For any packet received from interface I1
If first TLV is HMAC { If first TLV is HMAC {
Process the HMAC TLV Process the HMAC TLV
} }
Else { Else {
Discard the packet Discard the packet
} }
4.3.1.2. Upper-layer Header or No Next Header 4.3.1.2. Upper-layer Header or No Next Header
Send an ICMP destination unreachable to Send an ICMP parameter problem message to the Source Address and
the Source Address and discard the packet. discard the packet. Error code (TBD by IANA) "SR Upper-layer Header
Error", pointer set to the offset of the upper-layer header.
A unique error code allows an SR Source node to recognize an error in
SID processing at an endpoint.
4.3.2. FIB Entry is a Local Interface 4.3.2. FIB Entry is a Local Interface
If the FIB entry represents a local interface, not locally If the FIB entry represents a local interface, not locally
instantiated as an SRv6 SID, the SRH is processed as follows: instantiated as an SRv6 SID, the SRH is processed as follows:
If Segments Left is zero, the node must ignore the Routing header If Segments Left is zero, the node must ignore the Routing header
and proceed to process the next header in the packet, whose type and proceed to process the next header in the packet, whose type
is identified by the Next Header field in the Routing Header. is identified by the Next Header field in the Routing Header.
skipping to change at page 15, line 31 skipping to change at page 16, line 45
* | | * * | | *
[1]----[3]--------[5]----------------[6]---------[4]---[2] [1]----[3]--------[5]----------------[6]---------[4]---[2]
* | | * * | | *
| | | |
* | | * * | | *
+--------[7]-------+ +--------[7]-------+
* * * *
+ * * * * * * * SR Domain * * * * * * * + + * * * * * * * SR Domain * * * * * * * +
Figure 3
o 3 and 4 are SR Domain edge routers o 3 and 4 are SR Domain edge routers
o 5, 6, and 7 are all SR Domain routers o 5, 6, and 7 are all SR Domain routers
o 8 and 9 are hosts within the SR Domain o 8 and 9 are hosts within the SR Domain
o 1 and 2 are hosts outside the SR Domain o 1 and 2 are hosts outside the SR Domain
5.3. Source SR Node 5.3. Source SR Node
5.3.1. Intra SR Domain Packet 5.3.1. Intra SR Domain Packet
When host 8 sends a packet to host 9 via an SR Policy <S7,A9> the When host 8 sends a packet to host 9 via an SR Policy <S7,A9> the
packet is packet is
P1: (A8,S7)(A9,S7; SL=1) P1: (A8,S7)(A9,S7; SL=1)
skipping to change at page 17, line 5 skipping to change at page 18, line 22
5.5. SR Segment Endpoint Node 5.5. SR Segment Endpoint Node
Node 7 receives packet P1 and, using the logic in section 4.3.1, Node 7 receives packet P1 and, using the logic in section 4.3.1,
sends packet sends packet
P7: (A8,A9)(A9,S7; SL=0) P7: (A8,A9)(A9,S7; SL=0)
on the interface toward router 6. on the interface toward router 6.
6. Security Considerations 6. Deployment Models
This section analyzes the security threat model, the security issues
and proposed solutions related to the new Segment Routing Header.
The Segment Routing Header (SRH) is simply another type of the
Routing Header as described in [RFC8200] and is:
o Added by an SR edge router when entering the segment routing
domain or by the originating host itself. The source host can
even be outside the SR domain;
o inspected and acted upon when reaching the destination address of
the IP header per [RFC8200].
Per [RFC8200], routers on the path that simply forward an IPv6 packet
(i.e. the IPv6 destination address is none of theirs) will never
inspect and process the content of the SRH. Routers whose FIB
contains a locally instantiated SRv6 SID equal to the destination
address field of the IPv6 packet MUST parse the SRH if present, and
if supported and if the local configuration allows it, MUST act
accordingly to the SRH content.
As specified in [RFC8200], the default behavior of a non SR-capable
router upon receipt of an IPv6 packet with SRH destined to an address
of its, is to:
o ignore the SRH completely if the Segment Left field is 0 and
proceed to process the next header in the IPv6 packet;
o discard the IPv6 packet if Segment Left field is greater than 0,
it MAY send a Parameter Problem ICMP message back to the Source
Address.
6.1. Threat model
6.1.1. Source routing threats
Using an SRH is similar to source routing, therefore it has some
well-known security issues as described in [RFC4942] section 2.1.1
and [RFC5095]:
o amplification attacks: where a packet could be forged in such a
way to cause looping among a set of SR-enabled routers causing
unnecessary traffic, hence a Denial of Service (DoS) against
bandwidth;
o reflection attack: where a hacker could force an intermediate node
to appear as the immediate attacker, hence hiding the real
attacker from naive forensic;
o bypass attack: where an intermediate node could be used as a
stepping stone (for example in a De-Militarized Zone) to attack
another host (for example in the datacenter or any back-end
server).
6.1.2. Applicability of RFC 5095 to SRH
First of all, the reader must remember this specific part of section
1 of [RFC5095], "A side effect is that this also eliminates benign
RH0 use-cases; however, such applications may be facilitated by
future Routing Header specifications.". In short, it is not
forbidden to create new secure type of Routing Header; for example,
[RFC6554] (RPL) also creates a new Routing Header type for a specific
application confined in a single network.
In the segment routing architecture described in
[I-D.ietf-spring-segment-routing] there are basically two kinds of
nodes (routers and hosts):
o nodes within the SR domain, which is within one single
administrative domain, i.e., where all nodes are trusted anyway
else the damage caused by those nodes could be worse than
amplification attacks: traffic interception, man-in-the-middle
attacks, more server DoS by dropping packets, and so on.
o nodes outside of the SR domain, which is outside of the
administrative segment routing domain hence they cannot be trusted
because there is no physical security for those nodes, i.e., they
can be replaced by hostile nodes or can be coerced in wrong
behaviors.
The main use case for SR consists of the single administrative domain
where only trusted nodes with SR enabled and configured participate
in SR: this is the same model as in [RFC6554]. All non-trusted nodes
do not participate as either SR processing is not enabled by default
or because they only process SRH from nodes within their domain.
Moreover, all SR nodes ignore SRH created by outsiders based on
topology information (received on a peering or internal interface) or
on presence and validity of the HMAC field. Therefore, if
intermediate nodes ONLY act on valid and authorized SRH (such as
within a single administrative domain), then there is no security
threat similar to RH-0. Hence, the [RFC5095] attacks are not
applicable.
6.1.3. Service stealing threat
Segment routing is used for added value services, there is also a
need to prevent non-participating nodes to use those services; this
is called 'service stealing prevention'.
6.1.4. Topology disclosure
The SRH may also contains SIDs of some intermediate SR-nodes in the
path towards the destination, this obviously reveals those addresses
to the potentially hostile attackers if those attackers are able to
intercept packets containing SRH. On the other hand, if the attacker
can do a traceroute whose probes will be forwarded along the SR
Policy, then there is little learned by intercepting the SRH itself.
6.1.5. ICMP Generation
Per Section 4.4 of [RFC8200], when destination nodes (i.e. where the
destination address is one of theirs) receive a Routing Header with
unsupported Routing Type, the required behavior is:
o If Segments Left is zero, the node must ignore the Routing Header
and proceed to process the next header in the packet.
o If Segments Left is non-zero, the node must discard the packet and
send an ICMP Parameter Problem, Code 0, message to the packet's
Source Address, pointing to the unrecognized Routing Type.
This required behavior could be used by an attacker to force the
generation of ICMP message by any node. The attacker could send
packets with SRH (with Segment Left not set to 0) destined to a node
not supporting SRH. Per [RFC8200], the destination node could
generate an ICMP message, causing a local CPU utilization and if the
source of the offending packet with SRH was spoofed could lead to a
reflection attack without any amplification.
It must be noted that this is a required behavior for any unsupported
Routing Type and not limited to SRH packets. So, it is not specific
to SRH and the usual rate limiting for ICMP generation is required
anyway for any IPv6 implementation and has been implemented and
deployed for many years.
6.2. Security fields in SRH
This section summarizes the use of specific fields in the SRH. They
are based on a key-hashed message authentication code (HMAC).
The security-related fields in the SRH are instantiated by the HMAC
TLV, containing:
o HMAC Key-id, 32 bits wide;
o HMAC, 256 bits wide (optional, exists only if HMAC Key-id is not 6.1. Nodes Within the SR domain
0).
The HMAC field is the output of the HMAC computation (per [RFC2104]) SR Source Nodes within an SR Domain are trusted to generate IPv6
using a pre-shared key identified by HMAC Key-id and of the text packets with SRH. SR segment endpoint nodes receiving packets on
which consists of the concatenation of: interface that are part of the SR Domain may process any packet
destined to a local segment, containing an SRH.
o the source IPv6 address; A SR Source Node connected to the SR Domain via a secure tunnel, e.g.
IPSec tunnel mode [RFC4303] or Ethernet pseudowire [RFC4448], may be
considered trusted and directly connected. Some types of tunnels may
result in additional processing overhead that should be considered in
a deployment.
o Last Entry field; 6.2. Nodes Outside the SR Domain
o an octet of bit flags; Nodes outside the SR Domain cannot be trusted. SR Domain Ingress
routers SHOULD discard packets destined to SIDs within the SR Domain
(regardless of the presence of an SRH) to avoid attacks on the SR
Domain as described and referenced in [RFC5095]. As an additional
layer of protection, SR Segment Endpoint nodes SHOULD discard packets
destined to local SIDs from source addresses not part of the SR
Domain.
o HMAC Key-id; For example, using the example topology from section 5, all SIDs in
the SR Domain (SIDS S1-S9) are assigned within a single IPv6 prefix,
Prefix-S. All SIDs assigned to a node k are assigned within a single
IPv6 prefix Prefix-Sk, all addresses permitted to source packets
destined to SIDs in the SR Domain are assigned within a single IPv6
prefix Prefix-A.
o all addresses in the Segment List. An Infrastructure Access List (IACL), applied to the external
interfaces of SR Domain ingress nodes 3 and 4, that discards packets
destined to a SID covered by Prefix-S is used to discard packets
destined to SIDs within the SR Domain.
The purpose of the HMAC TLV is to verify the validity, the integrity An IACL, applied to each interface of SR Segment Endpoint Nodes k,
and the authorization of the SRH itself. If an outsider of the SR that discards packets destined to a SID covered by Prefix-Sk with a
domain does not have access to a current pre-shared secret, then it source address not covered by Prefix-A.
cannot compute the right HMAC field and the first SR router on the
path processing the SRH and configured to check the validity of the
HMAC will simply reject the packet.
The HMAC TLV is located at the end of the SRH simply because only the Failure to implement a method of ingress filtering, as defined above,
router on the ingress of the SR domain needs to process it, then all exposes the SR domain to source routing attacks from nodes outside
other SR nodes can ignore it (based on local policy) because they the SR Domain, as described and referenced in [RFC5095].
trust the upstream router. This is to speed up forwarding operations
because SR routers which do not validate the SRH do not need to parse
the SRH until the end.
The HMAC Key-id field allows for the simultaneous existence of 6.2.1. SR Source Nodes Not Directly Connected
several hash algorithms (SHA-256, SHA3-256 ... or future ones) as
well as pre-shared keys. The HMAC Key-id field is opaque, i.e., it
has neither syntax nor semantic except as an index to the right
combination of pre-shared key and hash algorithm and except that a
value of 0 means that there is no HMAC field. Having an HMAC Key-id
field allows for pre-shared key roll-over when two pre-shared keys
are supported for a while when all SR nodes converged to a fresher
pre-shared key. It could also allow for interoperation among
different SR domains if allowed by local policy and assuming a
collision-free HMAC Key Id allocation.
When a specific SRH is linked to a time-related service (such as Nodes outside the SR Domain may request, by some trusted means
turbo-QoS for a 1-hour period) where the DA, Segment ID (SID) are outside the scope of this document, a complete SRH including an HMAC
identical, then it is important to refresh the shared-secret TLV which is computed correctly for the SRH.
frequently as the HMAC validity period expires only when the HMAC
Key-id and its associated shared-secret expires.
6.2.1. Selecting a hash algorithm SR Domain ingress routers permit traffic destined to select SIDs with
local policy requiring HMAC TLV processing for those select SIDs,
i.e. those SIDs provide a gateway to the SR Domain for a set of
segment lists.
The HMAC field in the HMAC TLV is 256 bit wide. Therefore, the HMAC If HMAC verification is successful, the packet is forwarded to the
MUST be based on a hash function whose output is at least 256 bits. next segment. Within the SR Domain no further HMAC check need be
If the output of the hash function is 256, then this output is simply performed.
inserted in the HMAC field. If the output of the hash function is
larger than 256 bits, then the output value is truncated to 256 by
taking the least-significant 256 bits and inserting them in the HMAC
field.
SRH implementations can support multiple hash functions but MUST If HMAC verification fails, an ICMP error message (parameter problem,
implement SHA-2 [FIPS180-4] in its SHA-256 variant. error code 0, pointing to the HMAC TLV) SHOULD be generated (but rate
limited) and SHOULD be logged.
NOTE: SHA-1 is currently used by some early implementations used for For example, extending the topology defined in Figure 3, consider
quick interoperations testing, the 160-bit hash value must then be node 3 offering access to a premium SLA service to node 20. Node 20
right-hand padded with 96 bits set to 0. The authors understand that is a trusted SR Source not directly connected to the SR Domain.
this is not secure but is ok for limited tests.
6.2.2. Performance impact of HMAC + * * * * * * * * * * * * * * * * * * * * +
While adding an HMAC to each and every SR packet increases the * [8] [9] *
security, it has a performance impact. Nevertheless, it must be | |
noted that: * | | *
[20]--[11]--[3]--------[5]----------------[6]---------[4]---[2]
* | | *
| |
* | | *
+--------[7]-------+
* *
o the HMAC field is used only when SRH is added by a device (such as + * * * * * * * SR Domain * * * * * * * +
a home set-top box) which is outside of the segment routing
domain. If the SRH is added by a router in the trusted segment
routing domain, then, there is no need for an HMAC field, hence no
performance impact.
o when present, the HMAC field need only be checked and validated by In order to access the SLA service, node 20 must be able to access
the first router of the segment routing domain, this router is segments within the SR Domain. To provide a secure entry point for
named 'validating SR router'. the SLA service, SIDs with local policy requiring HMAC verification
at node k are defined as Hk and assigned from a prefix Prefix-H.
Prefix-H is disjoint with Prefix-S and Prefix-A defined earlier.
o this validating SR router can also have a cache of <IPv6 header + Prefix-H is not part of the IACLs applied at the external facing
SRH, HMAC field value> to improve the performance. It is not the interfaces of node 3 and 4, allowing external nodes access to it.
same use case as in IPsec where HMAC value was unique per packet,
in SRH, the HMAC value is unique per flow.
o hash functions such as SHA-2 have been optimized for security and SID H3 is a SID covered by Prefix-H at node 3.
performance and there are multiple implementations with good
performance.
With the above points in mind, the performance impact of using HMAC Node 20 requests the premium SLA service to node 2 and is provided a
is minimized. pre-computed SRH and HMAC with destination address H3.
6.2.3. Pre-shared key management Node 20 sends a packet with destination addresses set to H2, SRH and
HMAC TLV are as provided for the premium SLA service.
The field HMAC Key-id allows for: Node 3 receives the packet and verifies the HMAC as defined in
section 4.3, forwarding the packet to the next segment in the segment
list or dropping it based on the HMAC result.
o key roll-over: when there is a need to change the key (the hash This use of an HMAC is particularly valuable within an enterprise
pre-shared secret), then multiple pre-shared keys can be used based SR Domain to authenticate a host which is using SRv6 segment
simultaneously. The validating SR router can have a table of routing as documented in [SRN]. In that example, the HMAC is used to
<HMAC Key-id, pre-shared secret> for the currently active and validate a source node is using a permitted segment list.
future keys.
o different algorithms: by extending the previous table to <HMAC 7. Security Considerations
Key-id, hash function, pre-shared secret>, the validating SR
router can also support several hash algorithms (see section
Section 6.2.1)
The pre-shared secret distribution can be done: This section reviews security considerations related to the SRH,
given the SRH processing and deployment models discussed in this
document.
o in the configuration of the validating SR routers, either by As describe in Section 6, it is necessary to filter packets ingress
static configuration or any SDN oriented approach; to the SR Domain destined to segments within the SR Domain. This
ingress filtering is via an IACL at SR Domain ingress border nodes.
Additional protection is applied via an IACL at each SR Segment
Endpoint node, filtering packets not from within the SR Domain,
destined to SIDs in the SR Domain. ACLs are easily supported for
small numbers of prefixes, making summarization important, and when
the prefixes requiring filtering is kept to a seldom changing set.
o dynamically using a trusted key distribution such as [RFC6407] Additionally, ingress filtering of IPv6 source addresses as
recommended in BCP38 SHOULD be used.
The intent of this document is NOT to define yet-another-key- SR Source Nodes not directly connected to the SR Domain may access
distribution-protocol. specific sets of segments within the SR Domain when secured with the
SRH HMAC TLV. The SRH HMAC TLV provides a means of verifying the
validity of ingress packets SRH, limiting access to the segments in
the SR Domain to only those source nodes with permission.
6.3. Deployment Models 7.1. Source Routing Attacks
6.3.1. Nodes within the SR domain [RFC5095] deprecates the Type 0 Routing header due to a number of
significant attacks that are referenced in that document. Such
attacks include bypassing filtering devices, reaching otherwise
unreachable Internet systems, network topology discovery, bandwidth
exhaustion, and defeating anycast.
SR Source Nodes within an SR Domain are trusted to generate IPv6 Because this document specifies that the SRH is for use within an SR
packets with SRH. SR segment endpoint nodes receiving packets on domain protected by ingress filtering via IACLs, and by
interface that are part of the SR Domain may process any packet cryptographically authenticated SR source nodes not directly
destined to a local segment, containing an SRH. connected to the SR Domain; such attacks cannot be mounted from
outside an SR Domain. As specified in this document, SR Domain
ingress edge nodes drop packets entering the SR Domain destined to
segments within the SR Domain.
6.3.2. Nodes outside of the SR domain Aditionally, this document specifies the use of IACL on SR Segment
Endpoint nodes within the SR Domain to limit the source addresses
permitted to send packets to a SID in the SR Domain.
Nodes outside the SR Domain cannot be trusted. SR Domain Ingress Such attacks may, however, be mounted from within the SR Domain, from
routers SHOULD discard packets destined to SIDs within the SR Domain nodes permitted to source traffic to SIDs in the domain. As such,
(regardless of the presence of an SRH) to avoid attacks on the SR these attacks and other known attacks on an IP network (e.g. DOS/
Domain. This is accomplished via infrastructure Access Lists (iACLs) DDOS, topology discovery, man-in-the-middle, traffic interception/
applied on domain ingress nodes. However the SR Domain may be siphoning), can occur from compromised nodes within an SR Domain.
extended to nodes outside of it via use of the SRH HMAC.
Nodes outside the SR Domain may request, by some trusted means 7.2. Service Theft
outside the scope of this document, a complete SRH including an HMAC
TLV which is computed correctly for the SRH (see Section 6.2).
SR Domain ingress routers permit traffic destined to select SIDs with Service theft is defined as the use of a service offered by the SR
local policy requiring HMAC TLV processing for those select SIDs, Domain by a node not authorized to use the service.
i.e. these SIDs provide a gateway to the SR Domain for a set of
segment lists.
If HMAC validation is successful, the packet is forwarded to the next Service theft is not a concern within the SR Domain as all SR Source
segment. Within the SR Domain no further HMAC check need be nodes and SR segment endpoint nodes within the domain are able to
performed. However, other segments in the SR domain MAY verify the utilizing the services of the Domain. If a node outside the SR
HMAC TLV when the SRH is processed, dependent on local policy. Domain learns of segments or a topological service within the SR
domain, IACL filtering denies access to those segments.
If HMAC validation fails an ICMP error message (parameter problem) Nodes outside the SR Domain, capable of intercepting packets from SR
SHOULD be generated (but rate limited) and SHOULD be logged. Source nodes not directly connected to the SR Domain utilizing the
SRH HMAC, may steel the outer IP header SRH and HMAC TLV. If such an
attacker is capable of spoofing the source address of the original
sender it may use the IP header and HMAC to access services of the SR
Domain intended for the original SR Source node.
6.3.3. SR path exposure Frequent rekeying of the HMAC TLV helps mitigate against this attack
but cannot prevent it.
The SRH contains a Segment List. If an observer outside the SR However, as described in Section 6.2.1, there exist use cases where
Domain is able to inspect the SRH, they may use the segments in the the risk of service threat is of minimum concern and the HMAC TLV is
Segment List to launch an attack on the SR Domain or obtain knowledge used primarily to validate that the source is permitted to use the
of the topology within the SR Domain. When the SR Source node is segment list in the SRH.
outside the SR Domain and the packet traverses the public internet to
the SR Domain ingress router it is likely that others will have
access to the Segment List in the SRH.
IPSec Encapsulating Security Payload (ESP), [RFC4303], cannot be use 7.3. Topology Disclosure
to protect the SRH as the ESP header must appear after the routing
header (including SRH).
Exposure of segments and TLV content to observers outside the SR The SRH may contains SIDs of some intermediate SR-nodes in the path
Domain should be considered in any deployment. There are two methods towards the destination, this reveals those addresses to attackers if
to limit exposure, and attacks on segments within the SR Domain from they are able to intercept packets containing SRH.
outside the SR Domain:
Limit the number of segments and the TLV data exposed in SRH from This is applicable within an SR Domain but the disclosure is less
nodes outside the SR Domain. relevant as an attacker has other means of learning topology.
Restrict which SIDs may accept traffic from outside the SR Domain For an SR Source node not directly connected to the SR Domain this
to only those enforcing HMAC verification by using iACLs (as disclosure is applicable. While the segments within the SR domain
described in Section 6.3.2). disclosed in SRH are protected by ingress filtering, they may be
learned by an attacker external to the SR Domain.
6.3.4. Impact of BCP-38 As described in Section 6.2.1, there exist use cases where the risk
of topology disclosure is of minimum concern when the HMAC TLV is
used primarily to validate that the source is permitted to use the
segment list in the SRH.
BCP-38 [RFC2827], also known as "Network Ingress Filtering", checks 7.4. ICMP Generation
whether the source address of packets received on an interface is
valid for this interface. The use of loose source routing such as
SRH forces packets to follow a path which differs from the expected
routing. Therefore, if BCP-38 was implemented in all routers inside
the SR domain, SR packets could be received by an interface which is
not the expected one, and the packets could be dropped.
As BCP-38 is only deployed at the ingress routers of an The generation of ICMPv6 error messages may be used to attempt
administrative domain, and as Packets arriving at those ingress denial-of-service attacks by sending an error-causing destination
routers have been forwarded using the routing information, then there address or SRH in back-to-back packets. An implementation that
is no reason why this ingress router should drop the SRH packet based correctly follows Section 2.4 of [RFC4443] would be protected by the
on BCP-38. Routers inside the domain commonly do not apply BCP-38; ICMPv6 rate-limiting mechanism.
so, this is not a problem.
7. IANA Considerations 8. IANA Considerations
This document makes the following registrations in the Internet This document makes the following registrations in the Internet
Protocol Version 6 (IPv6) Parameters "Routing Type" registry Protocol Version 6 (IPv6) Parameters "Routing Type" registry
maintained by IANA: maintained by IANA:
Suggested Description Reference Suggested Description Reference
Value Value
---------------------------------------------------------- ----------------------------------------------------------
4 Segment Routing Header (SRH) This document 4 Segment Routing Header (SRH) This document
This document request IANA to create and maintain a new Registry: This document request IANA to create and maintain a new Registry:
"Segment Routing Header TLVs" "Segment Routing Header TLVs"
7.1. Segment Routing Header Flags Register 8.1. Segment Routing Header Flags Register
This document requests the creation of a new IANA managed registry to This document requests the creation of a new IANA managed registry to
identify SRH Flags Bits. The registration procedure is "Expert identify SRH Flags Bits. The registration procedure is "Expert
Review" as defined in [RFC8126]. Suggested registry name is "Segment Review" as defined in [RFC8126]. Suggested registry name is "Segment
Routing Header Flags". Flags is 8 bits, the following bits are Routing Header Flags". Flags is 8 bits, the following bits are
defined in this document: defined in this document:
Suggested Description Reference Suggested Description Reference
Bit Bit
----------------------------------------------------- -----------------------------------------------------
4 HMAC This document 4 HMAC This document
7.2. Segment Routing Header TLVs Register 8.2. Segment Routing Header TLVs Register
This document requests the creation of a new IANA managed registry to This document requests the creation of a new IANA managed registry to
identify SRH TLVs. The registration procedure is "Expert Review" as identify SRH TLVs. The registration procedure is "Expert Review" as
defined in [RFC8126]. Suggested registry name is "Segment Routing defined in [RFC8126]. Suggested registry name is "Segment Routing
Header TLVs". A TLV is identified through an unsigned 8 bit Header TLVs". A TLV is identified through an unsigned 8 bit
codepoint value. The following codepoints are defined in this codepoint value. The following codepoints are defined in this
document: document:
Suggested Description Reference Suggested Description Reference
Value Value
----------------------------------------------------- -----------------------------------------------------
5 HMAC TLV This document 5 HMAC TLV This document
128 Pad0 TLV This document 128 Pad0 TLV This document
129 PadN TLV This document 129 PadN TLV This document
8. Implementation Status 9. Implementation Status
This section is to be removed prior to publishing as an RFC. This section is to be removed prior to publishing as an RFC.
8.1. Linux 9.1. Linux
Name: Linux Kernel v4.14 Name: Linux Kernel v4.14
Status: Production Status: Production
Implementation: adds SRH, performs END processing, supports HMAC TLV Implementation: adds SRH, performs END processing, supports HMAC TLV
Details: https://irtf.org/anrw/2017/anrw17-final3.pdf and Details: https://irtf.org/anrw/2017/anrw17-final3.pdf and
[I-D.filsfils-spring-srv6-interop] [I-D.filsfils-spring-srv6-interop]
8.2. Cisco Systems 9.2. Cisco Systems
Name: IOS XR and IOS XE Name: IOS XR and IOS XE
Status: Pre-production Status: Pre-production
Implementation: adds SRH, performs END processing, no TLV processing Implementation: adds SRH, performs END processing, no TLV processing
Details: [I-D.filsfils-spring-srv6-interop] Details: [I-D.filsfils-spring-srv6-interop]
8.3. FD.io 9.3. FD.io
Name: VPP/Segment Routing for IPv6 Name: VPP/Segment Routing for IPv6
Status: Production Status: Production
Implementation: adds SRH, performs END processing, no TLV processing Implementation: adds SRH, performs END processing, no TLV processing
Details: https://wiki.fd.io/view/VPP/Segment_Routing_for_IPv6 and Details: https://wiki.fd.io/view/VPP/Segment_Routing_for_IPv6 and
[I-D.filsfils-spring-srv6-interop] [I-D.filsfils-spring-srv6-interop]
8.4. Barefoot 9.4. Barefoot
Name: Barefoot Networks Tofino NPU Name: Barefoot Networks Tofino NPU
Status: Prototype Status: Prototype
Implementation: performs END processing, no TLV processing Implementation: performs END processing, no TLV processing
Details: [I-D.filsfils-spring-srv6-interop] Details: [I-D.filsfils-spring-srv6-interop]
8.5. Juniper 9.5. Juniper
Name: Juniper Networks Trio and vTrio NPU's Name: Juniper Networks Trio and vTrio NPU's
Status: Prototype & Experimental Status: Prototype & Experimental
Implementation: SRH insertion mode, Process SID where SID is an Implementation: SRH insertion mode, Process SID where SID is an
interface address, no TLV processing interface address, no TLV processing
9. Contributors 9.6. Huawei
Name: Huawei Systems VRP Platform
Status: Production
Implementation: adds SRH, performs END processing, no TLV processing
10. Contributors
Kamran Raza, Darren Dukes, Brian Field, Daniel Bernier, Ida Leung, Kamran Raza, Darren Dukes, Brian Field, Daniel Bernier, Ida Leung,
Jen Linkova, Ebben Aries, Tomoya Kosugi, Eric Vyncke, David Lebrun, Jen Linkova, Ebben Aries, Tomoya Kosugi, Eric Vyncke, David Lebrun,
Dirk Steinberg, Robert Raszuk, Dave Barach, John Brzozowski, Pierre Dirk Steinberg, Robert Raszuk, Dave Barach, John Brzozowski, Pierre
Francois, Nagendra Kumar, Mark Townsley, Christian Martin, Roberta Francois, Nagendra Kumar, Mark Townsley, Christian Martin, Roberta
Maglione, James Connolly, Aloys Augustin contributed to the content Maglione, James Connolly, Aloys Augustin contributed to the content
of this document. of this document.
10. Acknowledgements 11. Acknowledgements
The authors would like to thank Ole Troan, Bob Hinden, Ron Bonica, The authors would like to thank Ole Troan, Bob Hinden, Ron Bonica,
Fred Baker, Brian Carpenter, Alexandru Petrescu, Punit Kumar Jaiswal, Fred Baker, Brian Carpenter, Alexandru Petrescu, Punit Kumar Jaiswal,
and David Lebrun for their comments to this document. and David Lebrun for their comments to this document.
11. References 12. References
11.1. Normative References 12.1. Normative References
[FIPS180-4] [FIPS180-4]
National Institute of Standards and Technology, "FIPS National Institute of Standards and Technology, "FIPS
180-4 Secure Hash Standard (SHS)", March 2012, 180-4 Secure Hash Standard (SHS)", March 2012,
<http://csrc.nist.gov/publications/fips/fips180-4/ <http://csrc.nist.gov/publications/fips/fips180-4/
fips-180-4.pdf>. fips-180-4.pdf>.
[I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing
Architecture", draft-ietf-spring-segment-routing-15 (work
in progress), January 2018.
[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>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095, of Type 0 Routing Headers in IPv6", RFC 5095,
DOI 10.17487/RFC5095, December 2007, DOI 10.17487/RFC5095, December 2007,
<https://www.rfc-editor.org/info/rfc5095>. <https://www.rfc-editor.org/info/rfc5095>.
[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain
of Interpretation", RFC 6407, DOI 10.17487/RFC6407, of Interpretation", RFC 6407, DOI 10.17487/RFC6407,
October 2011, <https://www.rfc-editor.org/info/rfc6407>. October 2011, <https://www.rfc-editor.org/info/rfc6407>.
[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>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
11.2. Informative References [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
12.2. Informative References
[I-D.filsfils-spring-srv6-interop] [I-D.filsfils-spring-srv6-interop]
Filsfils, C., Clad, F., Camarillo, P., Abdelsalam, A., Filsfils, C., Clad, F., Camarillo, P., Abdelsalam, A.,
Salsano, S., Bonaventure, O., Horn, J., and J. Liste, Salsano, S., Bonaventure, O., Horn, J., and J. Liste,
"SRv6 interoperability report", draft-filsfils-spring- "SRv6 interoperability report", draft-filsfils-spring-
srv6-interop-00 (work in progress), March 2018. srv6-interop-01 (work in progress), September 2018.
[I-D.filsfils-spring-srv6-network-programming] [I-D.filsfils-spring-srv6-network-programming]
Filsfils, C., Li, Z., Leddy, J., daniel.voyer@bell.ca, d., Filsfils, C., Camarillo, P., Leddy, J.,
daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6
Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., Network Programming", draft-filsfils-spring-srv6-network-
Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., and programming-05 (work in progress), July 2018.
M. Sharif, "SRv6 Network Programming", draft-filsfils-
spring-srv6-network-programming-04 (work in progress),
March 2018.
[I-D.ietf-spring-segment-routing-mpls] [I-D.ietf-spring-segment-routing-mpls]
Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing with MPLS Litkowski, S., and R. Shakir, "Segment Routing with MPLS
data plane", draft-ietf-spring-segment-routing-mpls-14 data plane", draft-ietf-spring-segment-routing-mpls-14
(work in progress), June 2018. (work in progress), June 2018.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<https://www.rfc-editor.org/info/rfc3032>. <https://www.rfc-editor.org/info/rfc3032>.
[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>.
[RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
Co-existence Security Considerations", RFC 4942, RFC 4303, DOI 10.17487/RFC4303, December 2005,
DOI 10.17487/RFC4942, September 2007, <https://www.rfc-editor.org/info/rfc4303>.
<https://www.rfc-editor.org/info/rfc4942>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron,
"Encapsulation Methods for Transport of Ethernet over MPLS
Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006,
<https://www.rfc-editor.org/info/rfc4448>.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
DOI 10.17487/RFC5308, October 2008, DOI 10.17487/RFC5308, October 2008,
<https://www.rfc-editor.org/info/rfc5308>. <https://www.rfc-editor.org/info/rfc5308>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>. <https://www.rfc-editor.org/info/rfc5340>.
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
for Equal Cost Multipath Routing and Link Aggregation in for Equal Cost Multipath Routing and Link Aggregation in
Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011,
<https://www.rfc-editor.org/info/rfc6438>. <https://www.rfc-editor.org/info/rfc6438>.
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
Routing Header for Source Routes with the Routing Protocol
for Low-Power and Lossy Networks (RPL)", RFC 6554,
DOI 10.17487/RFC6554, March 2012,
<https://www.rfc-editor.org/info/rfc6554>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
Authors' Addresses [SRN] and , "Software Resolved Networks: Rethinking Enterprise
Networks with IPv6 Segment Routing", 2018,
<https://inl.info.ucl.ac.be/system/files/
sosr18-final15-embedfonts.pdf>.
Authors' Addresses
Clarence Filsfils (editor) Clarence Filsfils (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Brussels Brussels
BE BE
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
Stefano Previdi Stefano Previdi
Individual Huawei
Italy Italy
Email: stefano@previdi.net Email: stefano@previdi.net
John Leddy John Leddy
Comcast Individual
4100 East Dry Creek Road
Centennial, CO 80122
US US
Email: John_Leddy@comcast.com Email: john@leddy.net
Satoru Matsushima Satoru Matsushima
Softbank Softbank
Email: satoru.matsushima@g.softbank.co.jp Email: satoru.matsushima@g.softbank.co.jp
Daniel Voyer (editor) Daniel Voyer (editor)
Bell Canada Bell Canada
Email: daniel.voyer@bell.ca Email: daniel.voyer@bell.ca
 End of changes. 95 change blocks. 
432 lines changed or deleted 378 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/