draft-ietf-6man-segment-routing-header-03.txt   draft-ietf-6man-segment-routing-header-04.txt 
Network Working Group S. Previdi, Ed. Network Working Group S. Previdi, Ed.
Internet-Draft C. Filsfils Internet-Draft C. Filsfils
Intended status: Standards Track Cisco Systems, Inc. Intended status: Standards Track Cisco Systems, Inc.
Expires: July 17, 2017 B. Field Expires: July 22, 2017 B. Field
Comcast Comcast
I. Leung I. Leung
Rogers Communications Rogers Communications
J. Linkova J. Linkova
Google Google
E. Aries E. Aries
Facebook Facebook
T. Kosugi T. Kosugi
NTT NTT
E. Vyncke E. Vyncke
Cisco Systems, Inc. Cisco Systems, Inc.
D. Lebrun D. Lebrun
Universite Catholique de Louvain Universite Catholique de Louvain
January 13, 2017 January 18, 2017
IPv6 Segment Routing Header (SRH) IPv6 Segment Routing Header (SRH)
draft-ietf-6man-segment-routing-header-03 draft-ietf-6man-segment-routing-header-04
Abstract Abstract
Segment Routing (SR) allows a node to steer a packet through a Segment Routing (SR) allows a node to steer a packet through a
controlled set of instructions, called segments, by prepending an SR controlled set of instructions, called segments, by prepending an SR
header to the packet. A segment can represent any instruction, header to the packet. A segment can represent any instruction,
topological or service-based. SR allows to enforce a flow through topological or service-based. SR allows to enforce a flow through
any path (topological, or application/service based) while any path (topological, or application/service based) while
maintaining per-flow state only at the ingress node to the SR domain. maintaining per-flow state only at the ingress node to the SR domain.
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 July 17, 2017. This Internet-Draft will expire on July 22, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 3, line 9 skipping to change at page 3, line 9
4. SRH Procedures . . . . . . . . . . . . . . . . . . . . . . . 14 4. SRH Procedures . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 14 4.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 14
4.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 15 4.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 15
4.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 16 4.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
5.1. Threat model . . . . . . . . . . . . . . . . . . . . . . 17 5.1. Threat model . . . . . . . . . . . . . . . . . . . . . . 17
5.1.1. Source routing threats . . . . . . . . . . . . . . . 17 5.1.1. Source routing threats . . . . . . . . . . . . . . . 17
5.1.2. Applicability of RFC 5095 to SRH . . . . . . . . . . 17 5.1.2. Applicability of RFC 5095 to SRH . . . . . . . . . . 17
5.1.3. Service stealing threat . . . . . . . . . . . . . . . 18 5.1.3. Service stealing threat . . . . . . . . . . . . . . . 18
5.1.4. Topology disclosure . . . . . . . . . . . . . . . . . 18 5.1.4. Topology disclosure . . . . . . . . . . . . . . . . . 18
5.1.5. ICMP Generation . . . . . . . . . . . . . . . . . . . 19 5.1.5. ICMP Generation . . . . . . . . . . . . . . . . . . . 18
5.2. Security fields in SRH . . . . . . . . . . . . . . . . . 19 5.2. Security fields in SRH . . . . . . . . . . . . . . . . . 19
5.2.1. Selecting a hash algorithm . . . . . . . . . . . . . 20 5.2.1. Selecting a hash algorithm . . . . . . . . . . . . . 20
5.2.2. Performance impact of HMAC . . . . . . . . . . . . . 21 5.2.2. Performance impact of HMAC . . . . . . . . . . . . . 21
5.2.3. Pre-shared key management . . . . . . . . . . . . . . 21 5.2.3. Pre-shared key management . . . . . . . . . . . . . . 21
5.3. Deployment Models . . . . . . . . . . . . . . . . . . . . 22 5.3. Deployment Models . . . . . . . . . . . . . . . . . . . . 22
5.3.1. Nodes within the SR domain . . . . . . . . . . . . . 22 5.3.1. Nodes within the SR domain . . . . . . . . . . . . . 22
5.3.2. Nodes outside of the SR domain . . . . . . . . . . . 22 5.3.2. Nodes outside of the SR domain . . . . . . . . . . . 22
5.3.3. SR path exposure . . . . . . . . . . . . . . . . . . 23 5.3.3. SR path exposure . . . . . . . . . . . . . . . . . . 23
5.3.4. Impact of BCP-38 . . . . . . . . . . . . . . . . . . 23 5.3.4. Impact of BCP-38 . . . . . . . . . . . . . . . . . . 23
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
7. Manageability Considerations . . . . . . . . . . . . . . . . 24 7. Manageability Considerations . . . . . . . . . . . . . . . . 24
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . 25 10.1. Normative References . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . 25 10.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Segment Routing Documents 1. Segment Routing Documents
Segment Routing terminology is defined in Segment Routing terminology is defined in
[I-D.ietf-spring-segment-routing]. [I-D.ietf-spring-segment-routing].
skipping to change at page 16, line 26 skipping to change at page 16, line 26
4.3. SR Segment Endpoint Node 4.3. SR Segment Endpoint Node
The SR segment endpoint node is the node whose address is in the DA. The SR segment endpoint node is the node whose address is in the DA.
The segment endpoint node inspects the SRH and does: The segment endpoint node inspects the SRH and does:
1. IF DA = myself (segment endpoint) 1. IF DA = myself (segment endpoint)
2. IF Segments Left > 0 THEN 2. IF Segments Left > 0 THEN
decrement Segments Left decrement Segments Left
update DA with Segment List[Segments Left] update DA with Segment List[Segments Left]
3. IF Segments Left == 0 THEN 3. ELSE continue IPv6 processing of the packet
IF Clean-up bit is set THEN remove the SRH
4. ELSE continue IPv6 processing of the packet
End of processing. End of processing.
5. Forward the packet out 4. Forward the packet out
5. Security Considerations 5. Security Considerations
This section analyzes the security threat model, the security issues This section analyzes the security threat model, the security issues
and proposed solutions related to the new Segment Routing Header. and proposed solutions related to the new Segment Routing Header.
The Segment Routing Header (SRH) is simply another type of the The Segment Routing Header (SRH) is simply another type of the
routing header as described in RFC 2460 [RFC2460] and is: routing header as described in RFC 2460 [RFC2460] and is:
o inserted by an SR edge router when entering the segment routing o inserted by an SR edge router when entering the segment routing
skipping to change at page 18, line 50 skipping to change at page 18, line 46
is called 'service stealing prevention'. is called 'service stealing prevention'.
5.1.4. Topology disclosure 5.1.4. Topology disclosure
The SRH may also contains IPv6 addresses of some intermediate SR- The SRH may also contains IPv6 addresses of some intermediate SR-
nodes in the path towards the destination, this obviously reveals nodes in the path towards the destination, this obviously reveals
those addresses to the potentially hostile attackers if those those addresses to the potentially hostile attackers if those
attackers are able to intercept packets containing SRH. On the other attackers are able to intercept packets containing SRH. On the other
hand, if the attacker can do a traceroute whose probes will be hand, if the attacker can do a traceroute whose probes will be
forwarded along the SR path, then there is little learned by forwarded along the SR path, then there is little learned by
intercepting the SRH itself. Also the clean-bit of SRH can help by intercepting the SRH itself.
removing the SRH before forwarding the packet to potentially a non-
trusted part of the network.
5.1.5. ICMP Generation 5.1.5. ICMP Generation
Per section 4.4 of RFC2460 [RFC2460], when destination nodes (i.e. Per section 4.4 of RFC2460 [RFC2460], when destination nodes (i.e.
where the destination address is one of theirs) receive a Routing where the destination address is one of theirs) receive a Routing
Header with unsupported Routing Type, the required behavior is: Header with unsupported Routing Type, the required behavior is:
o If Segments Left is zero, the node must ignore the Routing header o If Segments Left is zero, the node must ignore the Routing header
and proceed to process the next header in the packet. and proceed to process the next header in the packet.
skipping to change at page 20, line 4 skipping to change at page 19, line 46
o HMAC, 256 bits wide (optional, exists only if HMAC Key-id is not o HMAC, 256 bits wide (optional, exists only if HMAC Key-id is not
0). 0).
The HMAC field is the output of the HMAC computation (per RFC 2104 The HMAC field is the output of the HMAC computation (per RFC 2104
[RFC2104]) using a pre-shared key identified by HMAC Key-id and of [RFC2104]) using a pre-shared key identified by HMAC Key-id and of
the text which consists of the concatenation of: the text which consists of the concatenation of:
o the source IPv6 address; o the source IPv6 address;
o First Segment field; o First Segment field;
o an octet whose bit-0 is the clean-up bit flag and others are 0;
o an octet of bit flags;
o HMAC Key-id; o HMAC Key-id;
o all addresses in the Segment List. o all addresses in the Segment List.
The purpose of the HMAC TLV is to verify the validity, the integrity The purpose of the HMAC TLV is to verify the validity, the integrity
and the authorization of the SRH itself. If an outsider of the SR and the authorization of the SRH itself. If an outsider of the SR
domain does not have access to a current pre-shared secret, then it domain does not have access to a current pre-shared secret, then it
cannot compute the right HMAC field and the first SR router on the 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 path processing the SRH and configured to check the validity of the
 End of changes. 10 change blocks. 
14 lines changed or deleted 11 lines changed or added

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