idnits 2.17.1 draft-previdi-6man-segment-routing-header-08.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 (October 2, 2015) is 3128 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 622 -- Looks like a reference, but probably isn't: '1' on line 531 -- Looks like a reference, but probably isn't: '2' on line 536 -- Looks like a reference, but probably isn't: '3' on line 541 -- 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-05 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-03 == Outdated reference: A later version (-12) exists of draft-ietf-spring-ipv6-use-cases-05 == Outdated reference: A later version (-08) exists of draft-ietf-spring-problem-statement-04 == Outdated reference: A later version (-12) exists of draft-ietf-spring-resiliency-use-cases-01 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-05 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-01 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 6 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: April 4, 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 October 2, 2015 21 IPv6 Segment Routing Header (SRH) 22 draft-previdi-6man-segment-routing-header-08 24 Abstract 26 Segment Routing (SR) allows a node to steer a packet through a 27 controlled set of instructions, called segments, by prepending a 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 April 4, 2016. 61 Copyright Notice 63 Copyright (c) 2015 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 2.3. Illustration . . . . . . . . . . . . . . . . . . . . . . 8 85 3. IPv6 Instantiation of Segment Routing . . . . . . . . . . . . 10 86 3.1. Segment Identifiers (SIDs) . . . . . . . . . . . . . . . 10 87 3.1.1. Node-SID . . . . . . . . . . . . . . . . . . . . . . 10 88 3.1.2. Adjacency-SID . . . . . . . . . . . . . . . . . . . . 11 89 3.2. Segment Routing Extension Header (SRH) . . . . . . . . . 11 90 3.2.1. SRH and RFC2460 behavior . . . . . . . . . . . . . . 14 91 4. SRH Procedures . . . . . . . . . . . . . . . . . . . . . . . 15 92 4.1. Segment Routing Node Functions . . . . . . . . . . . . . 15 93 4.1.1. Source SR Node . . . . . . . . . . . . . . . . . . . 16 94 4.1.2. SR Domain Ingress Node . . . . . . . . . . . . . . . 17 95 4.1.3. Transit Node . . . . . . . . . . . . . . . . . . . . 17 96 4.1.4. SR Segment Endpoint Node . . . . . . . . . . . . . . 17 98 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 99 5.1. Threat model . . . . . . . . . . . . . . . . . . . . . . 19 100 5.1.1. Source routing threats . . . . . . . . . . . . . . . 19 101 5.1.2. Applicability of RFC 5095 to SRH . . . . . . . . . . 19 102 5.1.3. Service stealing threat . . . . . . . . . . . . . . . 20 103 5.1.4. Topology disclosure . . . . . . . . . . . . . . . . . 20 104 5.1.5. ICMP Generation . . . . . . . . . . . . . . . . . . . 20 105 5.2. Security fields in SRH . . . . . . . . . . . . . . . . . 21 106 5.2.1. Selecting a hash algorithm . . . . . . . . . . . . . 22 107 5.2.2. Performance impact of HMAC . . . . . . . . . . . . . 22 108 5.2.3. Pre-shared key management . . . . . . . . . . . . . . 23 109 5.3. Deployment Models . . . . . . . . . . . . . . . . . . . . 23 110 5.3.1. Nodes within the SR domain . . . . . . . . . . . . . 23 111 5.3.2. Nodes outside of the SR domain . . . . . . . . . . . 24 112 5.3.3. SR path exposure . . . . . . . . . . . . . . . . . . 24 113 5.3.4. Impact of BCP-38 . . . . . . . . . . . . . . . . . . 25 114 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 115 7. Manageability Considerations . . . . . . . . . . . . . . . . 25 116 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 117 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 118 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 119 10.1. Normative References . . . . . . . . . . . . . . . . . . 26 120 10.2. Informative References . . . . . . . . . . . . . . . . . 26 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 123 1. Segment Routing Documents 125 Segment Routing terminology is defined in 126 [I-D.ietf-spring-segment-routing]. 128 Segment Routing use cases are described in 129 [I-D.ietf-spring-problem-statement] and 130 [I-D.ietf-spring-ipv6-use-cases]. 132 Segment Routing protocol extensions are defined in 133 [I-D.ietf-isis-segment-routing-extensions], and 134 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 136 2. Introduction 138 Segment Routing (SR), defined in [I-D.ietf-spring-segment-routing], 139 allows a node to steer a packet through a controlled set of 140 instructions, called segments, by prepending a SR header to the 141 packet. A segment can represent any instruction, topological or 142 service-based. SR allows to enforce a flow through any path 143 (topological or service/application based) while maintaining per-flow 144 state only at the ingress node to the SR domain. Segments can be 145 derived from different components: IGP, BGP, Services, Contexts, 146 Locators, etc. The list of segment forming the path is called the 147 Segment List and is encoded in the packet header. 149 SR allows the use of strict and loose source based routing paradigms 150 without requiring any additional signaling protocols in the 151 infrastructure hence delivering an excellent scalability property. 153 The source based routing model described in 154 [I-D.ietf-spring-segment-routing] is inherited from the ones proposed 155 by [RFC1940] and [RFC2460]. The source based routing model offers 156 the support for explicit routing capability. 158 2.1. Data Planes supporting Segment Routing 160 Segment Routing (SR), can be instantiated over MPLS 161 ([I-D.ietf-spring-segment-routing-mpls]) and IPv6. This document 162 defines its instantiation over the IPv6 data-plane based on the use- 163 cases defined in [I-D.ietf-spring-ipv6-use-cases]. 165 This document defines a new type of Routing Header (originally 166 defined in [RFC2460]) called the Segment Routing Header (SRH) in 167 order to convey the Segment List in the packet header as defined in 168 [I-D.ietf-spring-segment-routing]. Mechanisms through which segment 169 are known and advertised are outside the scope of this document. 171 A segment is materialized by an IPv6 address. A segment identifies a 172 topological instruction or a service instruction. A segment can be 173 either: 175 o global: a global segment represents an instruction supported by 176 all nodes in the SR domain and it is instantiated through an IPv6 177 address globally known in the SR domain. 179 o local: a local segment represents an instruction supported only by 180 the node who originates it and it is instantiated through an IPv6 181 address that is known only by the local node. 183 2.2. Segment Routing (SR) Domain 185 We define the concept of the Segment Routing Domain (SR Domain) as 186 the set of nodes participating into the source based routing model. 187 These nodes may be connected to the same physical infrastructure 188 (e.g.: a Service Provider's network) as well as nodes remotely 189 connected to each other (e.g.: an enterprise VPN or an overlay). 191 A non-exhaustive list of examples of SR Domains is: 193 o The network of an operator, service provider, content provider, 194 enterprise including nodes, links and Autonomous Systems. 196 o A set of nodes connected as an overlay over one or more transit 197 providers. The overlay nodes exchange SR-enabled traffic with 198 segments belonging solely to the overlay routers (the SR domain). 199 None of the segments in the SR-enabled packets exchanged by the 200 overlay belong to the transit networks 202 The source based routing model through its instantiation of the 203 Segment Routing Header (SRH) defined in this document equally applies 204 to all the above examples. 206 While the source routing model defined in [RFC2460] doesn't mandate 207 which node is allowed to insert (or modify) the SRH, it is assumed in 208 this document that the SRH is inserted in the packet by its source. 209 For example: 211 o At the node originating the packet (host, server). 213 o At the ingress node of a SR domain where the ingress node receives 214 an IPv6 packet and encapsulates it into an outer IPv6 header 215 followed by a Segment Routing header. 217 2.2.1. SR Domain in a Service Provider Network 219 The following figure illustrates an SR domain consisting of an 220 operator's network infrastructure. 222 (-------------------------- Operator 1 -----------------------) 223 ( ) 224 ( (-----AS 1-----) (-------AS 2-------) (----AS 3-------) ) 225 ( ( ) ( ) ( ) ) 226 A1--(--(--11---13--14-)--(-21---22---23--24-)--(-31---32---34--)--)--Z1 227 ( ( /|\ /|\ /| ) ( |\ /|\ /|\ /| ) ( |\ /|\ /| \ ) ) 228 A2--(--(/ | \/ | \/ | ) ( | \/ | \/ | \/ | ) ( | \/ | \/ | \)--)--Z2 229 ( ( | /\ | /\ | ) ( | /\ | /\ | /\ | ) ( | /\ | /\ | ) ) 230 ( ( |/ \|/ \| ) ( |/ \|/ \|/ \| ) ( |/ \|/ \| ) ) 231 A3--(--(--15---17--18-)--(-25---26---27--28-)--(-35---36---38--)--)--Z3 232 ( ( ) ( ) ( ) ) 233 ( (--------------) (------------------) (---------------) ) 234 ( ) 235 (-------------------------------------------------------------) 237 Figure 1: Service Provider SR Domain 239 Figure 1 describes an operator network including several ASes and 240 delivering connectivity between endpoints. In this scenario, Segment 241 Routing is used within the operator networks and across the ASes 242 boundaries (all being under the control of the same operator). In 243 this case segment routing can be used in order to address use cases 244 such as end-to-end traffic engineering, fast re-route, egress peer 245 engineering, data-center traffic engineering as described in 246 [I-D.ietf-spring-problem-statement], [I-D.ietf-spring-ipv6-use-cases] 247 and [I-D.ietf-spring-resiliency-use-cases]. 249 Typically, an IPv6 packet received at ingress (i.e.: from outside the 250 SR domain), is classified according to network operator policies and 251 such classification results into an outer header with an SRH applied 252 to the incoming packet. The SRH contains the list of segment 253 representing the path the packet must take inside the SR domain. 254 Thus, the SA of the packet is the ingress node, the DA (due to SRH 255 procedures described in Section 4) is set as the first segment of the 256 path and the last segment of the path is the egress node of the SR 257 domain. 259 The path may include intra-AS as well as inter-AS segments. It has 260 to be noted that all nodes within the SR domain are under control of 261 the same administration. When the packet reaches the egress point of 262 the SR domain, the outer header and its SRH are removed so that the 263 destination of the packet is unaware of the SR domain the packet has 264 traversed. 266 The outer header with the SRH is no different from any other 267 tunneling encapsulation mechanism and allows a network operator to 268 implement traffic engineering mechanisms so to efficiently steer 269 traffic across his infrastructure. 271 2.2.2. SR Domain in a Overlay Network 273 The following figure illustrates an SR domain consisting of an 274 overlay network over multiple operator's networks. 276 (--Operator 1---) (-----Operator 2-----) (--Operator 3---) 277 ( ) ( ) ( ) 278 A1--(--11---13--14--)--(--21---22---23--24--)--(-31---32---34--)--C1 279 ( /|\ /|\ /| ) ( |\ /|\ /|\ /| ) ( |\ /|\ /| \ ) 280 A2--(/ | \/ | \/ | ) ( | \/ | \/ | \/ | ) ( | \/ | \/ | \)--C2 281 ( | /\ | /\ | ) ( | /\ | /\ | /\ | ) ( | /\ | /\ | ) 282 ( |/ \|/ \| ) ( |/ \|/ \|/ \| ) ( |/ \|/ \| ) 283 A3--(--15---17--18--)--(--25---26---27--28--)--(-35---36---38--)--C3 284 ( ) ( | | | ) ( ) 285 (---------------) (--|----|---------|--) (---------------) 286 | | | 287 B1 B2 B3 289 Figure 2: Overlay SR Domain 291 Figure 2 describes an overlay consisting of nodes connected to three 292 different network operators and forming a single overlay network 293 where Segment routing packets are exchanged. 295 The overlay consists of nodes A1, A2, A3, B1, B2, B3, C1, C2 and C3. 296 These nodes are connected to their respective network operator and 297 form an overlay network. 299 Each node may originate packets with an SRH which contains, in the 300 segment list of the SRH or in the DA, segments identifying other 301 overlay nodes. This implies that packets with an SRH may traverse 302 operator's networks but, obviously, these SRHs cannot contain an 303 address/segment of the transit operators 1, 2 and 3. The SRH 304 originated by the overlay can only contain address/segment under the 305 administration of the overlay (e.g. address/segments supported by A1, 306 A2, A3, B1, B2, B3, C1,C2 or C3). 308 In this model, the operator network nodes are transit nodes and, 309 according to [RFC2460], MUST NOT inspect the routing extension header 310 since there are not the DA of the packet. 312 It is a common practice in operators networks to filter out, at 313 ingress, any packet whose DA is the address of an internal node and 314 it is also possible that an operator would filter out any packet 315 destined to an internal address and having an extension header in it. 317 This common practice does not impact the SR-enabled traffic between 318 the overlay nodes as the intermediate transit networks do never see a 319 destination address belonging to their infrastructure. These SR- 320 enabled overlay packets will thus never be filtered by the transit 321 operators. 323 In all cases, transit packets (i.e.: packets whose DA is outside the 324 domain of the operator's network) will be forwarded accordingly 325 without introducing any security concern in the operator's network. 326 This is similar to tunneled packets. 328 2.3. Illustration 330 In the context of Figure 3 we illustrate an example of how segment 331 routing an be used within a SR domain in order to engineer traffic. 332 Let's assume that the SR domain is configured as a single AS and the 333 IGP (OSPF or IS-IS) is configured using the same cost on every link. 334 Let's also assume that a packet P enters the SR domain at an ingress 335 edge router I and that the operator requests the following 336 requirements for packet P: 338 o The local service S offered by node B must be applied to packet P. 340 o The links AB and CE cannot be used to transport the packet P. 342 o Any node N along the journey of the packet should be able to 343 determine where the packet P entered the SR domain and where it 344 will exit. The intermediate node should be able to determine the 345 paths from the ingress edge router to itself, and from itself to 346 the egress edge router. 348 o Per-flow State for packet P should only be created at the ingress 349 edge router. 351 o The operator can forbid, for security reasons, anyone outside the 352 operator domain to exploit its intra-domain SR capabilities. 354 S 355 I---A---B---C---E 356 \ | / \ / 357 \ | / F 358 \|/ 359 D 361 Figure 3: An illustration of SR properties 363 All these properties may be realized by instructing the ingress SR 364 edge router I to create a SRH with the list of segments the packet 365 must traverse: D, B, S, F, E. Therefore, the ingress router I 366 creates an outer header where: 368 o the SA is the IPv6 address of I 369 o the final destination of the packet is the SR egress node E 370 however, D being the first segment of the path, the DA is set to D 371 IPv6 address. 373 o the SRH is inserted with the segment list consisting of following 374 IPv6 addresses: D, B, S, F, E 376 The SRH contains a source route encoded as a list of segments (D, B, 377 S, F, E). The ingress and egress nodes are identified in the packet 378 respectively by the SA and the last segment of the segment list. 380 The packet P reaches the ingress SR node I. Node I pushes the newly 381 created outer header and SRH with the Segment List as illustrated 382 above (D, B, S, F, E) 384 D is the IPv6 address of node D and it is recognized by all nodes in 385 the SR domain as the forwarding instruction "forward to D according 386 to D route in the IPv6 routing table". The routing table being built 387 through IGPs (OSPF or IS-IS) it is equivalent to say "forward 388 according to shortest path to D". 390 Once at D, the next segment is inspected and executed (segment B). 392 B is an instruction recognized by all the nodes in the SR domain 393 which causes the packet to be forwarded along the shortest path to B. 395 Once at B, the next segment is executed (segment S). 397 S is an instruction only recognized by node B which causes the packet 398 to receive service S. 400 Once the service S is applied, the next segment is executed (segment 401 F) which causes the packet to be forwarded along the shortest path to 402 F. 404 Once at F, the next segment is executed (segment E). 406 E is an instruction recognized by all the nodes in the SR domain 407 which causes the packet to be forwarded along the shortest path to E. 409 E being the destination of the packet, removes the outer header and 410 the SRH. Then, it inspects the inner packet header and forwards the 411 packet accordingly. 413 All of the requirements are met: 415 o First, the packet P has not used links AB and CE: the shortest- 416 path from I to D is I-A-D, the shortest-path from D to B is D-B, 417 the shortest-path from B to F is B-C-F and the shortest-path from 418 F to E is F-E, hence the packet path through the SR domain is 419 I-A-D-B-C-F-E and the links AB and CE have been avoided. 421 o Second, the service S supported by B has been applied on packet P. 423 o Third, any node along the packet path is able to identify the 424 service and topological journey of the packet within the SR domain 425 by inspecting the SRH and SA/DA fields of the packet header. 427 o Fourth, only node I maintains per-flow state for packet P. The 428 entire program of topological and service instructions to be 429 executed by the SR domain on packet P is encoded by the ingress 430 edge router I in the SR header in the form of a list of segments 431 where each segment identifies a specific instruction. No further 432 per-flow state is required along the packet path. Intermediate 433 nodes only hold states related to the global node segments and 434 their local segments. These segments are not per-flow specific 435 and hence scale very well. Typically, an intermediate node would 436 maintain in the order of 100's to 1000's global node segments and 437 in the order of 10's to 100 of local segments. 439 o Fifth, the SR header (and its outer header) is inserted at the 440 entrance to the domain and removed at the exit of the operator 441 domain. For security reasons, the operator can forbid anyone 442 outside its domain to use its intra-domain SR capability (e.g. 443 configuring ACL that deny any packet with a DA towards its 444 infrastructure segment). 446 3. IPv6 Instantiation of Segment Routing 448 3.1. Segment Identifiers (SIDs) 450 Segment Routing, as described in [I-D.ietf-spring-segment-routing], 451 defines Node-SID and Adjacency-SID. When SR is used over IPv6 data- 452 plane the following applies. 454 3.1.1. Node-SID 456 The Node-SID identifies a node. With SR-IPv6 the Node-SID is an IPv6 457 address that the operator configured on the node and that is used as 458 the node identifier. Typically, in case of a router, this is the 459 IPv6 address of the node loopback interface. Therefore, SR-IPv6 does 460 not require any additional SID advertisement for the Node Segment. 461 The Node-SID is in fact the IPv6 address of the node. 463 3.1.2. Adjacency-SID 465 Adjacency-SIDs can be either globally scoped IPv6 addresses or IPv6 466 addresses known locally by the node but not advertised in any control 467 plane (in other words an Adjacency-SID may well be any 128-bit 468 identifier). Obviously, in the latter case, the scope of the 469 Adjacency-SID is local to the router and any packet with the a such 470 Adjacency-SID would need first to reach the node through the node's 471 Segment Identifier (i.e.: Node-SID) prior for the node to process the 472 Adjacency-SID. In other words, two segments (SIDs) would then be 473 required: the first is the node's Node-SID that brings the packet to 474 the node and the second is the Adjacency-SID that will make the node 475 to forward the packet through the interface the Adjacency-SID is 476 allocated to. 478 In the SR architecture defined in [I-D.ietf-spring-segment-routing] a 479 node may advertise one (or more) Adj-SIDs allocated to the same 480 interface as well as a node can advertise the same Adj-SID for 481 multiple interfaces. Use cases of Adj-SID advertisements are 482 described in [I-D.ietf-spring-segment-routing]The semantic of the 483 Adj-SID is: 485 Send out the packet to the interface this Adj-SID is allocated to. 487 Advertisement of Adj-SID may be done using multiple mechanisms among 488 which the ones described in ISIS and OSPF protocol extensions: 489 [I-D.ietf-isis-segment-routing-extensions] and 490 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. The distinction 491 between local and global significance of the Adj-SID is given in the 492 encoding of the Adj-SID advertisement. 494 3.2. Segment Routing Extension Header (SRH) 496 A new type of the Routing Header (originally defined in [RFC2460]) is 497 defined: the Segment Routing Header (SRH) which has a new Routing 498 Type, (suggested value 4) to be assigned by IANA. 500 The Segment Routing Header (SRH) is defined as follows: 502 0 1 2 3 503 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 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | First Segment | Flags | HMAC Key ID | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | | 510 | Segment List[0] (128 bits ipv6 address) | 511 | | 512 | | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | | 515 | | 516 ... 517 | | 518 | | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | | 521 | Segment List[n] (128 bits ipv6 address) | 522 | | 523 | | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | | 526 | Policy List[0] (optional) | 527 | | 528 | | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | | 531 | Policy List[1] (optional) | 532 | | 533 | | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | | 536 | Policy List[2] (optional) | 537 | | 538 | | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | | 541 | Policy List[3] (optional) | 542 | | 543 | | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | | 546 | | 547 | | 548 | HMAC (256 bits) | 549 | (optional) | 550 | | 551 | | 552 | | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 where: 557 o Next Header: 8-bit selector. Identifies the type of header 558 immediately following the SRH. 560 o Hdr Ext Len: 8-bit unsigned integer, is the length of the SRH 561 header in 8-octet units, not including the first 8 octets. 563 o Routing Type: TBD, to be assigned by IANA (suggested value: 4). 565 o Segments Left. Defined in [RFC2460], it contains the index, in 566 the Segment List, of the next segment to inspect. Segments Left 567 is decremented at each segment. 569 o First Segment: contains the index, in the Segment List, of the 570 first segment of the path which is in fact the last element of the 571 Segment List. 573 o Flags: 16 bits of flags. Following flags are defined: 575 1 576 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 |C|P|R|R| Policy Flags | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 C-flag: Clean-up flag. Set when the SRH has to be removed from 582 the packet when packet reaches the last segment. 584 P-flag: Protected flag. Set when the packet has been rerouted 585 through FRR mechanism by a SR endpoint node. 587 R-flags. Reserved and for future use. 589 Policy Flags. Define the type of the IPv6 addresses encoded 590 into the Policy List (see below). The following have been 591 defined: 593 Bits 4-6: determine the type of the first element after the 594 segment list. 596 Bits 7-9: determine the type of the second element. 598 Bits 10-12: determine the type of the third element. 600 Bits 13-15: determine the type of the fourth element. 602 The following values are used for the type: 604 0x0: Not present. If value is set to 0x0, it means the 605 element represented by these bits is not present. 607 0x1: SR Ingress. 609 0x2: SR Egress. 611 0x3: Original Source Address. 613 0x4 to 0x7: currently unused and SHOULD be ignored on 614 reception. 616 o HMAC Key ID and HMAC field, and their use are defined in 617 Section 5. 619 o Segment List[n]: 128 bit IPv6 addresses representing the nth 620 segment in the Segment List. The Segment List is encoded starting 621 from the last segment of the path. I.e., the first element of the 622 segment list (Segment List [0]) contains the last segment of the 623 path while the last segment of the Segment List (Segment List[n]) 624 contains the first segment of the path. The index contained in 625 "Segments Left" identifies the current active segment. 627 o Policy List. Optional addresses representing specific nodes in 628 the SR path such as: 630 SR Ingress: a 128 bit generic identifier representing the 631 ingress in the SR domain (i.e.: it needs not to be a valid IPv6 632 address). 634 SR Egress: a 128 bit generic identifier representing the egress 635 in the SR domain (i.e.: it needs not to be a valid IPv6 636 address). 638 Original Source Address: IPv6 address originally present in the 639 SA field of the packet. 641 The segments in the Policy List are encoded after the segment list 642 and they are optional. If none are in the SRH, all bits of the 643 Policy List Flags MUST be set to 0x0. 645 3.2.1. SRH and RFC2460 behavior 647 The SRH being a new type of the Routing Header, it also has the same 648 properties: 650 SHOULD only appear once in the packet. 652 Only the router whose address is in the DA field of the packet 653 header MUST inspect the SRH. 655 Therefore, Segment Routing in IPv6 networks implies that the segment 656 identifier (i.e.: the IPv6 address of the segment) is moved into the 657 DA of the packet. 659 The DA of the packet changes at each segment termination/completion 660 and therefore the original DA of the packet MUST be encoded as the 661 last segment of the path. 663 As illustrated in Section 2.3, nodes that are within the path of a 664 segment will forward packets based on the DA of the packet without 665 inspecting the SRH. This ensures full interoperability between SR- 666 capable and non-SR-capable nodes. 668 4. SRH Procedures 670 In this section we describe the different procedures on the SRH. 672 4.1. Segment Routing Node Functions 674 SR packets are forwarded to segments endpoints (i.e.: the segment 675 endpoint is the node representing the segment and whose address is in 676 the segment list and in the DA of the packet when traveling in the 677 segment). The segment endpoint, when receiving a SR packet destined 678 to itself, does: 680 o Inspect the SRH. 682 o Determine the next active segment. 684 o Update the Segments Left field (or, if requested, remove the SRH 685 from the packet). 687 o Update the DA. 689 o Forward the packet to the next segment. 691 The procedures applied to the SRH are related to the node function. 692 Following nodes functions are defined: 694 Source SR Node. 696 SR Domain Ingress Node. 698 Transit Node. 700 SR Endpoint Node. 702 4.1.1. Source SR Node 704 A Source SR Node can be any node originating an IPv6 packet with its 705 IPv6 and Segment Routing Headers. This include either: 707 A host originating an IPv6 packet 709 A SR domain ingress router encapsulating a received IPv6 packet 710 into an outer IPv6 header followed by a SRH 712 The mechanism through which a Segment List is derived is outside of 713 the scope of this document. As an example, the Segment List may be 714 obtained through: 716 Local path computation. 718 Local configuration. 720 Interaction with a centralized controller delivering the path. 722 Any other mechanism. 724 The following are the steps of the creation of the SRH: 726 Next Header and Hdr Ext Len fields are set according to [RFC2460]. 728 Routing Type field is set as TBD (SRH). 730 The Segment List is built with the FIRST segment of the path 731 encoded in the LAST element of the Segment List. Subsequent 732 segments are encoded on top of the first segment. Finally, the 733 LAST segment of the path is encoded in the FIRST element of the 734 Segment List. In other words, the Segment List is encoded in the 735 reverse order of the path. 737 The original DA of the packet is encoded as the last segment of 738 the path (encoded in the first element of the Segment List). 740 The DA of the packet is set with the value of the first segment 741 (found in the last element of the segment list). 743 The Segments Left field is set to n-1 where n is the number of 744 elements in the Segment List. 746 The First Segment field is set to n-1 where n is the number of 747 elements in the Segment List. 749 The packet is sent out towards the first segment (i.e.: 750 represented in the packet DA). 752 HMAC and HMAC Key ID may be set according to Section 5. 754 4.1.2. SR Domain Ingress Node 756 The SR Domain Ingress Node is the node where ingress policies are 757 applied and where the packet path (and processing) is determined. 759 After policies are applied and packet classification is done, the 760 result may be instantiated into a Segment List representing the path 761 the packet should take. In such case, the SR Domain Ingress Node 762 instantiate a new outer IPv6 header to which the SRH is appended 763 (with the computed Segment List). The procedures for the creation 764 and insertion of the new SRH are described in Section 4.1.1. 766 4.1.3. Transit Node 768 According to [RFC2460], the only node who is allowed to inspect the 769 Routing Extension Header (and therefore the SRH), is the node 770 corresponding to the DA of the packet. Any other transit node MUST 771 NOT inspect the underneath routing header and MUST forward the packet 772 towards the DA and according to the IPv6 routing table. 774 In the example case described in Section 2.2.2, when SR capable nodes 775 are connected through an overlay spanning multiple third-party 776 infrastructure, it is safe to send SRH packets (i.e.: packet having a 777 Segment Routing Header) between each other overlay/SR-capable nodes 778 as long as the segment list does not include any of the transit 779 provider nodes. In addition, as a generic security measure, any 780 service provider will block any packet destined to one of its 781 internal routers, especially if these packets have an extended header 782 in it. 784 4.1.4. SR Segment Endpoint Node 786 The SR segment endpoint node is the node whose address is in the DA. 787 The segment endpoint node inspects the SRH and does: 789 1. IF DA = myself (segment endpoint) 790 2. IF Segments Left > 0 THEN 791 decrement Segments Left 792 update DA with Segment List[Segments Left] 793 3. IF Segments Left == 0 THEN 794 IF Clean-up bit is set THEN remove the SRH 795 4. ELSE give the packet to next PID (application) 796 End of processing. 797 5. Forward the packet out 799 5. Security Considerations 801 This section analyzes the security threat model, the security issues 802 and mitigation techniques of SRH. 804 SRH is simply another type of the routing header as described in RFC 805 2460 [RFC2460] and is: 807 o added to a new outer IP header by the ingress router when entering 808 the SR domain or by the originating node itself. The source host 809 can be outside the SR domain; 811 o inspected and acted upon when reaching the destination address of 812 the IP header per RFC 2460 [RFC2460]. 814 Per RFC2460 [RFC2460], routers on the path that simply forward an 815 IPv6 packet (i.e. the IPv6 destination address is none of theirs) 816 will never inspect and process the content of any routing header 817 (including SRH). Routers whose one interface IPv6 address equals the 818 destination address field of the IPv6 packet MUST to parse the SRH 819 and, if supported and if the local configuration allows it, MUST act 820 accordingly to the SRH content. 822 According to RFC2460 [RFC2460], non SR-capable (or non SR-configured) 823 router upon receipt of an IPv6 packet with SRH destined to an address 824 of its: 826 o must ignore the SRH completely if the Segment Left field is 0 and 827 proceed to process the next header in the IPv6 packet; 829 o must discard the IPv6 packet if Segment Left field is greater than 830 0 and send a Parameter Problem ICMP message back to the Source 831 Address. 833 5.1. Threat model 835 5.1.1. Source routing threats 837 Using a SRH is a specific case of loose source routing, therefore it 838 has some well-known security issues as described in RFC4942 [RFC4942] 839 section 2.1.1 and RFC5095 [RFC5095]: 841 o amplification attacks: where a packet could be forged in such a 842 way to cause looping among a set of SR-enabled routers causing 843 unnecessary traffic, hence a Denial of Service (DoS) against 844 bandwidth; 846 o reflection attack: where a hacker could force an intermediate node 847 to appear as the immediate attacker, hence hiding the real 848 attacker from naive forensic; 850 o bypass attack: where an intermediate node could be used as a 851 stepping stone (for example in a De-Militarized Zone) to attack 852 another host (for example in the datacenter or any back-end 853 server). 855 5.1.2. Applicability of RFC 5095 to SRH 857 First of all, the reader must remember this specific part of section 858 1 of RFC5095 [RFC5095], "A side effect is that this also eliminates 859 benign RH0 use-cases; however, such applications may be facilitated 860 by future Routing Header specifications.". In short, it is not 861 forbidden to create new secure type of Routing Header; for example, 862 RFC 6554 (RPL) [RFC6554] also creates a new Routing Header type for a 863 specific application confined in a single network. 865 The main use case for SR consists of the single administrative domain 866 (or cooperating administrative domains) where only trusted nodes with 867 SR enabled and explicitely configured participate in SR: this is the 868 same model as in RFC6554 [RFC6554]. All non-trusted nodes do not 869 participate as either SR processing is not enabled by default or 870 because they only process SRH from nodes within their domain. 872 Moreover, all SR routers SHOULD ignore SRH created by outsiders based 873 on topology information (received on a peering or internal interface) 874 or on presence and validity of the HMAC field. Therefore, if 875 intermediate SR routers ONLY act on valid and authorized SRH (such as 876 within a single administrative domain), then there is no security 877 threat similar to RH-0. Hence, the RFC 5095 [RFC5095] attacks are 878 not applicable. 880 5.1.3. Service stealing threat 882 Segment routing is used for added value services, there is also a 883 need to prevent non-participating nodes to use those services; this 884 is called 'service stealing prevention'. 886 5.1.4. Topology disclosure 888 The SRH may also contains IPv6 addresses of some intermediate SR 889 routers in the path towards the destination, this obviously reveals 890 those addresses to the potentially hostile attackers if those 891 attackers are able to intercept packets containing SRH. On the other 892 hand, if the attacker can do a traceroute whose probes will be 893 forwarded along the SR path, then there is little learned by 894 intercepting the SRH itself. The clean-bit of SRH can help by 895 removing the SRH before forwarding the packet to potentially a non- 896 trusted part of the network; if the attacker can force the generation 897 of an ICMP message during the transit in the SR domain, then the ICMP 898 will probably contain the SRH header (totally or partially) depending 899 on the ICMP-generating router behavior. 901 5.1.5. ICMP Generation 903 Per section 4.4 of RFC2460 [RFC2460], when destination nodes (i.e. 904 where the destination address is one of theirs) receive a Routing 905 Header with unsupported Routing Type, the required behavior is: 907 o If Segments Left is zero, the node must ignore the Routing header 908 and proceed to process the next header in the packet. 910 o If Segments Left is non-zero, the node must discard the packet and 911 SHOULD send an ICMP Parameter Problem, Code 0, message to the 912 packet's Source Address, pointing to the unrecognized Routing 913 Type. 915 This required behavior could be used by an attacker to force the 916 generation of ICMP message by any node. The attacker could send 917 packets with SRH (with Segment Left different than 0) destined to a 918 node not supporting SRH. Per RFC2460 [RFC2460], the destination node 919 must then generate an ICMP message per RFC 2460, causing a local CPU 920 utilization and if the source of the offending packet with SRH was 921 spoofed could lead to a reflection attack without any amplification. 923 It must be noted that this is a required behavior for any unsupported 924 Routing Type and not limited to SRH packets. So, it is not specific 925 to SRH and the usual rate limiting for ICMP generation is required 926 anyway for any IPv6 implementation and has been implemented and 927 deployed for many years. 929 5.2. Security fields in SRH 931 This section summarizes the use of specific fields in the SRH. They 932 are based on a key-hashed message authentication code (HMAC). 934 The security-related fields in SRH are: 936 o HMAC Key-id, 8 bits wide; 938 o HMAC, 256 bits wide (optional, exists only if HMAC Key-id is not 939 0). 941 The HMAC field is the output of the HMAC computation (per RFC 2104 942 [RFC2104]) using a pre-shared key and hashing algorithm identified by 943 HMAC Key-id and of the text which consists of the concatenation of: 945 o the source IPv6 address; 947 o First Segment field; 949 o an octet whose bit-0 is the clean-up bit flag and others are 0; 951 o HMAC Key-id; 953 o all addresses in the Segment List. 955 The purpose of the HMAC field is to verify the validity, the 956 integrity and the authorization of the SRH itself. If an outsider of 957 the SR domain does not have access to a current pre-shared secret, 958 then it cannot compute the right HMAC field and the first SR router 959 on the path processing the SRH and configured to check the validity 960 of the HMAC will simply reject the packet. 962 The HMAC field is located at the end of the SRH simply because only 963 the router on the ingress of the SR domain needs to process it, then 964 all other SR nodes can ignore it (based on local policy) because they 965 trust the upstream router. This is to speed up forwarding operations 966 because SR routers which do not validate the SRH do not need to parse 967 the SRH until the end. 969 The HMAC Key-id field allows for the simultaneous existence of 970 several hash algorithms (SHA-256, SHA3-256 ... or future ones) as 971 well as pre-shared keys. This allows for pre-shared key roll-over 972 when two pre-shared keys are supported for a while when all SR nodes 973 converged to a fresher pre-shared key. The HMAC Key-id field is 974 opaque, i.e., it has neither syntax not semantic except as an index 975 to the right combination of pre-shared key and hash algorithm and 976 except that a value of 0 means that there is no HMAC field. It could 977 also allow for interoperation among different SR domains if allowed 978 by local policy and assuming a collision-free Key Id allocation which 979 is out of scope of this memo. 981 When a specific SRH is linked to a time-related service (such as 982 turbo-QoS for a 1-hour period), then it is important to refresh the 983 shared-secret frequently as the HMAC validity period expires only 984 when the HMAC Key-id and its associated shared-secret expires. 986 5.2.1. Selecting a hash algorithm 988 The HMAC field in the SRH is 256 bits wide. Therefore, the HMAC MUST 989 be based on a hash function whose output is at least 256 bits. If 990 the output of the hash function is 256, then this output is simply 991 inserted in the HMAC field. If the output of the hash function is 992 larger than 256 bits, then the output value is truncated to 256 by 993 taking the least-significant 256 bits and inserting them in the HMAC 994 field. 996 SRH implementations can support multiple hash functions but MUST 997 implement SHA-2 [FIPS180-4] in its SHA-256 variant. 999 NOTE: SHA-1 is currently used by some early implementations used for 1000 quick interoperations testing, the 160-bit hash value must then be 1001 right-hand padded with 96 bits set to 0. The authors understand that 1002 this is not secure but is ok for limited tests. 1004 5.2.2. Performance impact of HMAC 1006 While adding a HMAC to each and every SR packet increases the 1007 security, it has a performance impact. Nevertheless, it must be 1008 noted that: 1010 o the HMAC field SHOULD be used only when SRH is inserted by a 1011 device (such as a home set-up box) which is outside of the segment 1012 routing domain. If the SRH is added by a router in the trusted 1013 segment routing domain, then, there is no need for a HMAC field, 1014 hence no performance impact. 1016 o when present, the HMAC field MUST be checked and validated only by 1017 the first router of the segment routing domain, this router is 1018 named 'validating SR router'. Downstream routers may not inspect 1019 the HMAC field. 1021 o this validating router can also have a cache of to improve the performance. It is not the 1023 same use case as in IPsec where HMAC value was unique per packet, 1024 in SRH, the HMAC value is unique per flow. 1026 o Last point, hash functions such as SHA-2 have been optmized for 1027 security and performance and there are multiple implementations 1028 with good performance. 1030 With the above points in mind, the performance impact of using HMAC 1031 is minimized. 1033 5.2.3. Pre-shared key management 1035 The field HMAC Key-id allows for: 1037 o key roll-over: when there is a need to change the key (the hash 1038 pre-shared secret), then multiple pre-shared keys can be used 1039 simultaneously. The validating routing can have a table of for the currently 1041 active and future keys. 1043 o different algorithm: by extending the previous table to , the validating router can 1045 also support simultaneously several hash algorithms (see section 1046 Section 5.2.1) 1048 The pre-shared secret distribution can be done: 1050 o in the configuration of the validating routers, either by static 1051 configuration or any SDN oriented approach; 1053 o dynamically using a trusted key distribution such as [RFC6407] 1055 The intent of this document is NOT to define yet-another-key- 1056 distribution-protocol. 1058 5.3. Deployment Models 1060 5.3.1. Nodes within the SR domain 1062 The routers inside a SR domain can be trusted to generate the outer 1063 IP header and the SRH and to process SRH received on interfaces that 1064 are part of the SR domain. These nodes MUST drop all SRH packets 1065 received on any interface that is not part of the SR domain and 1066 containing a SRH whose HMAC field cannot be validated by local 1067 policies. This includes obviously packet with a SRH generated by a 1068 non-cooperative SR domain. 1070 If the validation fails, then these packets MUST be dropped, ICMP 1071 error messages (parameter problem) SHOULD be generated (but rate 1072 limited) and SHOULD be logged. 1074 5.3.2. Nodes outside of the SR domain 1076 Nodes outside of the SR domain cannot be trusted for physical 1077 security; hence, they need to obtain by some trusted means (outside 1078 of the scope of this document) a complete SRH for each new connection 1079 (i.e. new destination address). The received SRH MUST include a HMAC 1080 Key-id and HMAC field which has been computed correctly (see 1081 Section 5.2). 1083 When a outside the SR domain sends a packet with a SRH and towards a 1084 SR domain ingress node, the packet MUST contain the HMAC Key-id and 1085 HMAC field and the the destination address MUST be an address of a SR 1086 domain ingress node . 1088 The ingress SR router, i.e., the router with an interface address 1089 equals to the destination address, MUST verify the HMAC field with 1090 respect to the HMAC Key-id. 1092 If the validation is successful, then the packet is simply forwarded 1093 as usual for a SR packet. As long as the packet travels within the 1094 SR domain, no further HMAC check needs to be done. Subsequent 1095 routers in the SR domain MAY verify the HMAC field when they process 1096 the SRH (i.e. when they are the destination). 1098 If the validation fails, then this packet MUST be dropped, an ICMP 1099 error message (parameter problem) SHOULD be generated (but rate 1100 limited) and SHOULD be logged. 1102 5.3.3. SR path exposure 1104 As the intermediate SR nodes addresses appears in the SRH, if this 1105 SRH is visible to an outsider then he/she could reuse this knowledge 1106 to launch an attack on the intermediate SR nodes or get some insider 1107 knowledge on the topology. This is especially applicable when the 1108 path between the source node and the first SR domain ingress router 1109 is on the public Internet. 1111 The first remark is to state that 'security by obscurity' is never 1112 enough; in other words, the security policy of the SR domain SHOULD 1113 assume that the internal topology and addressing is known by the 1114 attacker. 1116 IPsec Encapsulating Security Payload [RFC4303] cannot be use to 1117 protect the SRH as per RFC4303 the ESP header must appear after any 1118 routing header (including SRH). 1120 When the SRH is not generated by the actual source node but by an SR 1121 domain ingress router, it is added after a new outer IP header, this 1122 means that a normal traceroute will not reveal the routers in the SR 1123 domain (pretty much like in a MPLS network) and that if ICMP are 1124 generated by routers in the SR domain they will be sent to the 1125 ingress router of the SR domain without revealing anything to the 1126 outside of the SR domain. 1128 To prevent a user to leverage the gained knowledge by intercepting 1129 SRH, it it recommended to apply an infrastructure Access Control List 1130 (iACL) at the edge of the SR domain. This iACL will drop all packets 1131 from outside the SR-domain whose destination is any address of any 1132 router inside the domain. This security policy should be tuned for 1133 local operations. 1135 5.3.4. Impact of BCP-38 1137 BCP-38 [RFC2827], also known as "Network Ingress Filtering", checks 1138 whether the source address of packets received on an interface is 1139 valid for this interface. The use of loose source routing such as 1140 SRH forces packets to follow a path which differs from the expected 1141 routing. Therefore, if BCP-38 was implemented in all routers inside 1142 the SR domain, then SR packets could be received by an interface 1143 which is not expected one and the packets could be dropped. 1145 As a SR domain is usually a subset of one administrative domain, and 1146 as BCP-38 is only deployed at the ingress routers of this 1147 administrative domain and as packets arriving at those ingress 1148 routers have been normally forwarded using the normal routing 1149 information, then there is no reason why this ingress router should 1150 drop the SRH packet based on BCP-38. Routers inside the domain 1151 commonly do not apply BCP-38; so, this is not a problem. 1153 6. IANA Considerations 1155 TBD but should at least require a new type for routing header 1157 7. Manageability Considerations 1159 TBD should we talk about traceroute? about SRH in ICMP replies? 1161 8. Contributors 1163 The authors would like to thank Dave Barach, John Leddy, John 1164 Brzozowski, Pierre Francois, Nagendra Kumar, Mark Townsley, Christian 1165 Martin, Roberta Maglione, James Connolly, Aloys Augustin and Fred 1166 Baker for their contribution to this document. 1168 9. Acknowledgements 1170 TBD 1172 10. References 1174 10.1. Normative References 1176 [FIPS180-4] 1177 National Institute of Standards and Technology, "FIPS 1178 180-4 Secure Hash Standard (SHS)", March 2012, 1179 . 1182 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1183 Requirement Levels", BCP 14, RFC 2119, 1184 DOI 10.17487/RFC2119, March 1997, 1185 . 1187 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1188 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1189 December 1998, . 1191 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1192 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1193 . 1195 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1196 of Type 0 Routing Headers in IPv6", RFC 5095, 1197 DOI 10.17487/RFC5095, December 2007, 1198 . 1200 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 1201 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 1202 October 2011, . 1204 10.2. Informative References 1206 [I-D.ietf-isis-segment-routing-extensions] 1207 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 1208 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 1209 Extensions for Segment Routing", draft-ietf-isis-segment- 1210 routing-extensions-05 (work in progress), June 2015. 1212 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 1213 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1214 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 1215 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 1216 segment-routing-extensions-03 (work in progress), June 1217 2015. 1219 [I-D.ietf-spring-ipv6-use-cases] 1220 Brzozowski, J., Leddy, J., Leung, I., Previdi, S., 1221 Townsley, W., Martin, C., Filsfils, C., and R. Maglione, 1222 "IPv6 SPRING Use Cases", draft-ietf-spring-ipv6-use- 1223 cases-05 (work in progress), September 2015. 1225 [I-D.ietf-spring-problem-statement] 1226 Previdi, S., Filsfils, C., Decraene, B., Litkowski, S., 1227 Horneffer, M., and R. Shakir, "SPRING Problem Statement 1228 and Requirements", draft-ietf-spring-problem-statement-04 1229 (work in progress), April 2015. 1231 [I-D.ietf-spring-resiliency-use-cases] 1232 Francois, P., Filsfils, C., Decraene, B., and R. Shakir, 1233 "Use-cases for Resiliency in SPRING", draft-ietf-spring- 1234 resiliency-use-cases-01 (work in progress), March 2015. 1236 [I-D.ietf-spring-segment-routing] 1237 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 1238 and r. rjs@rob.sh, "Segment Routing Architecture", draft- 1239 ietf-spring-segment-routing-05 (work in progress), 1240 September 2015. 1242 [I-D.ietf-spring-segment-routing-mpls] 1243 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1244 Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., 1245 and E. Crabbe, "Segment Routing with MPLS data plane", 1246 draft-ietf-spring-segment-routing-mpls-01 (work in 1247 progress), May 2015. 1249 [RFC1940] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D. 1250 Zappala, "Source Demand Routing: Packet Format and 1251 Forwarding Specification (Version 1)", RFC 1940, 1252 DOI 10.17487/RFC1940, May 1996, 1253 . 1255 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1256 Hashing for Message Authentication", RFC 2104, 1257 DOI 10.17487/RFC2104, February 1997, 1258 . 1260 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1261 Defeating Denial of Service Attacks which employ IP Source 1262 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1263 May 2000, . 1265 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 1266 Co-existence Security Considerations", RFC 4942, 1267 DOI 10.17487/RFC4942, September 2007, 1268 . 1270 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 1271 Routing Header for Source Routes with the Routing Protocol 1272 for Low-Power and Lossy Networks (RPL)", RFC 6554, 1273 DOI 10.17487/RFC6554, March 2012, 1274 . 1276 Authors' Addresses 1278 Stefano Previdi (editor) 1279 Cisco Systems, Inc. 1280 Via Del Serafico, 200 1281 Rome 00142 1282 Italy 1284 Email: sprevidi@cisco.com 1286 Clarence Filsfils 1287 Cisco Systems, Inc. 1288 Brussels 1289 BE 1291 Email: cfilsfil@cisco.com 1293 Brian Field 1294 Comcast 1295 4100 East Dry Creek Road 1296 Centennial, CO 80122 1297 US 1299 Email: Brian_Field@cable.comcast.com 1300 Ida Leung 1301 Rogers Communications 1302 8200 Dixie Road 1303 Brampton, ON L6T 0C1 1304 CA 1306 Email: Ida.Leung@rci.rogers.com 1308 Jen Linkova 1309 Google 1310 1600 Amphitheatre Parkway 1311 Mountain View, CA 94043 1312 US 1314 Email: furry@google.com 1316 Ebben Aries 1317 Facebook 1318 US 1320 Email: exa@fb.com 1322 Tomoya Kosugi 1323 NTT 1324 3-9-11, Midori-Cho Musashino-Shi, 1325 Tokyo 180-8585 1326 JP 1328 Email: kosugi.tomoya@lab.ntt.co.jp 1330 Eric Vyncke 1331 Cisco Systems, Inc. 1332 De Kleetlaann 6A 1333 Diegem 1831 1334 Belgium 1336 Email: evyncke@cisco.com 1337 David Lebrun 1338 Universite Catholique de Louvain 1339 Place Ste Barbe, 2 1340 Louvain-la-Neuve, 1348 1341 Belgium 1343 Email: david.lebrun@uclouvain.be