idnits 2.17.00 (12 Aug 2021) /tmp/idnits42900/draft-ietf-6man-segment-routing-header-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 20, 2016) is 2069 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 414 -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180-4' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: draft-ietf-isis-segment-routing-extensions has been published as RFC 8667 == Outdated reference: draft-ietf-ospf-ospfv3-segment-routing-extensions has been published as RFC 8666 == Outdated reference: draft-ietf-spring-ipv6-use-cases has been published as RFC 8354 == Outdated reference: draft-ietf-spring-resiliency-use-cases has been published as RFC 8355 == Outdated reference: draft-ietf-spring-segment-routing has been published as RFC 8402 == Outdated reference: draft-ietf-spring-segment-routing-mpls has been published as RFC 8660 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Previdi, Ed. 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: March 24, 2017 B. Field 6 Comcast 7 I. Leung 8 Rogers Communications 9 J. Linkova 10 Google 11 E. Aries 12 Facebook 13 T. Kosugi 14 NTT 15 E. Vyncke 16 Cisco Systems, Inc. 17 D. Lebrun 18 Universite Catholique de Louvain 19 September 20, 2016 21 IPv6 Segment Routing Header (SRH) 22 draft-ietf-6man-segment-routing-header-02 24 Abstract 26 Segment Routing (SR) allows a node to steer a packet through a 27 controlled set of instructions, called segments, by prepending an SR 28 header to the packet. A segment can represent any instruction, 29 topological or service-based. SR allows to enforce a flow through 30 any path (topological, or application/service based) while 31 maintaining per-flow state only at the ingress node to the SR domain. 33 Segment Routing can be applied to the IPv6 data plane with the 34 addition of a new type of Routing Extension Header. This draft 35 describes the Segment Routing Extension Header Type and how it is 36 used by SR capable nodes. 38 Requirements Language 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 42 document are to be interpreted as described in RFC 2119 [RFC2119]. 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at http://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on March 24, 2017. 61 Copyright Notice 63 Copyright (c) 2016 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (http://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1. Segment Routing Documents . . . . . . . . . . . . . . . . . . 3 79 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 80 2.1. Data Planes supporting Segment Routing . . . . . . . . . 4 81 2.2. Segment Routing (SR) Domain . . . . . . . . . . . . . . . 4 82 2.2.1. SR Domain in a Service Provider Network . . . . . . . 5 83 2.2.2. SR Domain in a Overlay Network . . . . . . . . . . . 6 84 3. Segment Routing Extension Header (SRH) . . . . . . . . . . . 7 85 3.1. SRH TLVs . . . . . . . . . . . . . . . . . . . . . . . . 9 86 3.1.1. Ingress Node TLV . . . . . . . . . . . . . . . . . . 10 87 3.1.2. Egress Node TLV . . . . . . . . . . . . . . . . . . . 11 88 3.1.3. Opaque Container TLV . . . . . . . . . . . . . . . . 11 89 3.1.4. Padding TLV . . . . . . . . . . . . . . . . . . . . . 12 90 3.1.5. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . 13 91 3.2. SRH and RFC2460 behavior . . . . . . . . . . . . . . . . 14 92 4. SRH Procedures . . . . . . . . . . . . . . . . . . . . . . . 14 93 4.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 14 94 4.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 15 95 4.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 16 96 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 97 5.1. Threat model . . . . . . . . . . . . . . . . . . . . . . 17 98 5.1.1. Source routing threats . . . . . . . . . . . . . . . 17 99 5.1.2. Applicability of RFC 5095 to SRH . . . . . . . . . . 17 100 5.1.3. Service stealing threat . . . . . . . . . . . . . . . 18 101 5.1.4. Topology disclosure . . . . . . . . . . . . . . . . . 18 102 5.1.5. ICMP Generation . . . . . . . . . . . . . . . . . . . 19 103 5.2. Security fields in SRH . . . . . . . . . . . . . . . . . 19 104 5.2.1. Selecting a hash algorithm . . . . . . . . . . . . . 20 105 5.2.2. Performance impact of HMAC . . . . . . . . . . . . . 21 106 5.2.3. Pre-shared key management . . . . . . . . . . . . . . 21 107 5.3. Deployment Models . . . . . . . . . . . . . . . . . . . . 22 108 5.3.1. Nodes within the SR domain . . . . . . . . . . . . . 22 109 5.3.2. Nodes outside of the SR domain . . . . . . . . . . . 22 110 5.3.3. SR path exposure . . . . . . . . . . . . . . . . . . 23 111 5.3.4. Impact of BCP-38 . . . . . . . . . . . . . . . . . . 23 112 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 113 7. Manageability Considerations . . . . . . . . . . . . . . . . 24 114 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 115 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 116 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 117 10.1. Normative References . . . . . . . . . . . . . . . . . . 25 118 10.2. Informative References . . . . . . . . . . . . . . . . . 25 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 121 1. Segment Routing Documents 123 Segment Routing terminology is defined in 124 [I-D.ietf-spring-segment-routing]. 126 Segment Routing use cases are described in [RFC7855] and 127 [I-D.ietf-spring-ipv6-use-cases]. 129 Segment Routing protocol extensions are defined in 130 [I-D.ietf-isis-segment-routing-extensions], and 131 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 133 2. Introduction 135 Segment Routing (SR), defined in [I-D.ietf-spring-segment-routing], 136 allows a node to steer a packet through a controlled set of 137 instructions, called segments, by prepending an SR header to the 138 packet. A segment can represent any instruction, topological or 139 service-based. SR allows to enforce a flow through any path 140 (topological or service/application based) while maintaining per-flow 141 state only at the ingress node to the SR domain. Segments can be 142 derived from different components: IGP, BGP, Services, Contexts, 143 Locators, etc. The list of segment forming the path is called the 144 Segment List and is encoded in the packet header. 146 SR allows the use of strict and loose source based routing paradigms 147 without requiring any additional signaling protocols in the 148 infrastructure hence delivering an excellent scalability property. 150 The source based routing model described in 151 [I-D.ietf-spring-segment-routing] is inherited from the ones proposed 152 by [RFC1940] and [RFC2460]. The source based routing model offers 153 the support for explicit routing capability. 155 2.1. Data Planes supporting Segment Routing 157 Segment Routing (SR), can be instantiated over MPLS 158 ([I-D.ietf-spring-segment-routing-mpls]) and IPv6. This document 159 defines its instantiation over the IPv6 data-plane based on the use- 160 cases defined in [I-D.ietf-spring-ipv6-use-cases]. 162 This document defines a new type of Routing Header (originally 163 defined in [RFC2460]) called the Segment Routing Header (SRH) in 164 order to convey the Segment List in the packet header as defined in 165 [I-D.ietf-spring-segment-routing]. Mechanisms through which segment 166 are known and advertised are outside the scope of this document. 168 A segment is materialized by an IPv6 address. A segment identifies a 169 topological instruction or a service instruction. A segment can be 170 either: 172 o global: a global segment represents an instruction supported by 173 all nodes in the SR domain and it is instantiated through an IPv6 174 address globally known in the SR domain. 176 o local: a local segment represents an instruction supported only by 177 the node who originates it and it is instantiated through an IPv6 178 address that is known only by the local node. 180 2.2. Segment Routing (SR) Domain 182 We define the concept of the Segment Routing Domain (SR Domain) as 183 the set of nodes participating into the source based routing model. 184 These nodes may be connected to the same physical infrastructure 185 (e.g.: a Service Provider's network) as well as nodes remotely 186 connected to each other (e.g.: an enterprise VPN or an overlay). 188 A non-exhaustive list of examples of SR Domains is: 190 o The network of an operator, service provider, content provider, 191 enterprise including nodes, links and Autonomous Systems. 193 o A set of nodes connected as an overlay over one or more transit 194 providers. The overlay nodes exchange SR-enabled traffic with 195 segments belonging solely to the overlay routers (the SR domain). 196 None of the segments in the SR-enabled packets exchanged by the 197 overlay belong to the transit networks 199 The source based routing model through its instantiation of the 200 Segment Routing Header (SRH) defined in this document equally applies 201 to all the above examples. 203 While the source routing model defined in [RFC2460] doesn't mandate 204 which node is allowed to insert (or modify) the SRH, it is assumed in 205 this document that the SRH is inserted in the packet by its source. 206 For example: 208 o At the node originating the packet (host, server). 210 o At the ingress node of an SR domain where the ingress node 211 receives an IPv6 packet and encapsulates it into an outer IPv6 212 header followed by a Segment Routing header. 214 2.2.1. SR Domain in a Service Provider Network 216 The following figure illustrates an SR domain consisting of an 217 operator's network infrastructure. 219 (-------------------------- Operator 1 -----------------------) 220 ( ) 221 ( (-----AS 1-----) (-------AS 2-------) (----AS 3-------) ) 222 ( ( ) ( ) ( ) ) 223 A1--(--(--11---13--14-)--(-21---22---23--24-)--(-31---32---34--)--)--Z1 224 ( ( /|\ /|\ /| ) ( |\ /|\ /|\ /| ) ( |\ /|\ /| \ ) ) 225 A2--(--(/ | \/ | \/ | ) ( | \/ | \/ | \/ | ) ( | \/ | \/ | \)--)--Z2 226 ( ( | /\ | /\ | ) ( | /\ | /\ | /\ | ) ( | /\ | /\ | ) ) 227 ( ( |/ \|/ \| ) ( |/ \|/ \|/ \| ) ( |/ \|/ \| ) ) 228 A3--(--(--15---17--18-)--(-25---26---27--28-)--(-35---36---38--)--)--Z3 229 ( ( ) ( ) ( ) ) 230 ( (--------------) (------------------) (---------------) ) 231 ( ) 232 (-------------------------------------------------------------) 234 Figure 1: Service Provider SR Domain 236 Figure 1 describes an operator network including several ASes and 237 delivering connectivity between endpoints. In this scenario, Segment 238 Routing is used within the operator networks and across the ASes 239 boundaries (all being under the control of the same operator). In 240 this case segment routing can be used in order to address use cases 241 such as end-to-end traffic engineering, fast re-route, egress peer 242 engineering, data-center traffic engineering as described in 243 [RFC7855], [I-D.ietf-spring-ipv6-use-cases] and 244 [I-D.ietf-spring-resiliency-use-cases]. 246 Typically, an IPv6 packet received at ingress (i.e.: from outside the 247 SR domain), is classified according to network operator policies and 248 such classification results into an outer header with an SRH applied 249 to the incoming packet. The SRH contains the list of segment 250 representing the path the packet must take inside the SR domain. 251 Thus, the SA of the packet is the ingress node, the DA (due to SRH 252 procedures described in Section 4) is set as the first segment of the 253 path and the last segment of the path is the egress node of the SR 254 domain. 256 The path may include intra-AS as well as inter-AS segments. It has 257 to be noted that all nodes within the SR domain are under control of 258 the same administration. When the packet reaches the egress point of 259 the SR domain, the outer header and its SRH are removed so that the 260 destination of the packet is unaware of the SR domain the packet has 261 traversed. 263 The outer header with the SRH is no different from any other 264 tunneling encapsulation mechanism and allows a network operator to 265 implement traffic engineering mechanisms so to efficiently steer 266 traffic across his infrastructure. 268 2.2.2. SR Domain in a Overlay Network 270 The following figure illustrates an SR domain consisting of an 271 overlay network over multiple operator's networks. 273 (--Operator 1---) (-----Operator 2-----) (--Operator 3---) 274 ( ) ( ) ( ) 275 A1--(--11---13--14--)--(--21---22---23--24--)--(-31---32---34--)--C1 276 ( /|\ /|\ /| ) ( |\ /|\ /|\ /| ) ( |\ /|\ /| \ ) 277 A2--(/ | \/ | \/ | ) ( | \/ | \/ | \/ | ) ( | \/ | \/ | \)--C2 278 ( | /\ | /\ | ) ( | /\ | /\ | /\ | ) ( | /\ | /\ | ) 279 ( |/ \|/ \| ) ( |/ \|/ \|/ \| ) ( |/ \|/ \| ) 280 A3--(--15---17--18--)--(--25---26---27--28--)--(-35---36---38--)--C3 281 ( ) ( | | | ) ( ) 282 (---------------) (--|----|---------|--) (---------------) 283 | | | 284 B1 B2 B3 286 Figure 2: Overlay SR Domain 288 Figure 2 describes an overlay consisting of nodes connected to three 289 different network operators and forming a single overlay network 290 where Segment routing packets are exchanged. 292 The overlay consists of nodes A1, A2, A3, B1, B2, B3, C1, C2 and C3. 293 These nodes are connected to their respective network operator and 294 form an overlay network. 296 Each node may originate packets with an SRH which contains, in the 297 segment list of the SRH or in the DA, segments identifying other 298 overlay nodes. This implies that packets with an SRH may traverse 299 operator's networks but, obviously, these SRHs cannot contain an 300 address/segment of the transit operators 1, 2 and 3. The SRH 301 originated by the overlay can only contain address/segment under the 302 administration of the overlay (e.g. address/segments supported by A1, 303 A2, A3, B1, B2, B3, C1,C2 or C3). 305 In this model, the operator network nodes are transit nodes and, 306 according to [RFC2460], MUST NOT inspect the routing extension header 307 since they are not the DA of the packet. 309 It is a common practice in operators networks to filter out, at 310 ingress, any packet whose DA is the address of an internal node and 311 it is also possible that an operator would filter out any packet 312 destined to an internal address and having an extension header in it. 314 This common practice does not impact the SR-enabled traffic between 315 the overlay nodes as the intermediate transit networks never see a 316 destination address belonging to their infrastructure. These SR- 317 enabled overlay packets will thus never be filtered by the transit 318 operators. 320 In all cases, transit packets (i.e.: packets whose DA is outside the 321 domain of the operator's network) will be forwarded accordingly 322 without introducing any security concern in the operator's network. 323 This is similar to tunneled packets. 325 3. Segment Routing Extension Header (SRH) 327 A new type of the Routing Header (originally defined in [RFC2460]) is 328 defined: the Segment Routing Header (SRH) which has a new Routing 329 Type, (suggested value 4) to be assigned by IANA. 331 The Segment Routing Header (SRH) is defined as follows: 333 0 1 2 3 334 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 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | First Segment | Flags | RESERVED | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | | 341 | Segment List[0] (128 bits IPv6 address) | 342 | | 343 | | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | | 346 | | 347 ... 348 | | 349 | | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | | 352 | Segment List[n] (128 bits IPv6 address) | 353 | | 354 | | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 // // 357 // Optional Type Length Value objects (variable) // 358 // // 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 where: 363 o Next Header: 8-bit selector. Identifies the type of header 364 immediately following the SRH. 366 o Hdr Ext Len: 8-bit unsigned integer, is the length of the SRH 367 header in 8-octet units, not including the first 8 octets. 369 o Routing Type: TBD, to be assigned by IANA (suggested value: 4). 371 o Segments Left. Defined in [RFC2460], it contains the index, in 372 the Segment List, of the next segment to inspect. Segments Left 373 is decremented at each segment. 375 o First Segment: contains the index, in the Segment List, of the 376 first segment of the path which is in fact the last element of the 377 Segment List. 379 o Flags: 16 bits of flags. Following flags are defined: 381 1 382 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 |C|P|O|A|H| Unused | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 C-flag: Clean-up flag. Set when the SRH has to be removed from 388 the packet when the packet reaches the last segment. 390 P-flag: Protected flag. Set when the packet has been rerouted 391 through FRR mechanism by an SR endpoint node. 393 O-flag: OAM flag. When set, it indicates that this packet is 394 an operations and management (OAM) packet. 396 A-flag: Alert flag. If present, it means important Type Length 397 Value (TLV) objects are present. See Section 3.1 for details 398 on TLVs objects. 400 H-flag: HMAC flag. If set, the HMAC TLV is present and is 401 encoded as the last TLV of the SRH. In other words, the last 402 36 octets of the SRH represent the HMAC information. See 403 Section 3.1.5 for details on the HMAC TLV. 405 Unused: Reserved and for future use. SHOULD be unset on 406 transmission and MUST be ignored on receipt. 408 o RESERVED: SHOULD be unset on transmission and MUST be ignored on 409 receipt. 411 o Segment List[n]: 128 bit IPv6 addresses representing the nth 412 segment in the Segment List. The Segment List is encoded starting 413 from the last segment of the path. I.e., the first element of the 414 segment list (Segment List [0]) contains the last segment of the 415 path while the last segment of the Segment List (Segment List[n]) 416 contains the first segment of the path. The index contained in 417 "Segments Left" identifies the current active segment. 419 o Type Length Value (TLV) are described in Section 3.1. 421 3.1. SRH TLVs 423 This section defines TLVs of the Segment Routing Header. 425 Type Length Value (TLV) contain optional information that may be used 426 by the node identified in the DA of the packet. It has to be noted 427 that the information carried in the TLVs is not intended to be used 428 by the routing layer. Typically, TLVs carry information that is 429 consumed by other components (e.g.: OAM) than the routing function. 431 Each TLV has its own length, format and semantic. The code-point 432 allocated (by IANA) to each TLV defines both the format and the 433 semantic of the information carried in the TLV. Multiple TLVs may be 434 encoded in the same SRH. 436 The "Length" field of the TLV is primarily used to skip the TLV while 437 inspecting the SRH in case the node doesn't support or recognize the 438 TLV codepoint. The "Length" defines the TLV length in octets and not 439 including the "Type" and "Length" fields. 441 The primary scope of TLVs is to give the receiver of the packet 442 information related to the source routed path (e.g.: where the packet 443 entered in the SR domain and where it is expected to exit). 445 Additional TLVs may be defined in the future. 447 3.1.1. Ingress Node TLV 449 The Ingress Node TLV is optional and identifies the node this packet 450 traversed when entered the SR domain. The Ingress Node TLV has 451 following format: 453 0 1 2 3 454 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 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Type | Length | RESERVED | Flags | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | | 459 | Ingress Node (16 octets) | 460 | | 461 | | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 where: 466 o Type: to be assigned by IANA (suggested value 1). 468 o Length: 18. 470 o RESERVED: 8 bits. SHOULD be unset on transmission and MUST be 471 ignored on receipt. 473 o Flags: 8 bits. No flags are defined in this document. 475 o Ingress Node: 128 bits. Defines the node where the packet is 476 expected to enter the SR domain. In the encapsulation case 477 described in Section 2.2.1, this information corresponds to the SA 478 of the encapsulating header. 480 3.1.2. Egress Node TLV 482 The Egress Node TLV is optional and identifies the node this packet 483 is expected to traverse when exiting the SR domain. The Egress Node 484 TLV has following format: 486 0 1 2 3 487 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 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Type | Length | RESERVED | Flags | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | | 492 | Egress Node (16 octets) | 493 | | 494 | | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 where: 499 o Type: to be assigned by IANA (suggested value 2). 501 o Length: 18. 503 o RESERVED: 8 bits. SHOULD be unset on transmission and MUST be 504 ignored on receipt. 506 o Flags: 8 bits. No flags are defined in this document. 508 o Egress Node: 128 bits. Defines the node where the packet is 509 expected to exit the SR domain. In the encapsulation case 510 described in Section 2.2.1, this information corresponds to the 511 last segment of the SRH in the encapsulating header. 513 3.1.3. Opaque Container TLV 515 The Opaque Container TLV is optional and has the following format: 517 0 1 2 3 518 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 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Type | Length | RESERVED | Flags | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | | 523 | Opaque Container (16 octets) | 524 | | 525 | | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 where: 530 o Type: to be assigned by IANA (suggested value 3). 532 o Length: 18. 534 o RESERVED: 8 bits. SHOULD be unset on transmission and MUST be 535 ignored on receipt. 537 o Flags: 8 bits. No flags are defined in this document. 539 o Opaque Container: 128 bits of opaque data not relevant for the 540 routing layer. Typically, this information is consumed by a non- 541 routing component of the node receiving the packet (i.e.: the node 542 in the DA). 544 3.1.4. Padding TLV 546 The Padding TLV is optional and with the purpose of aligning the SRH 547 on a 8 octet boundary. The Padding TLV has the following format: 549 0 1 2 3 550 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 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | Type | Length | Padding (variable) | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 // Padding (variable) // 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 where: 559 o Type: to be assigned by IANA (suggested value 4). 561 o Length: 1 to 7 562 o Padding: from 1 to 7 octets of padding. Padding bits have no 563 semantic. They SHOULD be set to 0 on transmission and MUST be 564 ignored on receipt. 566 The following applies to the Padding TLV: 568 o Padding TLV is optional and MAY only appear once in the SRH. If 569 present, it MUST have a length between 1 and 7 octets. 571 o The Padding TLV is used in order to align the SRH total length on 572 the 8 octet boundary. 574 o When present, the Padding TLV MUST appear as the last TLV before 575 the HMAC TLV (if HMAC TLV is present). 577 o When present, the Padding TLV MUST have a length from 1 to 7 in 578 order to align the SRH total lenght on a 8-octet boundary. 580 o When a router inspecting the SRH encounters the Padding TLV, it 581 MUST assume that no other TLV (other than the HMAC) follow the 582 Padding TLV. 584 3.1.5. HMAC TLV 586 HMAC TLV is optional and contains the HMAC information. The HMAC TLV 587 has the following format: 589 0 1 2 3 590 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 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Type | Length | RESERVED | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | HMAC Key ID (4 octets) | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | // 597 | HMAC (32 octets) // 598 | // 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 where: 603 o Type: to be assigned by IANA (suggested value 5). 605 o Length: 38. 607 o RESERVED: 2 octets. SHOULD be unset on transmission and MUST be 608 ignored on receipt. 610 o HMAC Key ID: 4 octets. 612 o HMAC: 32 octets. 614 o HMAC and HMAC Key ID usage is described in Section 5 616 The Following applies to the HMAC TLV: 618 o When present, the HMAC TLV MUST be encoded as the last TLV of the 619 SRH. 621 o If the HMAC TLV is present, the SRH H-Flag (Figure 4) MUST be set. 623 o When the H-flag is set in the SRH, the router inspecting the SRH 624 MUST find the HMAC TLV in the last 38 octets of the SRH. 626 3.2. SRH and RFC2460 behavior 628 The SRH being a new type of the Routing Header, it also has the same 629 properties: 631 SHOULD only appear once in the packet. 633 Only the router whose address is in the DA field of the packet 634 header MUST inspect the SRH. 636 Therefore, Segment Routing in IPv6 networks implies that the segment 637 identifier (i.e.: the IPv6 address of the segment) is moved into the 638 DA of the packet. 640 The DA of the packet changes at each segment termination/completion 641 and therefore the final DA of the packet MUST be encoded as the last 642 segment of the path. 644 4. SRH Procedures 646 In this section we describe the different procedures on the SRH. 648 4.1. Source SR Node 650 A Source SR Node can be any node originating an IPv6 packet with its 651 IPv6 and Segment Routing Headers. This include either: 653 A host originating an IPv6 packet. 655 An SR domain ingress router encapsulating a received IPv6 packet 656 into an outer IPv6 header followed by an SRH. 658 The mechanism through which a Segment List is derived is outside of 659 the scope of this document. As an example, the Segment List may be 660 obtained through: 662 Local path computation. 664 Local configuration. 666 Interaction with a centralized controller delivering the path. 668 Any other mechanism. 670 The following are the steps of the creation of the SRH: 672 Next Header and Hdr Ext Len fields are set according to [RFC2460]. 674 Routing Type field is set as TBD (to be allocated by IANA, 675 suggested value 4). 677 The Segment List is built with the FIRST segment of the path 678 encoded in the LAST element of the Segment List. Subsequent 679 segments are encoded on top of the first segment. Finally, the 680 LAST segment of the path is encoded in the FIRST element of the 681 Segment List. In other words, the Segment List is encoded in the 682 reverse order of the path. 684 The final DA of the packet is encoded as the last segment of the 685 path (encoded in the first element of the Segment List). 687 The DA of the packet is set with the value of the first segment 688 (found in the last element of the segment list). 690 The Segments Left field is set to n-1 where n is the number of 691 elements in the Segment List. 693 The First Segment field is set to n-1 where n is the number of 694 elements in the Segment List. 696 The packet is sent out towards the first segment (i.e.: 697 represented in the packet DA). 699 HMAC TLV may be set according to Section 5. 701 4.2. Transit Node 703 According to [RFC2460], the only node who is allowed to inspect the 704 Routing Extension Header (and therefore the SRH), is the node 705 corresponding to the DA of the packet. Any other transit node MUST 706 NOT inspect the underneath routing header and MUST forward the packet 707 towards the DA and according to the IPv6 routing table. 709 In the example case described in Section 2.2.2, when SR capable nodes 710 are connected through an overlay spanning multiple third-party 711 infrastructure, it is safe to send SRH packets (i.e.: packet having a 712 Segment Routing Header) between each other overlay/SR-capable nodes 713 as long as the segment list does not include any of the transit 714 provider nodes. In addition, as a generic security measure, any 715 service provider will block any packet destined to one of its 716 internal routers, especially if these packets have an extended header 717 in it. 719 4.3. SR Segment Endpoint Node 721 The SR segment endpoint node is the node whose address is in the DA. 722 The segment endpoint node inspects the SRH and does: 724 1. IF DA = myself (segment endpoint) 725 2. IF Segments Left > 0 THEN 726 decrement Segments Left 727 update DA with Segment List[Segments Left] 728 3. IF Segments Left == 0 THEN 729 IF Clean-up bit is set THEN remove the SRH 730 4. ELSE continue IPv6 processing of the packet 731 End of processing. 732 5. Forward the packet out 734 5. Security Considerations 736 This section analyzes the security threat model, the security issues 737 and proposed solutions related to the new Segment Routing Header. 739 The Segment Routing Header (SRH) is simply another type of the 740 routing header as described in RFC 2460 [RFC2460] and is: 742 o inserted by an SR edge router when entering the segment routing 743 domain or by the originating host itself. The source host can 744 even be outside the SR domain; 746 o inspected and acted upon when reaching the destination address of 747 the IP header per RFC 2460 [RFC2460]. 749 Per RFC2460 [RFC2460], routers on the path that simply forward an 750 IPv6 packet (i.e. the IPv6 destination address is none of theirs) 751 will never inspect and process the content of the SRH. Routers whose 752 one interface IPv6 address equals the destination address field of 753 the IPv6 packet MUST parse the SRH and, if supported and if the local 754 configuration allows it, MUST act accordingly to the SRH content. 756 According to RFC2460 [RFC2460], the default behavior of a non SR- 757 capable router upon receipt of an IPv6 packet with SRH destined to an 758 address of its, is to: 760 o ignore the SRH completely if the Segment Left field is 0 and 761 proceed to process the next header in the IPv6 packet; 763 o discard the IPv6 packet if Segment Left field is greater than 0, 764 it MAY send a Parameter Problem ICMP message back to the Source 765 Address. 767 5.1. Threat model 769 5.1.1. Source routing threats 771 Using an SRH is similar to source routing, therefore it has some 772 well-known security issues as described in RFC4942 [RFC4942] section 773 2.1.1 and RFC5095 [RFC5095]: 775 o amplification attacks: where a packet could be forged in such a 776 way to cause looping among a set of SR-enabled routers causing 777 unnecessary traffic, hence a Denial of Service (DoS) against 778 bandwidth; 780 o reflection attack: where a hacker could force an intermediate node 781 to appear as the immediate attacker, hence hiding the real 782 attacker from naive forensic; 784 o bypass attack: where an intermediate node could be used as a 785 stepping stone (for example in a De-Militarized Zone) to attack 786 another host (for example in the datacenter or any back-end 787 server). 789 5.1.2. Applicability of RFC 5095 to SRH 791 First of all, the reader must remember this specific part of section 792 1 of RFC5095 [RFC5095], "A side effect is that this also eliminates 793 benign RH0 use-cases; however, such applications may be facilitated 794 by future Routing Header specifications.". In short, it is not 795 forbidden to create new secure type of Routing Header; for example, 796 RFC 6554 (RPL) [RFC6554] also creates a new Routing Header type for a 797 specific application confined in a single network. 799 In the segment routing architecture described in 800 [I-D.ietf-spring-segment-routing] there are basically two kinds of 801 nodes (routers and hosts): 803 o nodes within the SR domain, which is within one single 804 administrative domain, i.e., where all nodes are trusted anyway 805 else the damage caused by those nodes could be worse than 806 amplification attacks: traffic interception, man-in-the-middle 807 attacks, more server DoS by dropping packets, and so on. 809 o nodes outside of the SR domain, which is outside of the 810 administrative segment routing domain hence they cannot be trusted 811 because there is no physical security for those nodes, i.e., they 812 can be replaced by hostile nodes or can be coerced in wrong 813 behaviors. 815 The main use case for SR consists of the single administrative domain 816 where only trusted nodes with SR enabled and configured participate 817 in SR: this is the same model as in RFC6554 [RFC6554]. All non- 818 trusted nodes do not participate as either SR processing is not 819 enabled by default or because they only process SRH from nodes within 820 their domain. 822 Moreover, all SR nodes ignore SRH created by outsiders based on 823 topology information (received on a peering or internal interface) or 824 on presence and validity of the HMAC field. Therefore, if 825 intermediate nodes ONLY act on valid and authorized SRH (such as 826 within a single administrative domain), then there is no security 827 threat similar to RH-0. Hence, the RFC 5095 [RFC5095] attacks are 828 not applicable. 830 5.1.3. Service stealing threat 832 Segment routing is used for added value services, there is also a 833 need to prevent non-participating nodes to use those services; this 834 is called 'service stealing prevention'. 836 5.1.4. Topology disclosure 838 The SRH may also contains IPv6 addresses of some intermediate SR- 839 nodes in the path towards the destination, this obviously reveals 840 those addresses to the potentially hostile attackers if those 841 attackers are able to intercept packets containing SRH. On the other 842 hand, if the attacker can do a traceroute whose probes will be 843 forwarded along the SR path, then there is little learned by 844 intercepting the SRH itself. Also the clean-bit of SRH can help by 845 removing the SRH before forwarding the packet to potentially a non- 846 trusted part of the network. 848 5.1.5. ICMP Generation 850 Per section 4.4 of RFC2460 [RFC2460], when destination nodes (i.e. 851 where the destination address is one of theirs) receive a Routing 852 Header with unsupported Routing Type, the required behavior is: 854 o If Segments Left is zero, the node must ignore the Routing header 855 and proceed to process the next header in the packet. 857 o If Segments Left is non-zero, the node must discard the packet and 858 send an ICMP Parameter Problem, Code 0, message to the packet's 859 Source Address, pointing to the unrecognized Routing Type. 861 This required behavior could be used by an attacker to force the 862 generation of ICMP message by any node. The attacker could send 863 packets with SRH (with Segment Left set to 0) destined to a node not 864 supporting SRH. Per RFC2460 [RFC2460], the destination node could 865 generate an ICMP message, causing a local CPU utilization and if the 866 source of the offending packet with SRH was spoofed could lead to a 867 reflection attack without any amplification. 869 It must be noted that this is a required behavior for any unsupported 870 Routing Type and not limited to SRH packets. So, it is not specific 871 to SRH and the usual rate limiting for ICMP generation is required 872 anyway for any IPv6 implementation and has been implemented and 873 deployed for many years. 875 5.2. Security fields in SRH 877 This section summarizes the use of specific fields in the SRH. They 878 are based on a key-hashed message authentication code (HMAC). 880 The security-related fields in the SRH are instantiated by the HMAC 881 TLV, containing: 883 o HMAC Key-id, 32 bits wide; 885 o HMAC, 256 bits wide (optional, exists only if HMAC Key-id is not 886 0). 888 The HMAC field is the output of the HMAC computation (per RFC 2104 889 [RFC2104]) using a pre-shared key identified by HMAC Key-id and of 890 the text which consists of the concatenation of: 892 o the source IPv6 address; 894 o First Segment field; 895 o an octet whose bit-0 is the clean-up bit flag and others are 0; 897 o HMAC Key-id; 899 o all addresses in the Segment List. 901 The purpose of the HMAC TLV is to verify the validity, the integrity 902 and the authorization of the SRH itself. If an outsider of the SR 903 domain does not have access to a current pre-shared secret, then it 904 cannot compute the right HMAC field and the first SR router on the 905 path processing the SRH and configured to check the validity of the 906 HMAC will simply reject the packet. 908 The HMAC TLV is located at the end of the SRH simply because only the 909 router on the ingress of the SR domain needs to process it, then all 910 other SR nodes can ignore it (based on local policy) because they 911 trust the upstream router. This is to speed up forwarding operations 912 because SR routers which do not validate the SRH do not need to parse 913 the SRH until the end. 915 The HMAC Key-id field allows for the simultaneous existence of 916 several hash algorithms (SHA-256, SHA3-256 ... or future ones) as 917 well as pre-shared keys. The HMAC Key-id field is opaque, i.e., it 918 has neither syntax nor semantic except as an index to the right 919 combination of pre-shared key and hash algorithm and except that a 920 value of 0 means that there is no HMAC field. Having an HMAC Key-id 921 field allows for pre-shared key roll-over when two pre-shared keys 922 are supported for a while when all SR nodes converged to a fresher 923 pre-shared key. It could also allow for interoperation among 924 different SR domains if allowed by local policy and assuming a 925 collision-free HMAC Key Id allocation. 927 When a specific SRH is linked to a time-related service (such as 928 turbo-QoS for a 1-hour period) where the DA, Segment ID (SID) are 929 identical, then it is important to refresh the shared-secret 930 frequently as the HMAC validity period expires only when the HMAC 931 Key-id and its associated shared-secret expires. 933 5.2.1. Selecting a hash algorithm 935 The HMAC field in the HMAC TLV is 256 bit wide. Therefore, the HMAC 936 MUST be based on a hash function whose output is at least 256 bits. 937 If the output of the hash function is 256, then this output is simply 938 inserted in the HMAC field. If the output of the hash function is 939 larger than 256 bits, then the output value is truncated to 256 by 940 taking the least-significant 256 bits and inserting them in the HMAC 941 field. 943 SRH implementations can support multiple hash functions but MUST 944 implement SHA-2 [FIPS180-4] in its SHA-256 variant. 946 NOTE: SHA-1 is currently used by some early implementations used for 947 quick interoperations testing, the 160-bit hash value must then be 948 right-hand padded with 96 bits set to 0. The authors understand that 949 this is not secure but is ok for limited tests. 951 5.2.2. Performance impact of HMAC 953 While adding an HMAC to each and every SR packet increases the 954 security, it has a performance impact. Nevertheless, it must be 955 noted that: 957 o the HMAC field is used only when SRH is inserted by a device (such 958 as a home set-up box) which is outside of the segment routing 959 domain. If the SRH is added by a router in the trusted segment 960 routing domain, then, there is no need for an HMAC field, hence no 961 performance impact. 963 o when present, the HMAC field MUST only be checked and validated by 964 the first router of the segment routing domain, this router is 965 named 'validating SR router'. Downstream routers may not inspect 966 the HMAC field. 968 o this validating router can also have a cache of to improve the performance. It is not the 970 same use case as in IPsec where HMAC value was unique per packet, 971 in SRH, the HMAC value is unique per flow. 973 o Last point, hash functions such as SHA-2 have been optimized for 974 security and performance and there are multiple implementations 975 with good performance. 977 With the above points in mind, the performance impact of using HMAC 978 is minimized. 980 5.2.3. Pre-shared key management 982 The field HMAC Key-id allows for: 984 o key roll-over: when there is a need to change the key (the hash 985 pre-shared secret), then multiple pre-shared keys can be used 986 simultaneously. The validating routing can have a table of for the currently active and future 988 keys. 990 o different algorithms: by extending the previous table to , the validating router 992 can also support simultaneously several hash algorithms (see 993 section Section 5.2.1) 995 The pre-shared secret distribution can be done: 997 o in the configuration of the validating routers, either by static 998 configuration or any SDN oriented approach; 1000 o dynamically using a trusted key distribution such as [RFC6407] 1002 The intent of this document is NOT to define yet-another-key- 1003 distribution-protocol. 1005 5.3. Deployment Models 1007 5.3.1. Nodes within the SR domain 1009 An SR domain is defined as a set of interconnected routers where all 1010 routers at the perimeter are configured to insert and act on SRH. 1011 Some routers inside the SR domain can also act on SRH or simply 1012 forward IPv6 packets. 1014 The routers inside an SR domain can be trusted to generate SRH and to 1015 process SRH received on interfaces that are part of the SR domain. 1016 These nodes MUST drop all SRH packets received on an interface that 1017 is not part of the SR domain and containing an SRH whose HMAC field 1018 cannot be validated by local policies. This includes obviously 1019 packet with an SRH generated by a non-cooperative SR domain. 1021 If the validation fails, then these packets MUST be dropped, ICMP 1022 error messages (parameter problem) SHOULD be generated (but rate 1023 limited) and SHOULD be logged. 1025 5.3.2. Nodes outside of the SR domain 1027 Nodes outside of the SR domain cannot be trusted for physical 1028 security; hence, they need to request by some trusted means (outside 1029 of the scope of this document) a complete SRH for each new connection 1030 (i.e. new destination address). The received SRH MUST include an 1031 HMAC TLV which is computed correctly (see Section 5.2). 1033 When an outside node sends a packet with an SRH and towards an SR 1034 domain ingress node, the packet MUST contain the HMAC TLV (with a 1035 Key-id and HMAC fields) and the the destination address MUST be an 1036 address of an SR domain ingress node . 1038 The ingress SR router, i.e., the router with an interface address 1039 equals to the destination address, MUST verify the HMAC TLV. 1041 If the validation is successful, then the packet is simply forwarded 1042 as usual for an SR packet. As long as the packet travels within the 1043 SR domain, no further HMAC check needs to be done. Subsequent 1044 routers in the SR domain MAY verify the HMAC TLV when they process 1045 the SRH (i.e. when they are the destination). 1047 If the validation fails, then this packet MUST be dropped, an ICMP 1048 error message (parameter problem) SHOULD be generated (but rate 1049 limited) and SHOULD be logged. 1051 5.3.3. SR path exposure 1053 As the intermediate SR nodes addresses appears in the SRH, if this 1054 SRH is visible to an outsider then he/she could reuse this knowledge 1055 to launch an attack on the intermediate SR nodes or get some insider 1056 knowledge on the topology. This is especially applicable when the 1057 path between the source node and the first SR domain ingress router 1058 is on the public Internet. 1060 The first remark is to state that 'security by obscurity' is never 1061 enough; in other words, the security policy of the SR domain MUST 1062 assume that the internal topology and addressing is known by the 1063 attacker. A simple traceroute will also give the same information 1064 (with even more information as all intermediate nodes between SID 1065 will also be exposed). IPsec Encapsulating Security Payload 1066 [RFC4303] cannot be use to protect the SRH as per RFC4303 the ESP 1067 header must appear after any routing header (including SRH). 1069 To prevent a user to leverage the gained knowledge by intercepting 1070 SRH, it it recommended to apply an infrastructure Access Control List 1071 (iACL) at the edge of the SR domain. This iACL will drop all packets 1072 from outside the SR-domain whose destination is any address of any 1073 router inside the domain. This security policy should be tuned for 1074 local operations. 1076 5.3.4. Impact of BCP-38 1078 BCP-38 [RFC2827], also known as "Network Ingress Filtering", checks 1079 whether the source address of packets received on an interface is 1080 valid for this interface. The use of loose source routing such as 1081 SRH forces packets to follow a path which differs from the expected 1082 routing. Therefore, if BCP-38 was implemented in all routers inside 1083 the SR domain, then SR packets could be received by an interface 1084 which is not expected one and the packets could be dropped. 1086 As an SR domain is usually a subset of one administrative domain, and 1087 as BCP-38 is only deployed at the ingress routers of this 1088 administrative domain and as packets arriving at those ingress 1089 routers have been normally forwarded using the normal routing 1090 information, then there is no reason why this ingress router should 1091 drop the SRH packet based on BCP-38. Routers inside the domain 1092 commonly do not apply BCP-38; so, this is not a problem. 1094 6. IANA Considerations 1096 This document makes the following registrations in the Internet 1097 Protocol Version 6 (IPv6) Parameters "Routing Type" registry 1098 maintained by IANA: 1100 Suggested Description Reference 1101 Value 1102 ---------------------------------------------------------- 1103 4 Segment Routing Header (SRH) This document 1105 In addition, this document request IANA to create and maintain a new 1106 Registry: "Segment Routing Header Type-Value Objects". The following 1107 code-points are requested from the registry: 1109 Registry: Segment Routing Header Type-Value Objects 1111 Suggested Description Reference 1112 Value 1113 ----------------------------------------------------- 1114 1 Ingress Node TLV This document 1115 2 Egress Node TLV This document 1116 3 Opaque Container TLV This document 1117 4 Padding TLV This document 1118 5 HMAC TLV This document 1120 7. Manageability Considerations 1122 TBD 1124 8. Contributors 1126 Dave Barach, John Leddy, John Brzozowski, Pierre Francois, Nagendra 1127 Kumar, Mark Townsley, Christian Martin, Roberta Maglione, James 1128 Connolly, Aloys Augustin contributed to the content of this document. 1130 9. Acknowledgements 1132 The authors would like to thank Ole Troan, Bob Hinden, Fred Baker, 1133 Brian Carpenter and Alexandru Petrescu for their comments to this 1134 document. 1136 10. References 1138 10.1. Normative References 1140 [FIPS180-4] 1141 National Institute of Standards and Technology, "FIPS 1142 180-4 Secure Hash Standard (SHS)", March 2012, 1143 . 1146 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1147 Requirement Levels", BCP 14, RFC 2119, 1148 DOI 10.17487/RFC2119, March 1997, 1149 . 1151 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1152 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1153 December 1998, . 1155 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1156 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1157 . 1159 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1160 of Type 0 Routing Headers in IPv6", RFC 5095, 1161 DOI 10.17487/RFC5095, December 2007, 1162 . 1164 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 1165 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 1166 October 2011, . 1168 10.2. Informative References 1170 [I-D.ietf-isis-segment-routing-extensions] 1171 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 1172 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 1173 Extensions for Segment Routing", draft-ietf-isis-segment- 1174 routing-extensions-07 (work in progress), June 2016. 1176 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 1177 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1178 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 1179 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 1180 segment-routing-extensions-06 (work in progress), July 1181 2016. 1183 [I-D.ietf-spring-ipv6-use-cases] 1184 Brzozowski, J., Leddy, J., Townsley, W., Filsfils, C., and 1185 R. Maglione, "IPv6 SPRING Use Cases", draft-ietf-spring- 1186 ipv6-use-cases-07 (work in progress), July 2016. 1188 [I-D.ietf-spring-resiliency-use-cases] 1189 Filsfils, C., Previdi, S., Francois, P., Decraene, B., and 1190 R. Shakir, "Use-cases for Resiliency in SPRING", draft- 1191 ietf-spring-resiliency-use-cases-05 (work in progress), 1192 September 2016. 1194 [I-D.ietf-spring-segment-routing] 1195 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 1196 and R. Shakir, "Segment Routing Architecture", draft-ietf- 1197 spring-segment-routing-09 (work in progress), July 2016. 1199 [I-D.ietf-spring-segment-routing-mpls] 1200 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1201 Litkowski, S., Horneffer, M., Shakir, R., 1202 jefftant@gmail.com, j., and E. Crabbe, "Segment Routing 1203 with MPLS data plane", draft-ietf-spring-segment-routing- 1204 mpls-05 (work in progress), July 2016. 1206 [RFC1940] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D. 1207 Zappala, "Source Demand Routing: Packet Format and 1208 Forwarding Specification (Version 1)", RFC 1940, 1209 DOI 10.17487/RFC1940, May 1996, 1210 . 1212 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1213 Hashing for Message Authentication", RFC 2104, 1214 DOI 10.17487/RFC2104, February 1997, 1215 . 1217 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1218 Defeating Denial of Service Attacks which employ IP Source 1219 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1220 May 2000, . 1222 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 1223 Co-existence Security Considerations", RFC 4942, 1224 DOI 10.17487/RFC4942, September 2007, 1225 . 1227 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 1228 Routing Header for Source Routes with the Routing Protocol 1229 for Low-Power and Lossy Networks (RPL)", RFC 6554, 1230 DOI 10.17487/RFC6554, March 2012, 1231 . 1233 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 1234 Litkowski, S., Horneffer, M., and R. Shakir, "Source 1235 Packet Routing in Networking (SPRING) Problem Statement 1236 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 1237 2016, . 1239 Authors' Addresses 1241 Stefano Previdi (editor) 1242 Cisco Systems, Inc. 1243 Via Del Serafico, 200 1244 Rome 00142 1245 Italy 1247 Email: sprevidi@cisco.com 1249 Clarence Filsfils 1250 Cisco Systems, Inc. 1251 Brussels 1252 BE 1254 Email: cfilsfil@cisco.com 1256 Brian Field 1257 Comcast 1258 4100 East Dry Creek Road 1259 Centennial, CO 80122 1260 US 1262 Email: Brian_Field@cable.comcast.com 1263 Ida Leung 1264 Rogers Communications 1265 8200 Dixie Road 1266 Brampton, ON L6T 0C1 1267 CA 1269 Email: Ida.Leung@rci.rogers.com 1271 Jen Linkova 1272 Google 1273 1600 Amphitheatre Parkway 1274 Mountain View, CA 94043 1275 US 1277 Email: furry@google.com 1279 Ebben Aries 1280 Facebook 1281 US 1283 Email: exa@fb.com 1285 Tomoya Kosugi 1286 NTT 1287 3-9-11, Midori-Cho Musashino-Shi, 1288 Tokyo 180-8585 1289 JP 1291 Email: kosugi.tomoya@lab.ntt.co.jp 1293 Eric Vyncke 1294 Cisco Systems, Inc. 1295 De Kleetlaann 6A 1296 Diegem 1831 1297 Belgium 1299 Email: evyncke@cisco.com 1300 David Lebrun 1301 Universite Catholique de Louvain 1302 Place Ste Barbe, 2 1303 Louvain-la-Neuve, 1348 1304 Belgium 1306 Email: david.lebrun@uclouvain.be