--- /dev/null
+Network Working Group S. Previdi, Ed.
+Internet-Draft C. Filsfils
+Intended status: Standards Track Cisco Systems, Inc.
+Expires: August 5, 2017 B. Field
+ Comcast
+ I. Leung
+ Rogers Communications
+ J. Linkova
+ Google
+ E. Aries
+ Facebook
+ T. Kosugi
+ NTT
+ E. Vyncke
+ Cisco Systems, Inc.
+ D. Lebrun
+ Universite Catholique de Louvain
+ February 1, 2017
+
+
+ IPv6 Segment Routing Header (SRH)
+ draft-ietf-6man-segment-routing-header-05
+
+Abstract
+
+ Segment Routing (SR) allows a node to steer a packet through a
+ controlled set of instructions, called segments, by prepending an SR
+ header to the packet. A segment can represent any instruction,
+ topological or service-based. SR allows to enforce a flow through
+ any path (topological, or application/service based) while
+ maintaining per-flow state only at the ingress node to the SR domain.
+
+ Segment Routing can be applied to the IPv6 data plane with the
+ addition of a new type of Routing Extension Header. This draft
+ describes the Segment Routing Extension Header Type and how it is
+ used by SR capable nodes.
+
+Requirements Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+Status of This Memo
+
+ This Internet-Draft is submitted in full conformance with the
+ provisions of BCP 78 and BCP 79.
+
+
+
+
+Previdi, et al. Expires August 5, 2017 [Page 1]
+
+Internet-Draft IPv6 Segment Routing Header (SRH) February 2017
+
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF). Note that other groups may also distribute
+ working documents as Internet-Drafts. The list of current Internet-
+ Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ This Internet-Draft will expire on August 5, 2017.
+
+Copyright Notice
+
+ Copyright (c) 2017 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Segment Routing Documents . . . . . . . . . . . . . . . . . . 3
+ 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2.1. Data Planes supporting Segment Routing . . . . . . . . . 4
+ 2.2. Segment Routing (SR) Domain . . . . . . . . . . . . . . . 4
+ 2.2.1. SR Domain in a Service Provider Network . . . . . . . 5
+ 2.2.2. SR Domain in a Overlay Network . . . . . . . . . . . 6
+ 3. Segment Routing Extension Header (SRH) . . . . . . . . . . . 7
+ 3.1. SRH TLVs . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 3.1.1. Ingress Node TLV . . . . . . . . . . . . . . . . . . 10
+ 3.1.2. Egress Node TLV . . . . . . . . . . . . . . . . . . . 11
+ 3.1.3. Opaque Container TLV . . . . . . . . . . . . . . . . 11
+ 3.1.4. Padding TLV . . . . . . . . . . . . . . . . . . . . . 12
+ 3.1.5. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . 13
+ 3.2. SRH and RFC2460 behavior . . . . . . . . . . . . . . . . 14
+ 4. SRH Procedures . . . . . . . . . . . . . . . . . . . . . . . 14
+ 4.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 14
+ 4.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 15
+ 4.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 16
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
+
+
+
+Previdi, et al. Expires August 5, 2017 [Page 2]
+
+Internet-Draft IPv6 Segment Routing Header (SRH) February 2017
+
+
+ 5.1. Threat model . . . . . . . . . . . . . . . . . . . . . . 17
+ 5.1.1. Source routing threats . . . . . . . . . . . . . . . 17
+ 5.1.2. Applicability of RFC 5095 to SRH . . . . . . . . . . 17
+ 5.1.3. Service stealing threat . . . . . . . . . . . . . . . 18
+ 5.1.4. Topology disclosure . . . . . . . . . . . . . . . . . 18
+ 5.1.5. ICMP Generation . . . . . . . . . . . . . . . . . . . 18
+ 5.2. Security fields in SRH . . . . . . . . . . . . . . . . . 19
+ 5.2.1. Selecting a hash algorithm . . . . . . . . . . . . . 20
+ 5.2.2. Performance impact of HMAC . . . . . . . . . . . . . 21
+ 5.2.3. Pre-shared key management . . . . . . . . . . . . . . 21
+ 5.3. Deployment Models . . . . . . . . . . . . . . . . . . . . 22
+ 5.3.1. Nodes within the SR domain . . . . . . . . . . . . . 22
+ 5.3.2. Nodes outside of the SR domain . . . . . . . . . . . 22
+ 5.3.3. SR path exposure . . . . . . . . . . . . . . . . . . 23
+ 5.3.4. Impact of BCP-38 . . . . . . . . . . . . . . . . . . 23
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
+ 7. Manageability Considerations . . . . . . . . . . . . . . . . 24
+ 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24
+ 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . 25
+ 10.2. Informative References . . . . . . . . . . . . . . . . . 25
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
+
+1. Segment Routing Documents
+
+ Segment Routing terminology is defined in
+ [I-D.ietf-spring-segment-routing].
+
+ Segment Routing use cases are described in [RFC7855] and
+ [I-D.ietf-spring-ipv6-use-cases].
+
+ Segment Routing protocol extensions are defined in
+ [I-D.ietf-isis-segment-routing-extensions], and
+ [I-D.ietf-ospf-ospfv3-segment-routing-extensions].
+
+2. Introduction
+
+ Segment Routing (SR), defined in [I-D.ietf-spring-segment-routing],
+ allows a node to steer a packet through a controlled set of
+ instructions, called segments, by prepending an SR header to the
+ packet. A segment can represent any instruction, topological or
+ service-based. SR allows to enforce a flow through any path
+ (topological or service/application based) while maintaining per-flow
+ state only at the ingress node to the SR domain. Segments can be
+ derived from different components: IGP, BGP, Services, Contexts,
+ Locators, etc. The list of segment forming the path is called the
+ Segment List and is encoded in the packet header.
+
+
+
+Previdi, et al. Expires August 5, 2017 [Page 3]
+
+Internet-Draft IPv6 Segment Routing Header (SRH) February 2017
+
+
+ SR allows the use of strict and loose source based routing paradigms
+ without requiring any additional signaling protocols in the
+ infrastructure hence delivering an excellent scalability property.
+
+ The source based routing model described in
+ [I-D.ietf-spring-segment-routing] is inherited from the ones proposed
+ by [RFC1940] and [RFC2460]. The source based routing model offers
+ the support for explicit routing capability.
+
+2.1. Data Planes supporting Segment Routing
+
+ Segment Routing (SR), can be instantiated over MPLS
+ ([I-D.ietf-spring-segment-routing-mpls]) and IPv6. This document
+ defines its instantiation over the IPv6 data-plane based on the use-
+ cases defined in [I-D.ietf-spring-ipv6-use-cases].
+
+ This document defines a new type of Routing Header (originally
+ defined in [RFC2460]) called the Segment Routing Header (SRH) in
+ order to convey the Segment List in the packet header as defined in
+ [I-D.ietf-spring-segment-routing]. Mechanisms through which segment
+ are known and advertised are outside the scope of this document.
+
+ A segment is materialized by an IPv6 address. A segment identifies a
+ topological instruction or a service instruction. A segment can be
+ either:
+
+ o global: a global segment represents an instruction supported by
+ all nodes in the SR domain and it is instantiated through an IPv6
+ address globally known in the SR domain.
+
+ o local: a local segment represents an instruction supported only by
+ the node who originates it and it is instantiated through an IPv6
+ address that is known only by the local node.
+
+2.2. Segment Routing (SR) Domain
+
+ We define the concept of the Segment Routing Domain (SR Domain) as
+ the set of nodes participating into the source based routing model.
+ These nodes may be connected to the same physical infrastructure
+ (e.g.: a Service Provider's network) as well as nodes remotely
+ connected to each other (e.g.: an enterprise VPN or an overlay).
+
+ A non-exhaustive list of examples of SR Domains is:
+
+ o The network of an operator, service provider, content provider,
+ enterprise including nodes, links and Autonomous Systems.
+
+
+
+
+
+Previdi, et al. Expires August 5, 2017 [Page 4]
+
+Internet-Draft IPv6 Segment Routing Header (SRH) February 2017
+
+
+ o A set of nodes connected as an overlay over one or more transit
+ providers. The overlay nodes exchange SR-enabled traffic with
+ segments belonging solely to the overlay routers (the SR domain).
+ None of the segments in the SR-enabled packets exchanged by the
+ overlay belong to the transit networks
+
+ The source based routing model through its instantiation of the
+ Segment Routing Header (SRH) defined in this document equally applies
+ to all the above examples.
+
+ It is assumed in this document that the SRH is added to the packet by
+ its source, consistently with the source routing model defined in
+ [RFC2460]. For example:
+
+ o At the node originating the packet (host, server).
+
+ o At the ingress node of an SR domain where the ingress node
+ receives an IPv6 packet and encapsulates it into an outer IPv6
+ header followed by a Segment Routing header.
+
+2.2.1. SR Domain in a Service Provider Network
+
+ The following figure illustrates an SR domain consisting of an
+ operator's network infrastructure.
+
+ (-------------------------- Operator 1 -----------------------)
+ ( )
+ ( (-----AS 1-----) (-------AS 2-------) (----AS 3-------) )
+ ( ( ) ( ) ( ) )
+ A1--(--(--11---13--14-)--(-21---22---23--24-)--(-31---32---34--)--)--Z1
+ ( ( /|\ /|\ /| ) ( |\ /|\ /|\ /| ) ( |\ /|\ /| \ ) )
+ A2--(--(/ | \/ | \/ | ) ( | \/ | \/ | \/ | ) ( | \/ | \/ | \)--)--Z2
+ ( ( | /\ | /\ | ) ( | /\ | /\ | /\ | ) ( | /\ | /\ | ) )
+ ( ( |/ \|/ \| ) ( |/ \|/ \|/ \| ) ( |/ \|/ \| ) )
+ A3--(--(--15---17--18-)--(-25---26---27--28-)--(-35---36---38--)--)--Z3
+ ( ( ) ( ) ( ) )
+ ( (--------------) (------------------) (---------------) )
+ ( )
+ (-------------------------------------------------------------)
+
+ Figure 1: Service Provider SR Domain
+
+ Figure 1 describes an operator network including several ASes and
+ delivering connectivity between endpoints. In this scenario, Segment
+ Routing is used within the operator networks and across the ASes
+ boundaries (all being under the control of the same operator). In
+ 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
+
+
+
+Previdi, et al. Expires August 5, 2017 [Page 5]
+
+Internet-Draft IPv6 Segment Routing Header (SRH) February 2017
+
+
+ engineering, data-center traffic engineering as described in
+ [RFC7855], [I-D.ietf-spring-ipv6-use-cases] and
+ [I-D.ietf-spring-resiliency-use-cases].
+
+ Typically, an IPv6 packet received at ingress (i.e.: from outside the
+ SR domain), is classified according to network operator policies and
+ such classification results into an outer header with an SRH applied
+ to the incoming packet. The SRH contains the list of segment
+ 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
+ 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
+ domain.
+
+ The path may include intra-AS as well as inter-AS segments. It has
+ to be noted that all nodes within the SR domain are under control of
+ the same administration. When the packet reaches the egress point of
+ the SR domain, the outer header and its SRH are removed so that the
+ destination of the packet is unaware of the SR domain the packet has
+ traversed.
+
+ The outer header with the SRH is no different from any other
+ tunneling encapsulation mechanism and allows a network operator to
+ implement traffic engineering mechanisms so to efficiently steer
+ traffic across his infrastructure.
+
+2.2.2. SR Domain in a Overlay Network
+
+ The following figure illustrates an SR domain consisting of an
+ overlay network over multiple operator's networks.
+
+ (--Operator 1---) (-----Operator 2-----) (--Operator 3---)
+ ( ) ( ) ( )
+ A1--(--11---13--14--)--(--21---22---23--24--)--(-31---32---34--)--C1
+ ( /|\ /|\ /| ) ( |\ /|\ /|\ /| ) ( |\ /|\ /| \ )
+ A2--(/ | \/ | \/ | ) ( | \/ | \/ | \/ | ) ( | \/ | \/ | \)--C2
+ ( | /\ | /\ | ) ( | /\ | /\ | /\ | ) ( | /\ | /\ | )
+ ( |/ \|/ \| ) ( |/ \|/ \|/ \| ) ( |/ \|/ \| )
+ A3--(--15---17--18--)--(--25---26---27--28--)--(-35---36---38--)--C3
+ ( ) ( | | | ) ( )
+ (---------------) (--|----|---------|--) (---------------)
+ | | |
+ B1 B2 B3
+
+ Figure 2: Overlay SR Domain
+
+
+
+
+
+
+Previdi, et al. Expires August 5, 2017 [Page 6]
+
+Internet-Draft IPv6 Segment Routing Header (SRH) February 2017
+
+
+ Figure 2 describes an overlay consisting of nodes connected to three
+ different network operators and forming a single overlay network
+ where Segment routing packets are exchanged.
+
+ The overlay consists of nodes A1, A2, A3, B1, B2, B3, C1, C2 and C3.
+ These nodes are connected to their respective network operator and
+ form an overlay network.
+
+ Each node may originate packets with an SRH which contains, in the
+ segment list of the SRH or in the DA, segments identifying other
+ overlay nodes. This implies that packets with an SRH may traverse
+ operator's networks but, obviously, these SRHs cannot contain an
+ address/segment of the transit operators 1, 2 and 3. The SRH
+ originated by the overlay can only contain address/segment under the
+ administration of the overlay (e.g. address/segments supported by A1,
+ A2, A3, B1, B2, B3, C1,C2 or C3).
+
+ In this model, the operator network nodes are transit nodes and,
+ according to [RFC2460], MUST NOT inspect the routing extension header
+ since they are not the DA of the packet.
+
+ 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
+ it is also possible that an operator would filter out any packet
+ destined to an internal address and having an extension header in it.
+
+ This common practice does not impact the SR-enabled traffic between
+ the overlay nodes as the intermediate transit networks never see a
+ destination address belonging to their infrastructure. These SR-
+ enabled overlay packets will thus never be filtered by the transit
+ operators.
+
+ In all cases, transit packets (i.e.: packets whose DA is outside the
+ domain of the operator's network) will be forwarded accordingly
+ without introducing any security concern in the operator's network.
+ This is similar to tunneled packets.
+
+3. Segment Routing Extension Header (SRH)
+
+ A new type of the Routing Header (originally defined in [RFC2460]) is
+ defined: the Segment Routing Header (SRH) which has a new Routing
+ Type, (suggested value 4) to be assigned by IANA.
+
+ The Segment Routing Header (SRH) is defined as follows:
+
+
+
+
+
+
+
+Previdi, et al. Expires August 5, 2017 [Page 7]
+
+Internet-Draft IPv6 Segment Routing Header (SRH) February 2017
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Next Header | Hdr Ext Len | Routing Type | Segments Left |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | First Segment | Flags | RESERVED |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ | Segment List[0] (128 bits IPv6 address) |
+ | |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ | |
+ ...
+ | |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ | Segment List[n] (128 bits IPv6 address) |
+ | |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ // //
+ // Optional Type Length Value objects (variable) //
+ // //
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ where:
+
+ o Next Header: 8-bit selector. Identifies the type of header
+ immediately following the SRH.
+
+ o Hdr Ext Len: 8-bit unsigned integer, is the length of the SRH
+ header in 8-octet units, not including the first 8 octets.
+
+ o Routing Type: TBD, to be assigned by IANA (suggested value: 4).
+
+ o Segments Left. Defined in [RFC2460], it contains the index, in
+ the Segment List, of the next segment to inspect. Segments Left
+ is decremented at each segment.
+
+ o First Segment: contains the index, in the Segment List, of the
+ first segment of the path which is in fact the last element of the
+ Segment List.
+
+ o Flags: 8 bits of flags. Following flags are defined:
+
+
+
+
+Previdi, et al. Expires August 5, 2017 [Page 8]
+
+Internet-Draft IPv6 Segment Routing Header (SRH) February 2017
+
+
+ 0 1 2 3 4 5 6 7
+ +-+-+-+-+-+-+-+-+
+ |U|P|O|A|H| U |
+ +-+-+-+-+-+-+-+-+
+
+ U: Unused and for future use. SHOULD be unset on transmission
+ and MUST be ignored on receipt.
+
+ P-flag: Protected flag. Set when the packet has been rerouted
+ through FRR mechanism by an SR endpoint node.
+
+ O-flag: OAM flag. When set, it indicates that this packet is
+ an operations and management (OAM) packet.
+
+ A-flag: Alert flag. If present, it means important Type Length
+ Value (TLV) objects are present. See Section 3.1 for details
+ on TLVs objects.
+
+ H-flag: HMAC flag. If set, the HMAC TLV is present and is
+ encoded as the last TLV of the SRH. In other words, the last
+ 36 octets of the SRH represent the HMAC information. See
+ Section 3.1.5 for details on the HMAC TLV.
+
+ o RESERVED: SHOULD be unset on transmission and MUST be ignored on
+ receipt.
+
+ o Segment List[n]: 128 bit IPv6 addresses representing the nth
+ segment in the Segment List. The Segment List is encoded starting
+ from the last segment of the path. I.e., the first element of the
+ segment list (Segment List [0]) contains the last segment of the
+ path while the last segment of the Segment List (Segment List[n])
+ contains the first segment of the path. The index contained in
+ "Segments Left" identifies the current active segment.
+
+ o Type Length Value (TLV) are described in Section 3.1.
+
+3.1. SRH TLVs
+
+ This section defines TLVs of the Segment Routing Header.
+
+ Type Length Value (TLV) contain optional information that may be used
+ by the node identified in the DA of the packet. It has to be noted
+ that the information carried in the TLVs is not intended to be used
+ by the routing layer. Typically, TLVs carry information that is
+ consumed by other components (e.g.: OAM) than the routing function.
+
+ Each TLV has its own length, format and semantic. The code-point
+ allocated (by IANA) to each TLV defines both the format and the
+
+
+
+Previdi, et al. Expires August 5, 2017 [Page 9]
+
+Internet-Draft IPv6 Segment Routing Header (SRH) February 2017
+
+
+ semantic of the information carried in the TLV. Multiple TLVs may be
+ encoded in the same SRH.
+
+ The "Length" field of the TLV is primarily used to skip the TLV while
+ inspecting the SRH in case the node doesn't support or recognize the
+ TLV codepoint. The "Length" defines the TLV length in octets and not
+ including the "Type" and "Length" fields.
+
+ The primary scope of TLVs is to give the receiver of the packet
+ information related to the source routed path (e.g.: where the packet
+ entered in the SR domain and where it is expected to exit).
+
+ Additional TLVs may be defined in the future.
+
+3.1.1. Ingress Node TLV
+
+ The Ingress Node TLV is optional and identifies the node this packet
+ traversed when entered the SR domain. The Ingress Node TLV has
+ following format:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | RESERVED | Flags |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ | Ingress Node (16 octets) |
+ | |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ where:
+
+ o Type: to be assigned by IANA (suggested value 1).
+
+ o Length: 18.
+
+ o RESERVED: 8 bits. SHOULD be unset on transmission and MUST be
+ ignored on receipt.
+
+ o Flags: 8 bits. No flags are defined in this document.
+
+ o Ingress Node: 128 bits. Defines the node where the packet is
+ expected to enter the SR domain. In the encapsulation case
+ described in Section 2.2.1, this information corresponds to the SA
+ of the encapsulating header.
+
+
+
+
+
+Previdi, et al. Expires August 5, 2017 [Page 10]
+
+Internet-Draft IPv6 Segment Routing Header (SRH) February 2017
+
+
+3.1.2. Egress Node TLV
+
+ The Egress Node TLV is optional and identifies the node this packet
+ is expected to traverse when exiting the SR domain. The Egress Node
+ TLV has following format:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | RESERVED | Flags |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ | Egress Node (16 octets) |
+ | |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ where:
+
+ o Type: to be assigned by IANA (suggested value 2).
+
+ o Length: 18.
+
+ o RESERVED: 8 bits. SHOULD be unset on transmission and MUST be
+ ignored on receipt.
+
+ o Flags: 8 bits. No flags are defined in this document.
+
+ o Egress Node: 128 bits. Defines the node where the packet is
+ expected to exit the SR domain. In the encapsulation case
+ described in Section 2.2.1, this information corresponds to the
+ last segment of the SRH in the encapsulating header.
+
+3.1.3. Opaque Container TLV
+
+ The Opaque Container TLV is optional and has the following format:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Previdi, et al. Expires August 5, 2017 [Page 11]
+
+Internet-Draft IPv6 Segment Routing Header (SRH) February 2017
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | RESERVED | Flags |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ | Opaque Container (16 octets) |
+ | |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ where:
+
+ o Type: to be assigned by IANA (suggested value 3).
+
+ o Length: 18.
+
+ o RESERVED: 8 bits. SHOULD be unset on transmission and MUST be
+ ignored on receipt.
+
+ o Flags: 8 bits. No flags are defined in this document.
+
+ o Opaque Container: 128 bits of opaque data not relevant for the
+ routing layer. Typically, this information is consumed by a non-
+ routing component of the node receiving the packet (i.e.: the node
+ in the DA).
+
+3.1.4. Padding TLV
+
+ The Padding TLV is optional and with the purpose of aligning the SRH
+ on a 8 octet boundary. The Padding TLV has the following format:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Padding (variable) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ // Padding (variable) //
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ where:
+
+ o Type: to be assigned by IANA (suggested value 4).
+
+ o Length: 1 to 7
+
+
+
+
+
+
+Previdi, et al. Expires August 5, 2017 [Page 12]
+
+Internet-Draft IPv6 Segment Routing Header (SRH) February 2017
+
+
+ o Padding: from 1 to 7 octets of padding. Padding bits have no
+ semantic. They SHOULD be set to 0 on transmission and MUST be
+ ignored on receipt.
+
+ The following applies to the Padding TLV:
+
+ o Padding TLV is optional and MAY only appear once in the SRH. If
+ present, it MUST have a length between 1 and 7 octets.
+
+ o The Padding TLV is used in order to align the SRH total length on
+ the 8 octet boundary.
+
+ o When present, the Padding TLV MUST appear as the last TLV before
+ the HMAC TLV (if HMAC TLV is present).
+
+ o When present, the Padding TLV MUST have a length from 1 to 7 in
+ order to align the SRH total lenght on a 8-octet boundary.
+
+ o When a router inspecting the SRH encounters the Padding TLV, it
+ MUST assume that no other TLV (other than the HMAC) follow the
+ Padding TLV.
+
+3.1.5. HMAC TLV
+
+ HMAC TLV is optional and contains the HMAC information. The HMAC TLV
+ has the following format:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | RESERVED |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | HMAC Key ID (4 octets) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | //
+ | HMAC (32 octets) //
+ | //
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ where:
+
+ o Type: to be assigned by IANA (suggested value 5).
+
+ o Length: 38.
+
+ o RESERVED: 2 octets. SHOULD be unset on transmission and MUST be
+ ignored on receipt.
+
+
+
+
+Previdi, et al. Expires August 5, 2017 [Page 13]
+
+Internet-Draft IPv6 Segment Routing Header (SRH) February 2017
+
+
+ o HMAC Key ID: 4 octets.
+
+ o HMAC: 32 octets.
+
+ o HMAC and HMAC Key ID usage is described in Section 5
+
+ The Following applies to the HMAC TLV:
+
+ o When present, the HMAC TLV MUST be encoded as the last TLV of the
+ SRH.
+
+ o If the HMAC TLV is present, the SRH H-Flag (Figure 4) MUST be set.
+
+ o When the H-flag is set in the SRH, the router inspecting the SRH
+ MUST find the HMAC TLV in the last 38 octets of the SRH.
+
+3.2. SRH and RFC2460 behavior
+
+ The SRH being a new type of the Routing Header, it also has the same
+ properties:
+
+ SHOULD only appear once in the packet.
+
+ Only the router whose address is in the DA field of the packet
+ header MUST inspect the SRH.
+
+ Therefore, Segment Routing in IPv6 networks implies that the segment
+ identifier (i.e.: the IPv6 address of the segment) is moved into the
+ DA of the packet.
+
+ The DA of the packet changes at each segment termination/completion
+ and therefore the final DA of the packet MUST be encoded as the last
+ segment of the path.
+
+4. SRH Procedures
+
+ In this section we describe the different procedures on the SRH.
+
+4.1. Source SR Node
+
+ A Source SR Node can be any node originating an IPv6 packet with its
+ IPv6 and Segment Routing Headers. This include either:
+
+ A host originating an IPv6 packet.
+
+ An SR domain ingress router encapsulating a received IPv6 packet
+ into an outer IPv6 header followed by an SRH.
+
+
+
+
+Previdi, et al. Expires August 5, 2017 [Page 14]
+
+Internet-Draft IPv6 Segment Routing Header (SRH) February 2017
+
+
+ The mechanism through which a Segment List is derived is outside of
+ the scope of this document. As an example, the Segment List may be
+ obtained through:
+
+ Local path computation.
+
+ Local configuration.
+
+ Interaction with a centralized controller delivering the path.
+
+ Any other mechanism.
+
+ The following are the steps of the creation of the SRH:
+
+ Next Header and Hdr Ext Len fields are set according to [RFC2460].
+
+ Routing Type field is set as TBD (to be allocated by IANA,
+ suggested value 4).
+
+ The Segment List is built with the FIRST segment of the path
+ encoded in the LAST element of the Segment List. Subsequent
+ segments are encoded on top of the first segment. Finally, the
+ LAST segment of the path is encoded in the FIRST element of the
+ Segment List. In other words, the Segment List is encoded in the
+ reverse order of the path.
+
+ The final DA of the packet is encoded as the last segment of the
+ path (encoded in the first element of the Segment List).
+
+ The DA of the packet is set with the value of the first segment
+ (found in the last element of the segment list).
+
+ The Segments Left field is set to n-1 where n is the number of
+ elements in the Segment List.
+
+ The First Segment field is set to n-1 where n is the number of
+ elements in the Segment List.
+
+ The packet is sent out towards the first segment (i.e.:
+ represented in the packet DA).
+
+ HMAC TLV may be set according to Section 5.
+
+4.2. Transit Node
+
+ According to [RFC2460], the only node who is allowed to inspect the
+ Routing Extension Header (and therefore the SRH), is the node
+ corresponding to the DA of the packet. Any other transit node MUST
+
+
+
+Previdi, et al. Expires August 5, 2017 [Page 15]
+
+Internet-Draft IPv6 Segment Routing Header (SRH) February 2017
+
+
+ NOT inspect the underneath routing header and MUST forward the packet
+ towards the DA and according to the IPv6 routing table.
+
+ In the example case described in Section 2.2.2, when SR capable nodes
+ are connected through an overlay spanning multiple third-party
+ infrastructure, it is safe to send SRH packets (i.e.: packet having a
+ Segment Routing Header) between each other overlay/SR-capable nodes
+ as long as the segment list does not include any of the transit
+ provider nodes. In addition, as a generic security measure, any
+ service provider will block any packet destined to one of its
+ internal routers, especially if these packets have an extended header
+ in it.
+
+4.3. SR Segment Endpoint Node
+
+ The SR segment endpoint node is the node whose address is in the DA.
+ The segment endpoint node inspects the SRH and does:
+
+ 1. IF DA = myself (segment endpoint)
+ 2. IF Segments Left > 0 THEN
+ decrement Segments Left
+ update DA with Segment List[Segments Left]
+ 3. ELSE continue IPv6 processing of the packet
+ End of processing.
+ 4. Forward the packet out
+
+5. Security Considerations
+
+ 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 RFC 2460 [RFC2460] 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 RFC 2460 [RFC2460].
+
+ Per RFC2460 [RFC2460], 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
+ one interface IPv6 address equals the destination address field of
+ the IPv6 packet MUST parse the SRH and, if supported and if the local
+ configuration allows it, MUST act accordingly to the SRH content.
+
+
+
+
+Previdi, et al. Expires August 5, 2017 [Page 16]
+
+Internet-Draft IPv6 Segment Routing Header (SRH) February 2017
+
+
+ According to RFC2460 [RFC2460], 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.
+
+5.1. Threat model
+
+5.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 [RFC4942] section
+ 2.1.1 and RFC5095 [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).
+
+5.1.2. Applicability of RFC 5095 to SRH
+
+ First of all, the reader must remember this specific part of section
+ 1 of RFC5095 [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,
+ RFC 6554 (RPL) [RFC6554] 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):
+
+
+
+
+
+Previdi, et al. Expires August 5, 2017 [Page 17]
+
+Internet-Draft IPv6 Segment Routing Header (SRH) February 2017
+
+
+ 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 [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 RFC 5095 [RFC5095] attacks are
+ not applicable.
+
+5.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'.
+
+5.1.4. Topology disclosure
+
+ The SRH may also contains IPv6 addresses 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 path, then there is little learned by
+ intercepting the SRH itself.
+
+5.1.5. ICMP Generation
+
+ Per section 4.4 of RFC2460 [RFC2460], 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:
+
+
+
+Previdi, et al. Expires August 5, 2017 [Page 18]
+
+Internet-Draft IPv6 Segment Routing Header (SRH) February 2017
+
+
+ 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 set to 0) destined to a node not
+ supporting SRH. Per RFC2460 [RFC2460], 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.
+
+5.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
+ 0).
+
+ 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
+ the text which consists of the concatenation of:
+
+ o the source IPv6 address;
+
+ o First Segment field;
+
+ o an octet of bit flags;
+
+ o HMAC Key-id;
+
+ o all addresses in the Segment List.
+
+
+
+
+Previdi, et al. Expires August 5, 2017 [Page 19]
+
+Internet-Draft IPv6 Segment Routing Header (SRH) February 2017
+
+
+ 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
+ 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
+ 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
+ router on the ingress of the SR domain needs to process it, then all
+ other SR nodes can ignore it (based on local policy) because they
+ 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
+ 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
+ turbo-QoS for a 1-hour period) where the DA, Segment ID (SID) are
+ identical, then it is important to refresh the shared-secret
+ frequently as the HMAC validity period expires only when the HMAC
+ Key-id and its associated shared-secret expires.
+
+5.2.1. Selecting a hash algorithm
+
+ The HMAC field in the HMAC TLV is 256 bit wide. Therefore, the HMAC
+ MUST be based on a hash function whose output is at least 256 bits.
+ If the output of the hash function is 256, then this output is simply
+ 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
+ implement SHA-2 [FIPS180-4] in its SHA-256 variant.
+
+ NOTE: SHA-1 is currently used by some early implementations used for
+ quick interoperations testing, the 160-bit hash value must then be
+
+
+
+
+Previdi, et al. Expires August 5, 2017 [Page 20]
+
+Internet-Draft IPv6 Segment Routing Header (SRH) February 2017
+
+
+ right-hand padded with 96 bits set to 0. The authors understand that
+ this is not secure but is ok for limited tests.
+
+5.2.2. Performance impact of HMAC
+
+ While adding an HMAC to each and every SR packet increases the
+ security, it has a performance impact. Nevertheless, it must be
+ noted that:
+
+ o the HMAC field is used only when SRH is added by a device (such as
+ a home set-up 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 MUST only be checked and validated by
+ the first router of the segment routing domain, this router is
+ named 'validating SR router'. Downstream routers may not inspect
+ the HMAC field.
+
+ o this validating router can also have a cache of <IPv6 header +
+ SRH, HMAC field value> to improve the performance. It is not the
+ same use case as in IPsec where HMAC value was unique per packet,
+ in SRH, the HMAC value is unique per flow.
+
+ o Last point, hash functions such as SHA-2 have been optimized for
+ security and performance and there are multiple implementations
+ with good performance.
+
+ With the above points in mind, the performance impact of using HMAC
+ is minimized.
+
+5.2.3. Pre-shared key management
+
+ The field HMAC Key-id allows for:
+
+ o key roll-over: when there is a need to change the key (the hash
+ pre-shared secret), then multiple pre-shared keys can be used
+ simultaneously. The validating routing can have a table of <HMAC
+ Key-id, pre-shared secret> for the currently active and future
+ keys.
+
+ o different algorithms: by extending the previous table to <HMAC
+ Key-id, hash function, pre-shared secret>, the validating router
+ can also support simultaneously several hash algorithms (see
+ section Section 5.2.1)
+
+ The pre-shared secret distribution can be done:
+
+
+
+Previdi, et al. Expires August 5, 2017 [Page 21]
+
+Internet-Draft IPv6 Segment Routing Header (SRH) February 2017
+
+
+ o in the configuration of the validating routers, either by static
+ configuration or any SDN oriented approach;
+
+ o dynamically using a trusted key distribution such as [RFC6407]
+
+ The intent of this document is NOT to define yet-another-key-
+ distribution-protocol.
+
+5.3. Deployment Models
+
+5.3.1. Nodes within the SR domain
+
+ An SR domain is defined as a set of interconnected routers where all
+ routers at the perimeter are configured to add and act on SRH. Some
+ routers inside the SR domain can also act on SRH or simply forward
+ IPv6 packets.
+
+ The routers inside an SR domain can be trusted to generate SRH and to
+ process SRH received on interfaces that are part of the SR domain.
+ These nodes MUST drop all SRH packets received on an interface that
+ is not part of the SR domain and containing an SRH whose HMAC field
+ cannot be validated by local policies. This includes obviously
+ packet with an SRH generated by a non-cooperative SR domain.
+
+ If the validation fails, then these packets MUST be dropped, ICMP
+ error messages (parameter problem) SHOULD be generated (but rate
+ limited) and SHOULD be logged.
+
+5.3.2. Nodes outside of the SR domain
+
+ Nodes outside of the SR domain cannot be trusted for physical
+ security; hence, they need to request by some trusted means (outside
+ of the scope of this document) a complete SRH for each new connection
+ (i.e. new destination address). The received SRH MUST include an
+ HMAC TLV which is computed correctly (see Section 5.2).
+
+ When an outside node sends a packet with an SRH and towards an SR
+ domain ingress node, the packet MUST contain the HMAC TLV (with a
+ Key-id and HMAC fields) and the the destination address MUST be an
+ address of an SR domain ingress node .
+
+ The ingress SR router, i.e., the router with an interface address
+ equals to the destination address, MUST verify the HMAC TLV.
+
+ If the validation is successful, then the packet is simply forwarded
+ as usual for an SR packet. As long as the packet travels within the
+ SR domain, no further HMAC check needs to be done. Subsequent
+
+
+
+
+Previdi, et al. Expires August 5, 2017 [Page 22]
+
+Internet-Draft IPv6 Segment Routing Header (SRH) February 2017
+
+
+ routers in the SR domain MAY verify the HMAC TLV when they process
+ the SRH (i.e. when they are the destination).
+
+ If the validation fails, then this packet MUST be dropped, an ICMP
+ error message (parameter problem) SHOULD be generated (but rate
+ limited) and SHOULD be logged.
+
+5.3.3. SR path exposure
+
+ As the intermediate SR nodes addresses appears in the SRH, if this
+ SRH is visible to an outsider then he/she could reuse this knowledge
+ to launch an attack on the intermediate SR nodes or get some insider
+ knowledge on the topology. This is especially applicable when the
+ path between the source node and the first SR domain ingress router
+ is on the public Internet.
+
+ The first remark is to state that 'security by obscurity' is never
+ enough; in other words, the security policy of the SR domain MUST
+ assume that the internal topology and addressing is known by the
+ attacker. A simple traceroute will also give the same information
+ (with even more information as all intermediate nodes between SID
+ will also be exposed). IPsec Encapsulating Security Payload
+ [RFC4303] cannot be use to protect the SRH as per RFC4303 the ESP
+ header must appear after any routing header (including SRH).
+
+ To prevent a user to leverage the gained knowledge by intercepting
+ SRH, it it recommended to apply an infrastructure Access Control List
+ (iACL) at the edge of the SR domain. This iACL will drop all packets
+ from outside the SR-domain whose destination is any address of any
+ router inside the domain. This security policy should be tuned for
+ local operations.
+
+5.3.4. Impact of BCP-38
+
+ BCP-38 [RFC2827], also known as "Network Ingress Filtering", checks
+ 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, then SR packets could be received by an interface
+ which is not expected one and the packets could be dropped.
+
+ As an SR domain is usually a subset of one administrative domain, and
+ as BCP-38 is only deployed at the ingress routers of this
+ administrative domain and as packets arriving at those ingress
+ routers have been normally forwarded using the normal routing
+ information, then there is no reason why this ingress router should
+
+
+
+
+Previdi, et al. Expires August 5, 2017 [Page 23]
+
+Internet-Draft IPv6 Segment Routing Header (SRH) February 2017
+
+
+ drop the SRH packet based on BCP-38. Routers inside the domain
+ commonly do not apply BCP-38; so, this is not a problem.
+
+6. IANA Considerations
+
+ This document makes the following registrations in the Internet
+ Protocol Version 6 (IPv6) Parameters "Routing Type" registry
+ maintained by IANA:
+
+ Suggested Description Reference
+ Value
+ ----------------------------------------------------------
+ 4 Segment Routing Header (SRH) This document
+
+ In addition, this document request IANA to create and maintain a new
+ Registry: "Segment Routing Header Type-Value Objects". The following
+ code-points are requested from the registry:
+
+ Registry: Segment Routing Header Type-Value Objects
+
+ Suggested Description Reference
+ Value
+ -----------------------------------------------------
+ 1 Ingress Node TLV This document
+ 2 Egress Node TLV This document
+ 3 Opaque Container TLV This document
+ 4 Padding TLV This document
+ 5 HMAC TLV This document
+
+7. Manageability Considerations
+
+ TBD
+
+8. Contributors
+
+ Dave Barach, John Leddy, John Brzozowski, Pierre Francois, Nagendra
+ Kumar, Mark Townsley, Christian Martin, Roberta Maglione, James
+ Connolly, Aloys Augustin contributed to the content of this document.
+
+9. Acknowledgements
+
+ The authors would like to thank Ole Troan, Bob Hinden, Fred Baker,
+ Brian Carpenter, Alexandru Petrescu and Punit Kumar Jaiswal for their
+ comments to this document.
+
+
+
+
+
+
+
+Previdi, et al. Expires August 5, 2017 [Page 24]
+
+Internet-Draft IPv6 Segment Routing Header (SRH) February 2017
+
+
+10. References
+
+10.1. Normative References
+
+ [FIPS180-4]
+ National Institute of Standards and Technology, "FIPS
+ 180-4 Secure Hash Standard (SHS)", March 2012,
+ <http://csrc.nist.gov/publications/fips/fips180-4/
+ fips-180-4.pdf>.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
+ December 1998, <http://www.rfc-editor.org/info/rfc2460>.
+
+ [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
+ RFC 4303, DOI 10.17487/RFC4303, December 2005,
+ <http://www.rfc-editor.org/info/rfc4303>.
+
+ [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
+ of Type 0 Routing Headers in IPv6", RFC 5095,
+ DOI 10.17487/RFC5095, December 2007,
+ <http://www.rfc-editor.org/info/rfc5095>.
+
+ [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain
+ of Interpretation", RFC 6407, DOI 10.17487/RFC6407,
+ October 2011, <http://www.rfc-editor.org/info/rfc6407>.
+
+10.2. Informative References
+
+ [I-D.ietf-isis-segment-routing-extensions]
+ Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,
+ Litkowski, S., Decraene, B., and j. jefftant@gmail.com,
+ "IS-IS Extensions for Segment Routing", draft-ietf-isis-
+ segment-routing-extensions-09 (work in progress), October
+ 2016.
+
+ [I-D.ietf-ospf-ospfv3-segment-routing-extensions]
+ Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
+ Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3
+ Extensions for Segment Routing", draft-ietf-ospf-ospfv3-
+ segment-routing-extensions-07 (work in progress), October
+ 2016.
+
+
+
+
+Previdi, et al. Expires August 5, 2017 [Page 25]
+
+Internet-Draft IPv6 Segment Routing Header (SRH) February 2017
+
+
+ [I-D.ietf-spring-ipv6-use-cases]
+ Brzozowski, J., Leddy, J., Townsley, W., Filsfils, C., and
+ R. Maglione, "IPv6 SPRING Use Cases", draft-ietf-spring-
+ ipv6-use-cases-08 (work in progress), January 2017.
+
+ [I-D.ietf-spring-resiliency-use-cases]
+ Filsfils, C., Previdi, S., Decraene, B., and R. Shakir,
+ "Resiliency use cases in SPRING networks", draft-ietf-
+ spring-resiliency-use-cases-08 (work in progress), October
+ 2016.
+
+ [I-D.ietf-spring-segment-routing]
+ Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
+ and R. Shakir, "Segment Routing Architecture", draft-ietf-
+ spring-segment-routing-10 (work in progress), November
+ 2016.
+
+ [I-D.ietf-spring-segment-routing-mpls]
+ Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
+ Litkowski, S., Horneffer, M., Shakir, R.,
+ jefftant@gmail.com, j., and E. Crabbe, "Segment Routing
+ with MPLS data plane", draft-ietf-spring-segment-routing-
+ mpls-06 (work in progress), January 2017.
+
+ [RFC1940] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D.
+ Zappala, "Source Demand Routing: Packet Format and
+ Forwarding Specification (Version 1)", RFC 1940,
+ DOI 10.17487/RFC1940, May 1996,
+ <http://www.rfc-editor.org/info/rfc1940>.
+
+ [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
+ Hashing for Message Authentication", RFC 2104,
+ DOI 10.17487/RFC2104, February 1997,
+ <http://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, <http://www.rfc-editor.org/info/rfc2827>.
+
+ [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/
+ Co-existence Security Considerations", RFC 4942,
+ DOI 10.17487/RFC4942, September 2007,
+ <http://www.rfc-editor.org/info/rfc4942>.
+
+
+
+
+
+
+
+Previdi, et al. Expires August 5, 2017 [Page 26]
+
+Internet-Draft IPv6 Segment Routing Header (SRH) February 2017
+
+
+ [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,
+ <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
+
+ Stefano Previdi (editor)
+ Cisco Systems, Inc.
+ Via Del Serafico, 200
+ Rome 00142
+ Italy
+
+ Email: sprevidi@cisco.com
+
+
+ Clarence Filsfils
+ Cisco Systems, Inc.
+ Brussels
+ BE
+
+ Email: cfilsfil@cisco.com
+
+
+ Brian Field
+ Comcast
+ 4100 East Dry Creek Road
+ Centennial, CO 80122
+ US
+
+ Email: Brian_Field@cable.comcast.com
+
+
+ Ida Leung
+ Rogers Communications
+ 8200 Dixie Road
+ Brampton, ON L6T 0C1
+ CA
+
+ Email: Ida.Leung@rci.rogers.com
+
+
+
+
+Previdi, et al. Expires August 5, 2017 [Page 27]
+
+Internet-Draft IPv6 Segment Routing Header (SRH) February 2017
+
+
+ Jen Linkova
+ Google
+ 1600 Amphitheatre Parkway
+ Mountain View, CA 94043
+ US
+
+ Email: furry@google.com
+
+
+ Ebben Aries
+ Facebook
+ US
+
+ Email: exa@fb.com
+
+
+ Tomoya Kosugi
+ NTT
+ 3-9-11, Midori-Cho Musashino-Shi,
+ Tokyo 180-8585
+ JP
+
+ Email: kosugi.tomoya@lab.ntt.co.jp
+
+
+ Eric Vyncke
+ Cisco Systems, Inc.
+ De Kleetlaann 6A
+ Diegem 1831
+ Belgium
+
+ Email: evyncke@cisco.com
+
+
+ David Lebrun
+ Universite Catholique de Louvain
+ Place Ste Barbe, 2
+ Louvain-la-Neuve, 1348
+ Belgium
+
+ Email: david.lebrun@uclouvain.be
+
+
+
+
+
+
+
+
+
+
+Previdi, et al. Expires August 5, 2017 [Page 28]
\ No newline at end of file
Code Review / vpp.git / blobdiff