| 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] |