< draft-ietf-6man-segment-routing-header-01.txt   draft-ietf-6man-segment-routing-header-02.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: September 19, 2016 B. Field Expires: March 24, 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
March 18, 2016 September 20, 2016
IPv6 Segment Routing Header (SRH) IPv6 Segment Routing Header (SRH)
draft-ietf-6man-segment-routing-header-01 draft-ietf-6man-segment-routing-header-02
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 September 19, 2016. This Internet-Draft will expire on March 24, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 2, line 40 skipping to change at page 2, line 40
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Segment Routing Documents . . . . . . . . . . . . . . . . . . 3 1. Segment Routing Documents . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Data Planes supporting Segment Routing . . . . . . . . . 4 2.1. Data Planes supporting Segment Routing . . . . . . . . . 4
2.2. Segment Routing (SR) Domain . . . . . . . . . . . . . . . 4 2.2. Segment Routing (SR) Domain . . . . . . . . . . . . . . . 4
2.2.1. SR Domain in a Service Provider Network . . . . . . . 5 2.2.1. SR Domain in a Service Provider Network . . . . . . . 5
2.2.2. SR Domain in a Overlay Network . . . . . . . . . . . 6 2.2.2. SR Domain in a Overlay Network . . . . . . . . . . . 6
3. Segment Routing Extension Header (SRH) . . . . . . . . . . . 8 3. Segment Routing Extension Header (SRH) . . . . . . . . . . . 7
3.1. SRH TLVs . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. SRH TLVs . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1. Ingress Node TLV . . . . . . . . . . . . . . . . . . 10 3.1.1. Ingress Node TLV . . . . . . . . . . . . . . . . . . 10
3.1.2. Egress Node TLV . . . . . . . . . . . . . . . . . . . 11 3.1.2. Egress Node TLV . . . . . . . . . . . . . . . . . . . 11
3.1.3. Opaque Container TLV . . . . . . . . . . . . . . . . 12 3.1.3. Opaque Container TLV . . . . . . . . . . . . . . . . 11
3.1.4. Padding TLV . . . . . . . . . . . . . . . . . . . . . 12 3.1.4. Padding TLV . . . . . . . . . . . . . . . . . . . . . 12
3.1.5. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . 13 3.1.5. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . 13
3.2. SRH and RFC2460 behavior . . . . . . . . . . . . . . . . 14 3.2. SRH and RFC2460 behavior . . . . . . . . . . . . . . . . 14
4. SRH Procedures . . . . . . . . . . . . . . . . . . . . . . . 15 4. SRH Procedures . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 15 4.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 14
4.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 16 4.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 15
4.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 16 4.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
5.1. Threat model . . . . . . . . . . . . . . . . . . . . . . 17 5.1. Threat model . . . . . . . . . . . . . . . . . . . . . . 17
5.1.1. Source routing threats . . . . . . . . . . . . . . . 18 5.1.1. Source routing threats . . . . . . . . . . . . . . . 17
5.1.2. Applicability of RFC 5095 to SRH . . . . . . . . . . 18 5.1.2. Applicability of RFC 5095 to SRH . . . . . . . . . . 17
5.1.3. Service stealing threat . . . . . . . . . . . . . . . 19 5.1.3. Service stealing threat . . . . . . . . . . . . . . . 18
5.1.4. Topology disclosure . . . . . . . . . . . . . . . . . 19 5.1.4. Topology disclosure . . . . . . . . . . . . . . . . . 18
5.1.5. ICMP Generation . . . . . . . . . . . . . . . . . . . 19 5.1.5. ICMP Generation . . . . . . . . . . . . . . . . . . . 19
5.2. Security fields in SRH . . . . . . . . . . . . . . . . . 20 5.2. Security fields in SRH . . . . . . . . . . . . . . . . . 19
5.2.1. Selecting a hash algorithm . . . . . . . . . . . . . 21 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 . . . . . . . . . . . . . . 22 5.2.3. Pre-shared key management . . . . . . . . . . . . . . 21
5.3. Deployment Models . . . . . . . . . . . . . . . . . . . . 23 5.3. Deployment Models . . . . . . . . . . . . . . . . . . . . 22
5.3.1. Nodes within the SR domain . . . . . . . . . . . . . 23 5.3.1. Nodes within the SR domain . . . . . . . . . . . . . 22
5.3.2. Nodes outside of the SR domain . . . . . . . . . . . 23 5.3.2. Nodes outside of the SR domain . . . . . . . . . . . 22
5.3.3. SR path exposure . . . . . . . . . . . . . . . . . . 24 5.3.3. SR path exposure . . . . . . . . . . . . . . . . . . 23
5.3.4. Impact of BCP-38 . . . . . . . . . . . . . . . . . . 24 5.3.4. Impact of BCP-38 . . . . . . . . . . . . . . . . . . 23
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
7. Manageability Considerations . . . . . . . . . . . . . . . . 25 7. Manageability Considerations . . . . . . . . . . . . . . . . 24
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . 25 10.1. Normative References . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . 26 10.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 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].
Segment Routing use cases are described in Segment Routing use cases are described in [RFC7855] and
[I-D.ietf-spring-problem-statement] and
[I-D.ietf-spring-ipv6-use-cases]. [I-D.ietf-spring-ipv6-use-cases].
Segment Routing protocol extensions are defined in Segment Routing protocol extensions are defined in
[I-D.ietf-isis-segment-routing-extensions], and [I-D.ietf-isis-segment-routing-extensions], and
[I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [I-D.ietf-ospf-ospfv3-segment-routing-extensions].
2. Introduction 2. Introduction
Segment Routing (SR), defined in [I-D.ietf-spring-segment-routing], Segment Routing (SR), defined in [I-D.ietf-spring-segment-routing],
allows a node to steer a packet through a controlled set of allows a node to steer a packet through a controlled set of
skipping to change at page 6, line 9 skipping to change at page 6, line 6
Figure 1: Service Provider SR Domain Figure 1: Service Provider SR Domain
Figure 1 describes an operator network including several ASes and Figure 1 describes an operator network including several ASes and
delivering connectivity between endpoints. In this scenario, Segment delivering connectivity between endpoints. In this scenario, Segment
Routing is used within the operator networks and across the ASes Routing is used within the operator networks and across the ASes
boundaries (all being under the control of the same operator). In boundaries (all being under the control of the same operator). In
this case segment routing can be used in order to address use cases this case segment routing can be used in order to address use cases
such as end-to-end traffic engineering, fast re-route, egress peer such as end-to-end traffic engineering, fast re-route, egress peer
engineering, data-center traffic engineering as described in engineering, data-center traffic engineering as described in
[I-D.ietf-spring-problem-statement], [I-D.ietf-spring-ipv6-use-cases] [RFC7855], [I-D.ietf-spring-ipv6-use-cases] and
and [I-D.ietf-spring-resiliency-use-cases]. [I-D.ietf-spring-resiliency-use-cases].
Typically, an IPv6 packet received at ingress (i.e.: from outside the Typically, an IPv6 packet received at ingress (i.e.: from outside the
SR domain), is classified according to network operator policies and SR domain), is classified according to network operator policies and
such classification results into an outer header with an SRH applied such classification results into an outer header with an SRH applied
to the incoming packet. The SRH contains the list of segment to the incoming packet. The SRH contains the list of segment
representing the path the packet must take inside the SR domain. representing the path the packet must take inside the SR domain.
Thus, the SA of the packet is the ingress node, the DA (due to SRH Thus, the SA of the packet is the ingress node, the DA (due to SRH
procedures described in Section 4) is set as the first segment of the procedures described in Section 4) is set as the first segment of the
path and the last segment of the path is the egress node of the SR path and the last segment of the path is the egress node of the SR
domain. domain.
skipping to change at page 7, line 47 skipping to change at page 7, line 32
In this model, the operator network nodes are transit nodes and, In this model, the operator network nodes are transit nodes and,
according to [RFC2460], MUST NOT inspect the routing extension header according to [RFC2460], MUST NOT inspect the routing extension header
since they are not the DA of the packet. since they are not the DA of the packet.
It is a common practice in operators networks to filter out, at It is a common practice in operators networks to filter out, at
ingress, any packet whose DA is the address of an internal node and ingress, any packet whose DA is the address of an internal node and
it is also possible that an operator would filter out any packet it is also possible that an operator would filter out any packet
destined to an internal address and having an extension header in it. destined to an internal address and having an extension header in it.
This common practice does not impact the SR-enabled traffic between This common practice does not impact the SR-enabled traffic between
the overlay nodes as the intermediate transit networks do never see a the overlay nodes as the intermediate transit networks never see a
destination address belonging to their infrastructure. These SR- destination address belonging to their infrastructure. These SR-
enabled overlay packets will thus never be filtered by the transit enabled overlay packets will thus never be filtered by the transit
operators. operators.
In all cases, transit packets (i.e.: packets whose DA is outside the In all cases, transit packets (i.e.: packets whose DA is outside the
domain of the operator's network) will be forwarded accordingly domain of the operator's network) will be forwarded accordingly
without introducing any security concern in the operator's network. without introducing any security concern in the operator's network.
This is similar to tunneled packets. This is similar to tunneled packets.
3. Segment Routing Extension Header (SRH) 3. Segment Routing Extension Header (SRH)
skipping to change at page 20, line 22 skipping to change at page 19, line 40
deployed for many years. deployed for many years.
5.2. Security fields in SRH 5.2. Security fields in SRH
This section summarizes the use of specific fields in the SRH. They This section summarizes the use of specific fields in the SRH. They
are based on a key-hashed message authentication code (HMAC). are based on a key-hashed message authentication code (HMAC).
The security-related fields in the SRH are instantiated by the HMAC The security-related fields in the SRH are instantiated by the HMAC
TLV, containing: TLV, containing:
o HMAC Key-id, 16 bits wide; o HMAC Key-id, 32 bits wide;
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;
skipping to change at page 26, line 33 skipping to change at page 25, line 49
[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, <http://www.rfc-editor.org/info/rfc6407>. October 2011, <http://www.rfc-editor.org/info/rfc6407>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-isis-segment-routing-extensions] [I-D.ietf-isis-segment-routing-extensions]
Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,
Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS
Extensions for Segment Routing", draft-ietf-isis-segment- Extensions for Segment Routing", draft-ietf-isis-segment-
routing-extensions-06 (work in progress), December 2015. routing-extensions-07 (work in progress), June 2016.
[I-D.ietf-ospf-ospfv3-segment-routing-extensions] [I-D.ietf-ospf-ospfv3-segment-routing-extensions]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3
Extensions for Segment Routing", draft-ietf-ospf-ospfv3- Extensions for Segment Routing", draft-ietf-ospf-ospfv3-
segment-routing-extensions-04 (work in progress), December segment-routing-extensions-06 (work in progress), July
2015. 2016.
[I-D.ietf-spring-ipv6-use-cases] [I-D.ietf-spring-ipv6-use-cases]
Brzozowski, J., Leddy, J., Leung, I., Previdi, S., Brzozowski, J., Leddy, J., Townsley, W., Filsfils, C., and
Townsley, W., Martin, C., Filsfils, C., and R. Maglione, R. Maglione, "IPv6 SPRING Use Cases", draft-ietf-spring-
"IPv6 SPRING Use Cases", draft-ietf-spring-ipv6-use- ipv6-use-cases-07 (work in progress), July 2016.
cases-06 (work in progress), March 2016.
[I-D.ietf-spring-problem-statement]
Previdi, S., Filsfils, C., Decraene, B., Litkowski, S.,
Horneffer, M., and R. Shakir, "SPRING Problem Statement
and Requirements", draft-ietf-spring-problem-statement-07
(work in progress), March 2016.
[I-D.ietf-spring-resiliency-use-cases] [I-D.ietf-spring-resiliency-use-cases]
Francois, P., Filsfils, C., Decraene, B., and R. Shakir, Filsfils, C., Previdi, S., Francois, P., Decraene, B., and
"Use-cases for Resiliency in SPRING", draft-ietf-spring- R. Shakir, "Use-cases for Resiliency in SPRING", draft-
resiliency-use-cases-02 (work in progress), December 2015. ietf-spring-resiliency-use-cases-05 (work in progress),
September 2016.
[I-D.ietf-spring-segment-routing] [I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
and R. Shakir, "Segment Routing Architecture", draft-ietf- and R. Shakir, "Segment Routing Architecture", draft-ietf-
spring-segment-routing-07 (work in progress), December spring-segment-routing-09 (work in progress), July 2016.
2015.
[I-D.ietf-spring-segment-routing-mpls] [I-D.ietf-spring-segment-routing-mpls]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., Litkowski, S., Horneffer, M., Shakir, R.,
and E. Crabbe, "Segment Routing with MPLS data plane", jefftant@gmail.com, j., and E. Crabbe, "Segment Routing
draft-ietf-spring-segment-routing-mpls-03 (work in with MPLS data plane", draft-ietf-spring-segment-routing-
progress), February 2016. mpls-05 (work in progress), July 2016.
[RFC1940] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D. [RFC1940] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D.
Zappala, "Source Demand Routing: Packet Format and Zappala, "Source Demand Routing: Packet Format and
Forwarding Specification (Version 1)", RFC 1940, Forwarding Specification (Version 1)", RFC 1940,
DOI 10.17487/RFC1940, May 1996, DOI 10.17487/RFC1940, May 1996,
<http://www.rfc-editor.org/info/rfc1940>. <http://www.rfc-editor.org/info/rfc1940>.
[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,
skipping to change at page 28, line 5 skipping to change at page 27, line 16
Co-existence Security Considerations", RFC 4942, Co-existence Security Considerations", RFC 4942,
DOI 10.17487/RFC4942, September 2007, DOI 10.17487/RFC4942, September 2007,
<http://www.rfc-editor.org/info/rfc4942>. <http://www.rfc-editor.org/info/rfc4942>.
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
Routing Header for Source Routes with the Routing Protocol Routing Header for Source Routes with the Routing Protocol
for Low-Power and Lossy Networks (RPL)", RFC 6554, for Low-Power and Lossy Networks (RPL)", RFC 6554,
DOI 10.17487/RFC6554, March 2012, DOI 10.17487/RFC6554, March 2012,
<http://www.rfc-editor.org/info/rfc6554>. <http://www.rfc-editor.org/info/rfc6554>.
[RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B.,
Litkowski, S., Horneffer, M., and R. Shakir, "Source
Packet Routing in Networking (SPRING) Problem Statement
and Requirements", RFC 7855, DOI 10.17487/RFC7855, May
2016, <http://www.rfc-editor.org/info/rfc7855>.
Authors' Addresses Authors' Addresses
Stefano Previdi (editor) Stefano Previdi (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Via Del Serafico, 200 Via Del Serafico, 200
Rome 00142 Rome 00142
Italy Italy
Email: sprevidi@cisco.com Email: sprevidi@cisco.com
 End of changes. 24 change blocks. 
55 lines changed or deleted 53 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/