idnits 2.17.1 draft-ietf-6man-segment-routing-header-01.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 (March 18, 2016) is 2960 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 415 -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180-4' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-06 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-04 == Outdated reference: A later version (-12) exists of draft-ietf-spring-ipv6-use-cases-06 == Outdated reference: A later version (-08) exists of draft-ietf-spring-problem-statement-07 == Outdated reference: A later version (-12) exists of draft-ietf-spring-resiliency-use-cases-02 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-07 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-03 Summary: 1 error (**), 0 flaws (~~), 8 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: September 19, 2016 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 March 18, 2016 21 IPv6 Segment Routing Header (SRH) 22 draft-ietf-6man-segment-routing-header-01 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 September 19, 2016. 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) . . . . . . . . . . . 8 85 3.1. SRH TLVs . . . . . . . . . . . . . . . . . . . . . . . . 10 86 3.1.1. Ingress Node TLV . . . . . . . . . . . . . . . . . . 10 87 3.1.2. Egress Node TLV . . . . . . . . . . . . . . . . . . . 11 88 3.1.3. Opaque Container TLV . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . . . 15 93 4.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 15 94 4.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 16 95 4.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 16 96 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 97 5.1. Threat model . . . . . . . . . . . . . . . . . . . . . . 17 98 5.1.1. Source routing threats . . . . . . . . . . . . . . . 18 99 5.1.2. Applicability of RFC 5095 to SRH . . . . . . . . . . 18 100 5.1.3. Service stealing threat . . . . . . . . . . . . . . . 19 101 5.1.4. Topology disclosure . . . . . . . . . . . . . . . . . 19 102 5.1.5. ICMP Generation . . . . . . . . . . . . . . . . . . . 19 103 5.2. Security fields in SRH . . . . . . . . . . . . . . . . . 20 104 5.2.1. Selecting a hash algorithm . . . . . . . . . . . . . 21 105 5.2.2. Performance impact of HMAC . . . . . . . . . . . . . 21 106 5.2.3. Pre-shared key management . . . . . . . . . . . . . . 22 107 5.3. Deployment Models . . . . . . . . . . . . . . . . . . . . 23 108 5.3.1. Nodes within the SR domain . . . . . . . . . . . . . 23 109 5.3.2. Nodes outside of the SR domain . . . . . . . . . . . 23 110 5.3.3. SR path exposure . . . . . . . . . . . . . . . . . . 24 111 5.3.4. Impact of BCP-38 . . . . . . . . . . . . . . . . . . 24 112 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 113 7. Manageability Considerations . . . . . . . . . . . . . . . . 25 114 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 115 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 116 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 117 10.1. Normative References . . . . . . . . . . . . . . . . . . 25 118 10.2. Informative References . . . . . . . . . . . . . . . . . 26 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 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 127 [I-D.ietf-spring-problem-statement] and 128 [I-D.ietf-spring-ipv6-use-cases]. 130 Segment Routing protocol extensions are defined in 131 [I-D.ietf-isis-segment-routing-extensions], and 132 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 134 2. Introduction 136 Segment Routing (SR), defined in [I-D.ietf-spring-segment-routing], 137 allows a node to steer a packet through a controlled set of 138 instructions, called segments, by prepending an SR header to the 139 packet. A segment can represent any instruction, topological or 140 service-based. SR allows to enforce a flow through any path 141 (topological or service/application based) while maintaining per-flow 142 state only at the ingress node to the SR domain. Segments can be 143 derived from different components: IGP, BGP, Services, Contexts, 144 Locators, etc. The list of segment forming the path is called the 145 Segment List and is encoded in the packet header. 147 SR allows the use of strict and loose source based routing paradigms 148 without requiring any additional signaling protocols in the 149 infrastructure hence delivering an excellent scalability property. 151 The source based routing model described in 152 [I-D.ietf-spring-segment-routing] is inherited from the ones proposed 153 by [RFC1940] and [RFC2460]. The source based routing model offers 154 the support for explicit routing capability. 156 2.1. Data Planes supporting Segment Routing 158 Segment Routing (SR), can be instantiated over MPLS 159 ([I-D.ietf-spring-segment-routing-mpls]) and IPv6. This document 160 defines its instantiation over the IPv6 data-plane based on the use- 161 cases defined in [I-D.ietf-spring-ipv6-use-cases]. 163 This document defines a new type of Routing Header (originally 164 defined in [RFC2460]) called the Segment Routing Header (SRH) in 165 order to convey the Segment List in the packet header as defined in 166 [I-D.ietf-spring-segment-routing]. Mechanisms through which segment 167 are known and advertised are outside the scope of this document. 169 A segment is materialized by an IPv6 address. A segment identifies a 170 topological instruction or a service instruction. A segment can be 171 either: 173 o global: a global segment represents an instruction supported by 174 all nodes in the SR domain and it is instantiated through an IPv6 175 address globally known in the SR domain. 177 o local: a local segment represents an instruction supported only by 178 the node who originates it and it is instantiated through an IPv6 179 address that is known only by the local node. 181 2.2. Segment Routing (SR) Domain 183 We define the concept of the Segment Routing Domain (SR Domain) as 184 the set of nodes participating into the source based routing model. 185 These nodes may be connected to the same physical infrastructure 186 (e.g.: a Service Provider's network) as well as nodes remotely 187 connected to each other (e.g.: an enterprise VPN or an overlay). 189 A non-exhaustive list of examples of SR Domains is: 191 o The network of an operator, service provider, content provider, 192 enterprise including nodes, links and Autonomous Systems. 194 o A set of nodes connected as an overlay over one or more transit 195 providers. The overlay nodes exchange SR-enabled traffic with 196 segments belonging solely to the overlay routers (the SR domain). 197 None of the segments in the SR-enabled packets exchanged by the 198 overlay belong to the transit networks 200 The source based routing model through its instantiation of the 201 Segment Routing Header (SRH) defined in this document equally applies 202 to all the above examples. 204 While the source routing model defined in [RFC2460] doesn't mandate 205 which node is allowed to insert (or modify) the SRH, it is assumed in 206 this document that the SRH is inserted in the packet by its source. 207 For example: 209 o At the node originating the packet (host, server). 211 o At the ingress node of an SR domain where the ingress node 212 receives an IPv6 packet and encapsulates it into an outer IPv6 213 header followed by a Segment Routing header. 215 2.2.1. SR Domain in a Service Provider Network 217 The following figure illustrates an SR domain consisting of an 218 operator's network infrastructure. 220 (-------------------------- Operator 1 -----------------------) 221 ( ) 222 ( (-----AS 1-----) (-------AS 2-------) (----AS 3-------) ) 223 ( ( ) ( ) ( ) ) 224 A1--(--(--11---13--14-)--(-21---22---23--24-)--(-31---32---34--)--)--Z1 225 ( ( /|\ /|\ /| ) ( |\ /|\ /|\ /| ) ( |\ /|\ /| \ ) ) 226 A2--(--(/ | \/ | \/ | ) ( | \/ | \/ | \/ | ) ( | \/ | \/ | \)--)--Z2 227 ( ( | /\ | /\ | ) ( | /\ | /\ | /\ | ) ( | /\ | /\ | ) ) 228 ( ( |/ \|/ \| ) ( |/ \|/ \|/ \| ) ( |/ \|/ \| ) ) 229 A3--(--(--15---17--18-)--(-25---26---27--28-)--(-35---36---38--)--)--Z3 230 ( ( ) ( ) ( ) ) 231 ( (--------------) (------------------) (---------------) ) 232 ( ) 233 (-------------------------------------------------------------) 235 Figure 1: Service Provider SR Domain 237 Figure 1 describes an operator network including several ASes and 238 delivering connectivity between endpoints. In this scenario, Segment 239 Routing is used within the operator networks and across the ASes 240 boundaries (all being under the control of the same operator). In 241 this case segment routing can be used in order to address use cases 242 such as end-to-end traffic engineering, fast re-route, egress peer 243 engineering, data-center traffic engineering as described in 244 [I-D.ietf-spring-problem-statement], [I-D.ietf-spring-ipv6-use-cases] 245 and [I-D.ietf-spring-resiliency-use-cases]. 247 Typically, an IPv6 packet received at ingress (i.e.: from outside the 248 SR domain), is classified according to network operator policies and 249 such classification results into an outer header with an SRH applied 250 to the incoming packet. The SRH contains the list of segment 251 representing the path the packet must take inside the SR domain. 252 Thus, the SA of the packet is the ingress node, the DA (due to SRH 253 procedures described in Section 4) is set as the first segment of the 254 path and the last segment of the path is the egress node of the SR 255 domain. 257 The path may include intra-AS as well as inter-AS segments. It has 258 to be noted that all nodes within the SR domain are under control of 259 the same administration. When the packet reaches the egress point of 260 the SR domain, the outer header and its SRH are removed so that the 261 destination of the packet is unaware of the SR domain the packet has 262 traversed. 264 The outer header with the SRH is no different from any other 265 tunneling encapsulation mechanism and allows a network operator to 266 implement traffic engineering mechanisms so to efficiently steer 267 traffic across his infrastructure. 269 2.2.2. SR Domain in a Overlay Network 271 The following figure illustrates an SR domain consisting of an 272 overlay network over multiple operator's networks. 274 (--Operator 1---) (-----Operator 2-----) (--Operator 3---) 275 ( ) ( ) ( ) 276 A1--(--11---13--14--)--(--21---22---23--24--)--(-31---32---34--)--C1 277 ( /|\ /|\ /| ) ( |\ /|\ /|\ /| ) ( |\ /|\ /| \ ) 278 A2--(/ | \/ | \/ | ) ( | \/ | \/ | \/ | ) ( | \/ | \/ | \)--C2 279 ( | /\ | /\ | ) ( | /\ | /\ | /\ | ) ( | /\ | /\ | ) 280 ( |/ \|/ \| ) ( |/ \|/ \|/ \| ) ( |/ \|/ \| ) 281 A3--(--15---17--18--)--(--25---26---27--28--)--(-35---36---38--)--C3 282 ( ) ( | | | ) ( ) 283 (---------------) (--|----|---------|--) (---------------) 284 | | | 285 B1 B2 B3 287 Figure 2: Overlay SR Domain 289 Figure 2 describes an overlay consisting of nodes connected to three 290 different network operators and forming a single overlay network 291 where Segment routing packets are exchanged. 293 The overlay consists of nodes A1, A2, A3, B1, B2, B3, C1, C2 and C3. 294 These nodes are connected to their respective network operator and 295 form an overlay network. 297 Each node may originate packets with an SRH which contains, in the 298 segment list of the SRH or in the DA, segments identifying other 299 overlay nodes. This implies that packets with an SRH may traverse 300 operator's networks but, obviously, these SRHs cannot contain an 301 address/segment of the transit operators 1, 2 and 3. The SRH 302 originated by the overlay can only contain address/segment under the 303 administration of the overlay (e.g. address/segments supported by A1, 304 A2, A3, B1, B2, B3, C1,C2 or C3). 306 In this model, the operator network nodes are transit nodes and, 307 according to [RFC2460], MUST NOT inspect the routing extension header 308 since they are not the DA of the packet. 310 It is a common practice in operators networks to filter out, at 311 ingress, any packet whose DA is the address of an internal node and 312 it is also possible that an operator would filter out any packet 313 destined to an internal address and having an extension header in it. 315 This common practice does not impact the SR-enabled traffic between 316 the overlay nodes as the intermediate transit networks do never see a 317 destination address belonging to their infrastructure. These SR- 318 enabled overlay packets will thus never be filtered by the transit 319 operators. 321 In all cases, transit packets (i.e.: packets whose DA is outside the 322 domain of the operator's network) will be forwarded accordingly 323 without introducing any security concern in the operator's network. 324 This is similar to tunneled packets. 326 3. Segment Routing Extension Header (SRH) 328 A new type of the Routing Header (originally defined in [RFC2460]) is 329 defined: the Segment Routing Header (SRH) which has a new Routing 330 Type, (suggested value 4) to be assigned by IANA. 332 The Segment Routing Header (SRH) is defined as follows: 334 0 1 2 3 335 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 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | First Segment | Flags | RESERVED | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | | 342 | Segment List[0] (128 bits IPv6 address) | 343 | | 344 | | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | | 347 | | 348 ... 349 | | 350 | | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | | 353 | Segment List[n] (128 bits IPv6 address) | 354 | | 355 | | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 // // 358 // Optional Type Length Value objects (variable) // 359 // // 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 where: 364 o Next Header: 8-bit selector. Identifies the type of header 365 immediately following the SRH. 367 o Hdr Ext Len: 8-bit unsigned integer, is the length of the SRH 368 header in 8-octet units, not including the first 8 octets. 370 o Routing Type: TBD, to be assigned by IANA (suggested value: 4). 372 o Segments Left. Defined in [RFC2460], it contains the index, in 373 the Segment List, of the next segment to inspect. Segments Left 374 is decremented at each segment. 376 o First Segment: contains the index, in the Segment List, of the 377 first segment of the path which is in fact the last element of the 378 Segment List. 380 o Flags: 16 bits of flags. Following flags are defined: 382 1 383 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 |C|P|O|A|H| Unused | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 C-flag: Clean-up flag. Set when the SRH has to be removed from 389 the packet when the packet reaches the last segment. 391 P-flag: Protected flag. Set when the packet has been rerouted 392 through FRR mechanism by an SR endpoint node. 394 O-flag: OAM flag. When set, it indicates that this packet is 395 an operations and management (OAM) packet. 397 A-flag: Alert flag. If present, it means important Type Length 398 Value (TLV) objects are present. See Section 3.1 for details 399 on TLVs objects. 401 H-flag: HMAC flag. If set, the HMAC TLV is present and is 402 encoded as the last TLV of the SRH. In other words, the last 403 36 octets of the SRH represent the HMAC information. See 404 Section 3.1.5 for details on the HMAC TLV. 406 Unused: Reserved and for future use. SHOULD be unset on 407 transmission and MUST be ignored on receipt. 409 o RESERVED: SHOULD be unset on transmission and MUST be ignored on 410 receipt. 412 o Segment List[n]: 128 bit IPv6 addresses representing the nth 413 segment in the Segment List. The Segment List is encoded starting 414 from the last segment of the path. I.e., the first element of the 415 segment list (Segment List [0]) contains the last segment of the 416 path while the last segment of the Segment List (Segment List[n]) 417 contains the first segment of the path. The index contained in 418 "Segments Left" identifies the current active segment. 420 o Type Length Value (TLV) are described in Section 3.1. 422 3.1. SRH TLVs 424 This section defines TLVs of the Segment Routing Header. 426 Type Length Value (TLV) contain optional information that may be used 427 by the node identified in the DA of the packet. It has to be noted 428 that the information carried in the TLVs is not intended to be used 429 by the routing layer. Typically, TLVs carry information that is 430 consumed by other components (e.g.: OAM) than the routing function. 432 Each TLV has its own length, format and semantic. The code-point 433 allocated (by IANA) to each TLV defines both the format and the 434 semantic of the information carried in the TLV. Multiple TLVs may be 435 encoded in the same SRH. 437 The "Length" field of the TLV is primarily used to skip the TLV while 438 inspecting the SRH in case the node doesn't support or recognize the 439 TLV codepoint. The "Length" defines the TLV length in octets and not 440 including the "Type" and "Length" fields. 442 The primary scope of TLVs is to give the receiver of the packet 443 information related to the source routed path (e.g.: where the packet 444 entered in the SR domain and where it is expected to exit). 446 Additional TLVs may be defined in the future. 448 3.1.1. Ingress Node TLV 450 The Ingress Node TLV is optional and identifies the node this packet 451 traversed when entered the SR domain. The Ingress Node TLV has 452 following format: 454 0 1 2 3 455 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 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Type | Length | RESERVED | Flags | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | | 460 | Ingress Node (16 octets) | 461 | | 462 | | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 where: 467 o Type: to be assigned by IANA (suggested value 1). 469 o Length: 18. 471 o RESERVED: 8 bits. SHOULD be unset on transmission and MUST be 472 ignored on receipt. 474 o Flags: 8 bits. No flags are defined in this document. 476 o Ingress Node: 128 bits. Defines the node where the packet is 477 expected to enter the SR domain. In the encapsulation case 478 described in Section 2.2.1, this information corresponds to the SA 479 of the encapsulating header. 481 3.1.2. Egress Node TLV 483 The Egress Node TLV is optional and identifies the node this packet 484 is expected to traverse when exiting the SR domain. The Egress Node 485 TLV has following format: 487 0 1 2 3 488 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 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Type | Length | RESERVED | Flags | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | | 493 | Egress Node (16 octets) | 494 | | 495 | | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 where: 500 o Type: to be assigned by IANA (suggested value 2). 502 o Length: 18. 504 o RESERVED: 8 bits. SHOULD be unset on transmission and MUST be 505 ignored on receipt. 507 o Flags: 8 bits. No flags are defined in this document. 509 o Egress Node: 128 bits. Defines the node where the packet is 510 expected to exit the SR domain. In the encapsulation case 511 described in Section 2.2.1, this information corresponds to the 512 last segment of the SRH in the encapsulating header. 514 3.1.3. Opaque Container TLV 516 The Opaque Container TLV is optional and has the following format: 518 0 1 2 3 519 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 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Type | Length | RESERVED | Flags | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | | 524 | Opaque Container (16 octets) | 525 | | 526 | | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 where: 531 o Type: to be assigned by IANA (suggested value 3). 533 o Length: 18. 535 o RESERVED: 8 bits. SHOULD be unset on transmission and MUST be 536 ignored on receipt. 538 o Flags: 8 bits. No flags are defined in this document. 540 o Opaque Container: 128 bits of opaque data not relevant for the 541 routing layer. Typically, this information is consumed by a non- 542 routing component of the node receiving the packet (i.e.: the node 543 in the DA). 545 3.1.4. Padding TLV 547 The Padding TLV is optional and with the purpose of aligning the SRH 548 on a 8 octet boundary. The Padding TLV has the following format: 550 0 1 2 3 551 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 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Type | Length | Padding (variable) | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 // Padding (variable) // 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 where: 560 o Type: to be assigned by IANA (suggested value 4). 562 o Length: 1 to 7 564 o Padding: from 1 to 7 octets of padding. Padding bits have no 565 semantic. They SHOULD be set to 0 on transmission and MUST be 566 ignored on receipt. 568 The following applies to the Padding TLV: 570 o Padding TLV is optional and MAY only appear once in the SRH. If 571 present, it MUST have a length between 1 and 7 octets. 573 o The Padding TLV is used in order to align the SRH total length on 574 the 8 octet boundary. 576 o When present, the Padding TLV MUST appear as the last TLV before 577 the HMAC TLV (if HMAC TLV is present). 579 o When present, the Padding TLV MUST have a length from 1 to 7 in 580 order to align the SRH total lenght on a 8-octet boundary. 582 o When a router inspecting the SRH encounters the Padding TLV, it 583 MUST assume that no other TLV (other than the HMAC) follow the 584 Padding TLV. 586 3.1.5. HMAC TLV 588 HMAC TLV is optional and contains the HMAC information. The HMAC TLV 589 has the following format: 591 0 1 2 3 592 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 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Type | Length | RESERVED | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | HMAC Key ID (4 octets) | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | // 599 | HMAC (32 octets) // 600 | // 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 where: 605 o Type: to be assigned by IANA (suggested value 5). 607 o Length: 38. 609 o RESERVED: 2 octets. SHOULD be unset on transmission and MUST be 610 ignored on receipt. 612 o HMAC Key ID: 4 octets. 614 o HMAC: 32 octets. 616 o HMAC and HMAC Key ID usage is described in Section 5 618 The Following applies to the HMAC TLV: 620 o When present, the HMAC TLV MUST be encoded as the last TLV of the 621 SRH. 623 o If the HMAC TLV is present, the SRH H-Flag (Figure 4) MUST be set. 625 o When the H-flag is set in the SRH, the router inspecting the SRH 626 MUST find the HMAC TLV in the last 38 octets of the SRH. 628 3.2. SRH and RFC2460 behavior 630 The SRH being a new type of the Routing Header, it also has the same 631 properties: 633 SHOULD only appear once in the packet. 635 Only the router whose address is in the DA field of the packet 636 header MUST inspect the SRH. 638 Therefore, Segment Routing in IPv6 networks implies that the segment 639 identifier (i.e.: the IPv6 address of the segment) is moved into the 640 DA of the packet. 642 The DA of the packet changes at each segment termination/completion 643 and therefore the final DA of the packet MUST be encoded as the last 644 segment of the path. 646 4. SRH Procedures 648 In this section we describe the different procedures on the SRH. 650 4.1. Source SR Node 652 A Source SR Node can be any node originating an IPv6 packet with its 653 IPv6 and Segment Routing Headers. This include either: 655 A host originating an IPv6 packet. 657 An SR domain ingress router encapsulating a received IPv6 packet 658 into an outer IPv6 header followed by an SRH. 660 The mechanism through which a Segment List is derived is outside of 661 the scope of this document. As an example, the Segment List may be 662 obtained through: 664 Local path computation. 666 Local configuration. 668 Interaction with a centralized controller delivering the path. 670 Any other mechanism. 672 The following are the steps of the creation of the SRH: 674 Next Header and Hdr Ext Len fields are set according to [RFC2460]. 676 Routing Type field is set as TBD (to be allocated by IANA, 677 suggested value 4). 679 The Segment List is built with the FIRST segment of the path 680 encoded in the LAST element of the Segment List. Subsequent 681 segments are encoded on top of the first segment. Finally, the 682 LAST segment of the path is encoded in the FIRST element of the 683 Segment List. In other words, the Segment List is encoded in the 684 reverse order of the path. 686 The final DA of the packet is encoded as the last segment of the 687 path (encoded in the first element of the Segment List). 689 The DA of the packet is set with the value of the first segment 690 (found in the last element of the segment list). 692 The Segments Left field is set to n-1 where n is the number of 693 elements in the Segment List. 695 The First Segment field is set to n-1 where n is the number of 696 elements in the Segment List. 698 The packet is sent out towards the first segment (i.e.: 699 represented in the packet DA). 701 HMAC TLV may be set according to Section 5. 703 4.2. Transit Node 705 According to [RFC2460], the only node who is allowed to inspect the 706 Routing Extension Header (and therefore the SRH), is the node 707 corresponding to the DA of the packet. Any other transit node MUST 708 NOT inspect the underneath routing header and MUST forward the packet 709 towards the DA and according to the IPv6 routing table. 711 In the example case described in Section 2.2.2, when SR capable nodes 712 are connected through an overlay spanning multiple third-party 713 infrastructure, it is safe to send SRH packets (i.e.: packet having a 714 Segment Routing Header) between each other overlay/SR-capable nodes 715 as long as the segment list does not include any of the transit 716 provider nodes. In addition, as a generic security measure, any 717 service provider will block any packet destined to one of its 718 internal routers, especially if these packets have an extended header 719 in it. 721 4.3. SR Segment Endpoint Node 723 The SR segment endpoint node is the node whose address is in the DA. 724 The segment endpoint node inspects the SRH and does: 726 1. IF DA = myself (segment endpoint) 727 2. IF Segments Left > 0 THEN 728 decrement Segments Left 729 update DA with Segment List[Segments Left] 730 3. IF Segments Left == 0 THEN 731 IF Clean-up bit is set THEN remove the SRH 732 4. ELSE continue IPv6 processing of the packet 733 End of processing. 734 5. Forward the packet out 736 5. Security Considerations 738 This section analyzes the security threat model, the security issues 739 and proposed solutions related to the new Segment Routing Header. 741 The Segment Routing Header (SRH) is simply another type of the 742 routing header as described in RFC 2460 [RFC2460] and is: 744 o inserted by an SR edge router when entering the segment routing 745 domain or by the originating host itself. The source host can 746 even be outside the SR domain; 748 o inspected and acted upon when reaching the destination address of 749 the IP header per RFC 2460 [RFC2460]. 751 Per RFC2460 [RFC2460], routers on the path that simply forward an 752 IPv6 packet (i.e. the IPv6 destination address is none of theirs) 753 will never inspect and process the content of the SRH. Routers whose 754 one interface IPv6 address equals the destination address field of 755 the IPv6 packet MUST parse the SRH and, if supported and if the local 756 configuration allows it, MUST act accordingly to the SRH content. 758 According to RFC2460 [RFC2460], the default behavior of a non SR- 759 capable router upon receipt of an IPv6 packet with SRH destined to an 760 address of its, is to: 762 o ignore the SRH completely if the Segment Left field is 0 and 763 proceed to process the next header in the IPv6 packet; 765 o discard the IPv6 packet if Segment Left field is greater than 0, 766 it MAY send a Parameter Problem ICMP message back to the Source 767 Address. 769 5.1. Threat model 770 5.1.1. Source routing threats 772 Using an SRH is similar to source routing, therefore it has some 773 well-known security issues as described in RFC4942 [RFC4942] section 774 2.1.1 and RFC5095 [RFC5095]: 776 o amplification attacks: where a packet could be forged in such a 777 way to cause looping among a set of SR-enabled routers causing 778 unnecessary traffic, hence a Denial of Service (DoS) against 779 bandwidth; 781 o reflection attack: where a hacker could force an intermediate node 782 to appear as the immediate attacker, hence hiding the real 783 attacker from naive forensic; 785 o bypass attack: where an intermediate node could be used as a 786 stepping stone (for example in a De-Militarized Zone) to attack 787 another host (for example in the datacenter or any back-end 788 server). 790 5.1.2. Applicability of RFC 5095 to SRH 792 First of all, the reader must remember this specific part of section 793 1 of RFC5095 [RFC5095], "A side effect is that this also eliminates 794 benign RH0 use-cases; however, such applications may be facilitated 795 by future Routing Header specifications.". In short, it is not 796 forbidden to create new secure type of Routing Header; for example, 797 RFC 6554 (RPL) [RFC6554] also creates a new Routing Header type for a 798 specific application confined in a single network. 800 In the segment routing architecture described in 801 [I-D.ietf-spring-segment-routing] there are basically two kinds of 802 nodes (routers and hosts): 804 o nodes within the SR domain, which is within one single 805 administrative domain, i.e., where all nodes are trusted anyway 806 else the damage caused by those nodes could be worse than 807 amplification attacks: traffic interception, man-in-the-middle 808 attacks, more server DoS by dropping packets, and so on. 810 o nodes outside of the SR domain, which is outside of the 811 administrative segment routing domain hence they cannot be trusted 812 because there is no physical security for those nodes, i.e., they 813 can be replaced by hostile nodes or can be coerced in wrong 814 behaviors. 816 The main use case for SR consists of the single administrative domain 817 where only trusted nodes with SR enabled and configured participate 818 in SR: this is the same model as in RFC6554 [RFC6554]. All non- 819 trusted nodes do not participate as either SR processing is not 820 enabled by default or because they only process SRH from nodes within 821 their domain. 823 Moreover, all SR nodes ignore SRH created by outsiders based on 824 topology information (received on a peering or internal interface) or 825 on presence and validity of the HMAC field. Therefore, if 826 intermediate nodes ONLY act on valid and authorized SRH (such as 827 within a single administrative domain), then there is no security 828 threat similar to RH-0. Hence, the RFC 5095 [RFC5095] attacks are 829 not applicable. 831 5.1.3. Service stealing threat 833 Segment routing is used for added value services, there is also a 834 need to prevent non-participating nodes to use those services; this 835 is called 'service stealing prevention'. 837 5.1.4. Topology disclosure 839 The SRH may also contains IPv6 addresses of some intermediate SR- 840 nodes in the path towards the destination, this obviously reveals 841 those addresses to the potentially hostile attackers if those 842 attackers are able to intercept packets containing SRH. On the other 843 hand, if the attacker can do a traceroute whose probes will be 844 forwarded along the SR path, then there is little learned by 845 intercepting the SRH itself. Also the clean-bit of SRH can help by 846 removing the SRH before forwarding the packet to potentially a non- 847 trusted part of the network. 849 5.1.5. ICMP Generation 851 Per section 4.4 of RFC2460 [RFC2460], when destination nodes (i.e. 852 where the destination address is one of theirs) receive a Routing 853 Header with unsupported Routing Type, the required behavior is: 855 o If Segments Left is zero, the node must ignore the Routing header 856 and proceed to process the next header in the packet. 858 o If Segments Left is non-zero, the node must discard the packet and 859 send an ICMP Parameter Problem, Code 0, message to the packet's 860 Source Address, pointing to the unrecognized Routing Type. 862 This required behavior could be used by an attacker to force the 863 generation of ICMP message by any node. The attacker could send 864 packets with SRH (with Segment Left set to 0) destined to a node not 865 supporting SRH. Per RFC2460 [RFC2460], the destination node could 866 generate an ICMP message, causing a local CPU utilization and if the 867 source of the offending packet with SRH was spoofed could lead to a 868 reflection attack without any amplification. 870 It must be noted that this is a required behavior for any unsupported 871 Routing Type and not limited to SRH packets. So, it is not specific 872 to SRH and the usual rate limiting for ICMP generation is required 873 anyway for any IPv6 implementation and has been implemented and 874 deployed for many years. 876 5.2. Security fields in SRH 878 This section summarizes the use of specific fields in the SRH. They 879 are based on a key-hashed message authentication code (HMAC). 881 The security-related fields in the SRH are instantiated by the HMAC 882 TLV, containing: 884 o HMAC Key-id, 16 bits wide; 886 o HMAC, 256 bits wide (optional, exists only if HMAC Key-id is not 887 0). 889 The HMAC field is the output of the HMAC computation (per RFC 2104 890 [RFC2104]) using a pre-shared key identified by HMAC Key-id and of 891 the text which consists of the concatenation of: 893 o the source IPv6 address; 895 o First Segment field; 897 o an octet whose bit-0 is the clean-up bit flag and others are 0; 899 o HMAC Key-id; 901 o all addresses in the Segment List. 903 The purpose of the HMAC TLV is to verify the validity, the integrity 904 and the authorization of the SRH itself. If an outsider of the SR 905 domain does not have access to a current pre-shared secret, then it 906 cannot compute the right HMAC field and the first SR router on the 907 path processing the SRH and configured to check the validity of the 908 HMAC will simply reject the packet. 910 The HMAC TLV is located at the end of the SRH simply because only the 911 router on the ingress of the SR domain needs to process it, then all 912 other SR nodes can ignore it (based on local policy) because they 913 trust the upstream router. This is to speed up forwarding operations 914 because SR routers which do not validate the SRH do not need to parse 915 the SRH until the end. 917 The HMAC Key-id field allows for the simultaneous existence of 918 several hash algorithms (SHA-256, SHA3-256 ... or future ones) as 919 well as pre-shared keys. The HMAC Key-id field is opaque, i.e., it 920 has neither syntax nor semantic except as an index to the right 921 combination of pre-shared key and hash algorithm and except that a 922 value of 0 means that there is no HMAC field. Having an HMAC Key-id 923 field allows for pre-shared key roll-over when two pre-shared keys 924 are supported for a while when all SR nodes converged to a fresher 925 pre-shared key. It could also allow for interoperation among 926 different SR domains if allowed by local policy and assuming a 927 collision-free HMAC Key Id allocation. 929 When a specific SRH is linked to a time-related service (such as 930 turbo-QoS for a 1-hour period) where the DA, Segment ID (SID) are 931 identical, then it is important to refresh the shared-secret 932 frequently as the HMAC validity period expires only when the HMAC 933 Key-id and its associated shared-secret expires. 935 5.2.1. Selecting a hash algorithm 937 The HMAC field in the HMAC TLV is 256 bit wide. Therefore, the HMAC 938 MUST be based on a hash function whose output is at least 256 bits. 939 If the output of the hash function is 256, then this output is simply 940 inserted in the HMAC field. If the output of the hash function is 941 larger than 256 bits, then the output value is truncated to 256 by 942 taking the least-significant 256 bits and inserting them in the HMAC 943 field. 945 SRH implementations can support multiple hash functions but MUST 946 implement SHA-2 [FIPS180-4] in its SHA-256 variant. 948 NOTE: SHA-1 is currently used by some early implementations used for 949 quick interoperations testing, the 160-bit hash value must then be 950 right-hand padded with 96 bits set to 0. The authors understand that 951 this is not secure but is ok for limited tests. 953 5.2.2. Performance impact of HMAC 955 While adding an HMAC to each and every SR packet increases the 956 security, it has a performance impact. Nevertheless, it must be 957 noted that: 959 o the HMAC field is used only when SRH is inserted by a device (such 960 as a home set-up box) which is outside of the segment routing 961 domain. If the SRH is added by a router in the trusted segment 962 routing domain, then, there is no need for an HMAC field, hence no 963 performance impact. 965 o when present, the HMAC field MUST only be checked and validated by 966 the first router of the segment routing domain, this router is 967 named 'validating SR router'. Downstream routers may not inspect 968 the HMAC field. 970 o this validating router can also have a cache of to improve the performance. It is not the 972 same use case as in IPsec where HMAC value was unique per packet, 973 in SRH, the HMAC value is unique per flow. 975 o Last point, hash functions such as SHA-2 have been optimized for 976 security and performance and there are multiple implementations 977 with good performance. 979 With the above points in mind, the performance impact of using HMAC 980 is minimized. 982 5.2.3. Pre-shared key management 984 The field HMAC Key-id allows for: 986 o key roll-over: when there is a need to change the key (the hash 987 pre-shared secret), then multiple pre-shared keys can be used 988 simultaneously. The validating routing can have a table of for the currently active and future 990 keys. 992 o different algorithms: by extending the previous table to , the validating router 994 can also support simultaneously several hash algorithms (see 995 section Section 5.2.1) 997 The pre-shared secret distribution can be done: 999 o in the configuration of the validating routers, either by static 1000 configuration or any SDN oriented approach; 1002 o dynamically using a trusted key distribution such as [RFC6407] 1004 The intent of this document is NOT to define yet-another-key- 1005 distribution-protocol. 1007 5.3. Deployment Models 1009 5.3.1. Nodes within the SR domain 1011 An SR domain is defined as a set of interconnected routers where all 1012 routers at the perimeter are configured to insert and act on SRH. 1013 Some routers inside the SR domain can also act on SRH or simply 1014 forward IPv6 packets. 1016 The routers inside an SR domain can be trusted to generate SRH and to 1017 process SRH received on interfaces that are part of the SR domain. 1018 These nodes MUST drop all SRH packets received on an interface that 1019 is not part of the SR domain and containing an SRH whose HMAC field 1020 cannot be validated by local policies. This includes obviously 1021 packet with an SRH generated by a non-cooperative SR domain. 1023 If the validation fails, then these packets MUST be dropped, ICMP 1024 error messages (parameter problem) SHOULD be generated (but rate 1025 limited) and SHOULD be logged. 1027 5.3.2. Nodes outside of the SR domain 1029 Nodes outside of the SR domain cannot be trusted for physical 1030 security; hence, they need to request by some trusted means (outside 1031 of the scope of this document) a complete SRH for each new connection 1032 (i.e. new destination address). The received SRH MUST include an 1033 HMAC TLV which is computed correctly (see Section 5.2). 1035 When an outside node sends a packet with an SRH and towards an SR 1036 domain ingress node, the packet MUST contain the HMAC TLV (with a 1037 Key-id and HMAC fields) and the the destination address MUST be an 1038 address of an SR domain ingress node . 1040 The ingress SR router, i.e., the router with an interface address 1041 equals to the destination address, MUST verify the HMAC TLV. 1043 If the validation is successful, then the packet is simply forwarded 1044 as usual for an SR packet. As long as the packet travels within the 1045 SR domain, no further HMAC check needs to be done. Subsequent 1046 routers in the SR domain MAY verify the HMAC TLV when they process 1047 the SRH (i.e. when they are the destination). 1049 If the validation fails, then this packet MUST be dropped, an ICMP 1050 error message (parameter problem) SHOULD be generated (but rate 1051 limited) and SHOULD be logged. 1053 5.3.3. SR path exposure 1055 As the intermediate SR nodes addresses appears in the SRH, if this 1056 SRH is visible to an outsider then he/she could reuse this knowledge 1057 to launch an attack on the intermediate SR nodes or get some insider 1058 knowledge on the topology. This is especially applicable when the 1059 path between the source node and the first SR domain ingress router 1060 is on the public Internet. 1062 The first remark is to state that 'security by obscurity' is never 1063 enough; in other words, the security policy of the SR domain MUST 1064 assume that the internal topology and addressing is known by the 1065 attacker. A simple traceroute will also give the same information 1066 (with even more information as all intermediate nodes between SID 1067 will also be exposed). IPsec Encapsulating Security Payload 1068 [RFC4303] cannot be use to protect the SRH as per RFC4303 the ESP 1069 header must appear after any routing header (including SRH). 1071 To prevent a user to leverage the gained knowledge by intercepting 1072 SRH, it it recommended to apply an infrastructure Access Control List 1073 (iACL) at the edge of the SR domain. This iACL will drop all packets 1074 from outside the SR-domain whose destination is any address of any 1075 router inside the domain. This security policy should be tuned for 1076 local operations. 1078 5.3.4. Impact of BCP-38 1080 BCP-38 [RFC2827], also known as "Network Ingress Filtering", checks 1081 whether the source address of packets received on an interface is 1082 valid for this interface. The use of loose source routing such as 1083 SRH forces packets to follow a path which differs from the expected 1084 routing. Therefore, if BCP-38 was implemented in all routers inside 1085 the SR domain, then SR packets could be received by an interface 1086 which is not expected one and the packets could be dropped. 1088 As an SR domain is usually a subset of one administrative domain, and 1089 as BCP-38 is only deployed at the ingress routers of this 1090 administrative domain and as packets arriving at those ingress 1091 routers have been normally forwarded using the normal routing 1092 information, then there is no reason why this ingress router should 1093 drop the SRH packet based on BCP-38. Routers inside the domain 1094 commonly do not apply BCP-38; so, this is not a problem. 1096 6. IANA Considerations 1098 This document makes the following registrations in the Internet 1099 Protocol Version 6 (IPv6) Parameters "Routing Type" registry 1100 maintained by IANA: 1102 Suggested Description Reference 1103 Value 1104 ---------------------------------------------------------- 1105 4 Segment Routing Header (SRH) This document 1107 In addition, this document request IANA to create and maintain a new 1108 Registry: "Segment Routing Header Type-Value Objects". The following 1109 code-points are requested from the registry: 1111 Registry: Segment Routing Header Type-Value Objects 1113 Suggested Description Reference 1114 Value 1115 ----------------------------------------------------- 1116 1 Ingress Node TLV This document 1117 2 Egress Node TLV This document 1118 3 Opaque Container TLV This document 1119 4 Padding TLV This document 1120 5 HMAC TLV This document 1122 7. Manageability Considerations 1124 TBD 1126 8. Contributors 1128 Dave Barach, John Leddy, John Brzozowski, Pierre Francois, Nagendra 1129 Kumar, Mark Townsley, Christian Martin, Roberta Maglione, James 1130 Connolly, Aloys Augustin contributed to the content of this document. 1132 9. Acknowledgements 1134 The authors would like to thank Ole Troan, Bob Hinden, Fred Baker, 1135 Brian Carpenter and Alexandru Petrescu for their comments to this 1136 document. 1138 10. References 1140 10.1. Normative References 1142 [FIPS180-4] 1143 National Institute of Standards and Technology, "FIPS 1144 180-4 Secure Hash Standard (SHS)", March 2012, 1145 . 1148 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1149 Requirement Levels", BCP 14, RFC 2119, 1150 DOI 10.17487/RFC2119, March 1997, 1151 . 1153 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1154 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1155 December 1998, . 1157 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1158 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1159 . 1161 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1162 of Type 0 Routing Headers in IPv6", RFC 5095, 1163 DOI 10.17487/RFC5095, December 2007, 1164 . 1166 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 1167 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 1168 October 2011, . 1170 10.2. Informative References 1172 [I-D.ietf-isis-segment-routing-extensions] 1173 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 1174 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 1175 Extensions for Segment Routing", draft-ietf-isis-segment- 1176 routing-extensions-06 (work in progress), December 2015. 1178 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 1179 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1180 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 1181 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 1182 segment-routing-extensions-04 (work in progress), December 1183 2015. 1185 [I-D.ietf-spring-ipv6-use-cases] 1186 Brzozowski, J., Leddy, J., Leung, I., Previdi, S., 1187 Townsley, W., Martin, C., Filsfils, C., and R. Maglione, 1188 "IPv6 SPRING Use Cases", draft-ietf-spring-ipv6-use- 1189 cases-06 (work in progress), March 2016. 1191 [I-D.ietf-spring-problem-statement] 1192 Previdi, S., Filsfils, C., Decraene, B., Litkowski, S., 1193 Horneffer, M., and R. Shakir, "SPRING Problem Statement 1194 and Requirements", draft-ietf-spring-problem-statement-07 1195 (work in progress), March 2016. 1197 [I-D.ietf-spring-resiliency-use-cases] 1198 Francois, P., Filsfils, C., Decraene, B., and R. Shakir, 1199 "Use-cases for Resiliency in SPRING", draft-ietf-spring- 1200 resiliency-use-cases-02 (work in progress), December 2015. 1202 [I-D.ietf-spring-segment-routing] 1203 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 1204 and R. Shakir, "Segment Routing Architecture", draft-ietf- 1205 spring-segment-routing-07 (work in progress), December 1206 2015. 1208 [I-D.ietf-spring-segment-routing-mpls] 1209 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1210 Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., 1211 and E. Crabbe, "Segment Routing with MPLS data plane", 1212 draft-ietf-spring-segment-routing-mpls-03 (work in 1213 progress), February 2016. 1215 [RFC1940] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D. 1216 Zappala, "Source Demand Routing: Packet Format and 1217 Forwarding Specification (Version 1)", RFC 1940, 1218 DOI 10.17487/RFC1940, May 1996, 1219 . 1221 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1222 Hashing for Message Authentication", RFC 2104, 1223 DOI 10.17487/RFC2104, February 1997, 1224 . 1226 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1227 Defeating Denial of Service Attacks which employ IP Source 1228 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1229 May 2000, . 1231 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 1232 Co-existence Security Considerations", RFC 4942, 1233 DOI 10.17487/RFC4942, September 2007, 1234 . 1236 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 1237 Routing Header for Source Routes with the Routing Protocol 1238 for Low-Power and Lossy Networks (RPL)", RFC 6554, 1239 DOI 10.17487/RFC6554, March 2012, 1240 . 1242 Authors' Addresses 1244 Stefano Previdi (editor) 1245 Cisco Systems, Inc. 1246 Via Del Serafico, 200 1247 Rome 00142 1248 Italy 1250 Email: sprevidi@cisco.com 1252 Clarence Filsfils 1253 Cisco Systems, Inc. 1254 Brussels 1255 BE 1257 Email: cfilsfil@cisco.com 1259 Brian Field 1260 Comcast 1261 4100 East Dry Creek Road 1262 Centennial, CO 80122 1263 US 1265 Email: Brian_Field@cable.comcast.com 1267 Ida Leung 1268 Rogers Communications 1269 8200 Dixie Road 1270 Brampton, ON L6T 0C1 1271 CA 1273 Email: Ida.Leung@rci.rogers.com 1275 Jen Linkova 1276 Google 1277 1600 Amphitheatre Parkway 1278 Mountain View, CA 94043 1279 US 1281 Email: furry@google.com 1282 Ebben Aries 1283 Facebook 1284 US 1286 Email: exa@fb.com 1288 Tomoya Kosugi 1289 NTT 1290 3-9-11, Midori-Cho Musashino-Shi, 1291 Tokyo 180-8585 1292 JP 1294 Email: kosugi.tomoya@lab.ntt.co.jp 1296 Eric Vyncke 1297 Cisco Systems, Inc. 1298 De Kleetlaann 6A 1299 Diegem 1831 1300 Belgium 1302 Email: evyncke@cisco.com 1304 David Lebrun 1305 Universite Catholique de Louvain 1306 Place Ste Barbe, 2 1307 Louvain-la-Neuve, 1348 1308 Belgium 1310 Email: david.lebrun@uclouvain.be