idnits 2.17.1 draft-ietf-6man-segment-routing-header-10.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 17, 2018) is 2232 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 434 == Missing Reference: 'SL' is mentioned on line 770, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180-4' == Outdated reference: A later version (-05) exists of draft-bashandy-isis-srv6-extensions-01 == Outdated reference: A later version (-07) exists of draft-filsfils-spring-srv6-network-programming-04 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-15 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-11 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-12 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Previdi 3 Internet-Draft Individual 4 Intended status: Standards Track C. Filsfils, Ed. 5 Expires: September 18, 2018 Cisco Systems, Inc. 6 J. Leddy 7 Comcast 8 S. Matsushima 9 Softbank 10 D. Voyer, Ed. 11 Bell Canada 12 March 17, 2018 14 IPv6 Segment Routing Header (SRH) 15 draft-ietf-6man-segment-routing-header-10 17 Abstract 19 Segment Routing (SR) allows a node to steer a packet through a 20 controlled set of instructions, called segments, by prepending an SR 21 header to the packet. A segment can represent any instruction, 22 topological or service-based. SR allows to enforce a flow through 23 any path (topological, or application/service based) while 24 maintaining per-flow state only at the ingress node to the SR domain. 26 Segment Routing can be applied to the IPv6 data plane with the 27 addition of a new type of Routing Extension Header. This draft 28 describes the Segment Routing Extension Header Type and how it is 29 used by SR capable nodes. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC 2119 [RFC2119]. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on September 18, 2018. 54 Copyright Notice 56 Copyright (c) 2018 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Segment Routing Documents . . . . . . . . . . . . . . . . . . 3 72 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2.1. Data Planes supporting Segment Routing . . . . . . . . . 4 74 2.2. SRv6 Segment . . . . . . . . . . . . . . . . . . . . . . 4 75 2.3. Segment Routing (SR) Domain . . . . . . . . . . . . . . . 5 76 2.3.1. SR Domain in a Service Provider Network . . . . . . . 6 77 2.3.2. SR Domain in a Overlay Network . . . . . . . . . . . 7 78 3. Segment Routing Extension Header (SRH) . . . . . . . . . . . 8 79 3.1. SRH TLVs . . . . . . . . . . . . . . . . . . . . . . . . 10 80 3.1.1. Ingress Node TLV . . . . . . . . . . . . . . . . . . 11 81 3.1.2. Egress Node TLV . . . . . . . . . . . . . . . . . . . 12 82 3.1.3. Opaque Container TLV . . . . . . . . . . . . . . . . 13 83 3.1.4. Padding TLV . . . . . . . . . . . . . . . . . . . . . 13 84 3.1.5. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . 14 85 3.1.6. NSH Carrier TLV . . . . . . . . . . . . . . . . . . . 15 86 3.2. SRH and RFC8200 behavior . . . . . . . . . . . . . . . . 15 87 4. SRH Functions . . . . . . . . . . . . . . . . . . . . . . . . 16 88 4.1. Endpoint Function (End) . . . . . . . . . . . . . . . . . 16 89 4.2. End.X: Endpoint with Layer-3 cross-connect . . . . . . . 17 90 5. SR Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 18 91 5.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 18 92 5.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 19 93 5.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 20 94 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 95 6.1. Threat model . . . . . . . . . . . . . . . . . . . . . . 21 96 6.1.1. Source routing threats . . . . . . . . . . . . . . . 21 97 6.1.2. Applicability of RFC 5095 to SRH . . . . . . . . . . 21 98 6.1.3. Service stealing threat . . . . . . . . . . . . . . . 22 99 6.1.4. Topology disclosure . . . . . . . . . . . . . . . . . 22 100 6.1.5. ICMP Generation . . . . . . . . . . . . . . . . . . . 22 101 6.2. Security fields in SRH . . . . . . . . . . . . . . . . . 23 102 6.2.1. Selecting a hash algorithm . . . . . . . . . . . . . 24 103 6.2.2. Performance impact of HMAC . . . . . . . . . . . . . 24 104 6.2.3. Pre-shared key management . . . . . . . . . . . . . . 25 105 6.3. Deployment Models . . . . . . . . . . . . . . . . . . . . 26 106 6.3.1. Nodes within the SR domain . . . . . . . . . . . . . 26 107 6.3.2. Nodes outside of the SR domain . . . . . . . . . . . 26 108 6.3.3. SR path exposure . . . . . . . . . . . . . . . . . . 27 109 6.3.4. Impact of BCP-38 . . . . . . . . . . . . . . . . . . 27 110 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 111 7.1. Segment Routing Header TLVs Register . . . . . . . . . . 28 112 8. Manageability Considerations . . . . . . . . . . . . . . . . 28 113 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 114 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 115 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 116 11.1. Normative References . . . . . . . . . . . . . . . . . . 29 117 11.2. Informative References . . . . . . . . . . . . . . . . . 29 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 120 1. Segment Routing Documents 122 Segment Routing terminology is defined in 123 [I-D.ietf-spring-segment-routing]. 125 The network programming paradigm 126 [I-D.filsfils-spring-srv6-network-programming] defines the basic 127 functions associated to an SRv6 SID. 129 Segment Routing use cases are described in [RFC7855] 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 an 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 [RFC8200]. 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 [RFC8200]) 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 2.2. SRv6 Segment 173 An SRv6 Segment is a 128-bit value. "SRv6 SID" or simply "SID" are 174 often used as a shorter reference for "SRv6 Segment". 176 An SRv6-capable node N maintains a "My Local SID Table". This table 177 contains all the local SRv6 segments explicitly instantiated at node 178 N. N is the parent node for these SID's. 180 A local SID of N could be an IPv6 address of a local interface of N 181 but it does not have to. Most often, a local SID is not an address 182 of a local interface of N. The My Local SID Table is thus not 183 populated by default with all the addresses of a node. 185 An illustration is provided in 186 [I-D.filsfils-spring-srv6-network-programming]. 188 Every SRv6 local SID instantiated has a specific instruction bounded 189 to it. 191 This information is stored in the "My Local SID Table". The "My 192 Local SID Table" has three main purposes: 194 o Define which local SID's are explicitly instantiated. 196 o Specify which instruction is bound to each of the instantiated 197 SID's. 199 o Store the parameters associated to such instruction (i.e. OIF, 200 NextHop,...). 202 A node may receive a packet with an SRv6 SID in the DA without an 203 SRH. In such case the packet should still be processed by the 204 Segment Routing engine. 206 2.3. Segment Routing (SR) Domain 208 We define the concept of the Segment Routing Domain (SR Domain) as 209 the set of nodes participating into the source based routing model. 210 These nodes may be connected to the same physical infrastructure 211 (e.g.: a Service Provider's network) as well as nodes remotely 212 connected to each other (e.g.: an enterprise VPN or an overlay). 214 A non-exhaustive list of examples of SR Domains is: 216 o The network of an operator, service provider, content provider, 217 enterprise including nodes, links and Autonomous Systems. 219 o A set of nodes connected as an overlay over one or more transit 220 providers. The overlay nodes exchange SR-enabled traffic with 221 segments belonging solely to the overlay routers (the SR domain). 222 None of the segments in the SR-enabled packets exchanged by the 223 overlay belong to the transit networks 225 The source based routing model through its instantiation of the 226 Segment Routing Header (SRH) defined in this document equally applies 227 to all the above examples. 229 It is assumed in this document that the SRH is added to the packet by 230 its source, consistently with the source routing model defined in 231 [RFC8200]. For example: 233 o At the node originating the packet (host, server). 235 o At the ingress node of an SR domain where the ingress node 236 receives an IPv6 packet and encapsulates it into an outer IPv6 237 header followed by a Segment Routing header. 239 2.3.1. SR Domain in a Service Provider Network 241 The following figure illustrates an SR domain consisting of an 242 operator's network infrastructure. 244 (-------------------------- Operator 1 -----------------------) 245 ( ) 246 ( (-----AS 1-----) (-------AS 2-------) (----AS 3-------) ) 247 ( ( ) ( ) ( ) ) 248 A1--(--(--11---13--14-)--(-21---22---23--24-)--(-31---32---34--)--)--Z1 249 ( ( /|\ /|\ /| ) ( |\ /|\ /|\ /| ) ( |\ /|\ /| \ ) ) 250 A2--(--(/ | \/ | \/ | ) ( | \/ | \/ | \/ | ) ( | \/ | \/ | \)--)--Z2 251 ( ( | /\ | /\ | ) ( | /\ | /\ | /\ | ) ( | /\ | /\ | ) ) 252 ( ( |/ \|/ \| ) ( |/ \|/ \|/ \| ) ( |/ \|/ \| ) ) 253 A3--(--(--15---17--18-)--(-25---26---27--28-)--(-35---36---38--)--)--Z3 254 ( ( ) ( ) ( ) ) 255 ( (--------------) (------------------) (---------------) ) 256 ( ) 257 (-------------------------------------------------------------) 259 Figure 1: Service Provider SR Domain 261 Figure 1 describes an operator network including several ASes and 262 delivering connectivity between endpoints. In this scenario, Segment 263 Routing is used within the operator networks and across the ASes 264 boundaries (all being under the control of the same operator). In 265 this case segment routing can be used in order to address use cases 266 such as end-to-end traffic engineering, fast re-route, egress peer 267 engineering, data-center traffic engineering as described in 268 [RFC7855], [I-D.ietf-spring-ipv6-use-cases] and 269 [I-D.ietf-spring-resiliency-use-cases]. 271 Typically, an IPv6 packet received at ingress (i.e.: from outside the 272 SR domain), is classified according to network operator policies and 273 such classification results into an outer header with an SRH applied 274 to the incoming packet. The SRH contains the list of segment 275 representing the path the packet must take inside the SR domain. 276 Thus, the SA of the packet is the ingress node, the DA (due to SRH 277 procedures described in Section 5) is set as the first segment of the 278 path and the last segment of the path is the egress node of the SR 279 domain. 281 The path may include intra-AS as well as inter-AS segments. It has 282 to be noted that all nodes within the SR domain are under control of 283 the same administration. When the packet reaches the egress point of 284 the SR domain, the outer header and its SRH are removed so that the 285 destination of the packet is unaware of the SR domain the packet has 286 traversed. 288 The outer header with the SRH is no different from any other 289 tunneling encapsulation mechanism and allows a network operator to 290 implement traffic engineering mechanisms so to efficiently steer 291 traffic across his infrastructure. 293 2.3.2. SR Domain in a Overlay Network 295 The following figure illustrates an SR domain consisting of an 296 overlay network over multiple operator's networks. 298 (--Operator 1---) (-----Operator 2-----) (--Operator 3---) 299 ( ) ( ) ( ) 300 A1--(--11---13--14--)--(--21---22---23--24--)--(-31---32---34--)--C1 301 ( /|\ /|\ /| ) ( |\ /|\ /|\ /| ) ( |\ /|\ /| \ ) 302 A2--(/ | \/ | \/ | ) ( | \/ | \/ | \/ | ) ( | \/ | \/ | \)--C2 303 ( | /\ | /\ | ) ( | /\ | /\ | /\ | ) ( | /\ | /\ | ) 304 ( |/ \|/ \| ) ( |/ \|/ \|/ \| ) ( |/ \|/ \| ) 305 A3--(--15---17--18--)--(--25---26---27--28--)--(-35---36---38--)--C3 306 ( ) ( | | | ) ( ) 307 (---------------) (--|----|---------|--) (---------------) 308 | | | 309 B1 B2 B3 311 Figure 2: Overlay SR Domain 313 Figure 2 describes an overlay consisting of nodes connected to three 314 different network operators and forming a single overlay network 315 where Segment routing packets are exchanged. 317 The overlay consists of nodes A1, A2, A3, B1, B2, B3, C1, C2 and C3. 318 These nodes are connected to their respective network operator and 319 form an overlay network. 321 Each node may originate packets with an SRH which contains, in the 322 segment list of the SRH or in the DA, segments identifying other 323 overlay nodes. This implies that packets with an SRH may traverse 324 operator's networks but, obviously, these SRHs cannot contain an 325 address/segment of the transit operators 1, 2 and 3. The SRH 326 originated by the overlay can only contain address/segment under the 327 administration of the overlay (e.g. address/segments supported by A1, 328 A2, A3, B1, B2, B3, C1,C2 or C3). 330 In this model, the operator network nodes are transit nodes and, as 331 specified in [RFC8200], MUST NOT inspect the routing extension header 332 since they are not the DA of the packet. 334 It is a common practice in operators networks to filter out, at 335 ingress, any packet whose DA is the address of an internal node and 336 it is also possible that an operator would filter out any packet 337 destined to an internal address and having an extension header in it. 339 This common practice does not impact the SR-enabled traffic between 340 the overlay nodes as the intermediate transit networks never see a 341 destination address belonging to their infrastructure. These SR- 342 enabled overlay packets will thus never be filtered by the transit 343 operators. 345 In all cases, transit packets (i.e.: packets whose DA is outside the 346 domain of the operator's network) will be forwarded accordingly 347 without introducing any security concern in the operator's network. 348 This is similar to tunneled packets. 350 3. Segment Routing Extension Header (SRH) 352 A new type of the Routing Header (originally defined in [RFC8200]) is 353 defined: the Segment Routing Header (SRH) which has a new Routing 354 Type, (suggested value 4) to be assigned by IANA. 356 The Segment Routing Header (SRH) is defined as follows: 358 0 1 2 3 359 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 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Last Entry | Flags | Tag | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | | 366 | Segment List[0] (128 bits IPv6 address) | 367 | | 368 | | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | | 371 | | 372 ... 373 | | 374 | | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | | 377 | Segment List[n] (128 bits IPv6 address) | 378 | | 379 | | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 // // 382 // Optional Type Length Value objects (variable) // 383 // // 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 where: 388 o Next Header: 8-bit selector. Identifies the type of header 389 immediately following the SRH. 391 o Hdr Ext Len: 8-bit unsigned integer, is the length of the SRH 392 header in 8-octet units, not including the first 8 octets. 394 o Routing Type: TBD, to be assigned by IANA (suggested value: 4). 396 o Segments Left. Defined in [RFC8200], it contains the index, in 397 the Segment List, of the next segment to inspect. Segments Left 398 is decremented at each segment. 400 o Last Entry: contains the index, in the Segment List, of the last 401 element of the Segment List. 403 o Flags: 8 bits of flags. Following flags are defined: 405 0 1 2 3 4 5 6 7 406 +-+-+-+-+-+-+-+-+ 407 |U|P|O|A|H| U | 408 +-+-+-+-+-+-+-+-+ 410 U: Unused and for future use. SHOULD be unset on transmission 411 and MUST be ignored on receipt. 413 P-flag: Protected flag. Set when the packet has been rerouted 414 through FRR mechanism by an SR endpoint node. 416 O-flag: OAM flag. When set, it indicates that this packet is 417 an operations and management (OAM) packet. 419 A-flag: Alert flag. If present, it means important Type Length 420 Value (TLV) objects are present. See Section 3.1 for details 421 on TLVs objects. 423 H-flag: HMAC flag. If set, the HMAC TLV is present and is 424 encoded as the last TLV of the SRH. In other words, the last 425 36 octets of the SRH represent the HMAC information. See 426 Section 3.1.5 for details on the HMAC TLV. 428 o Tag: tag a packet as part of a class or group of packets, e.g., 429 packets sharing the same set of properties. 431 o Segment List[n]: 128 bit IPv6 addresses representing the nth 432 segment in the Segment List. The Segment List is encoded starting 433 from the last segment of the path. I.e., the first element of the 434 segment list (Segment List [0]) contains the last segment of the 435 path, the second element contains the penultimate segment of the 436 path and so on. 438 o Type Length Value (TLV) are described in Section 3.1. 440 3.1. SRH TLVs 442 This section defines TLVs of the Segment Routing Header. 444 Type Length Value (TLV) contain optional information that may be used 445 by the node identified in the DA of the packet. It has to be noted 446 that the information carried in the TLVs is not intended to be used 447 by the routing layer. Typically, TLVs carry information that is 448 consumed by other components (e.g.: OAM) than the routing function. 450 Each TLV has its own length, format and semantic. The code-point 451 allocated (by IANA) to each TLV defines both the format and the 452 semantic of the information carried in the TLV. Multiple TLVs may be 453 encoded in the same SRH. 455 The "Length" field of the TLV is primarily used to skip the TLV while 456 inspecting the SRH in case the node doesn't support or recognize the 457 TLV codepoint. The "Length" defines the TLV length in octets and not 458 including the "Type" and "Length" fields. 460 The following TLVs are defined in this document: 462 Ingress Node TLV 464 Egress Node TLV 466 Opaque TLV 468 Padding TLV 470 HMAC TLV 472 NSH Carrier TLV 474 Additional TLVs may be defined in the future. 476 3.1.1. Ingress Node TLV 478 The Ingress Node TLV is optional and identifies the node this packet 479 traversed when entered the SR domain. The Ingress Node TLV has 480 following format: 482 0 1 2 3 483 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 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Type | Length | RESERVED | Flags | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | | 488 | Ingress Node (16 octets) | 489 | | 490 | | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 where: 495 o Type: to be assigned by IANA (suggested value 1). 497 o Length: 18. 499 o RESERVED: 8 bits. SHOULD be unset on transmission and MUST be 500 ignored on receipt. 502 o Flags: 8 bits. No flags are defined in this document. SHOULD be 503 set to 0 on transmission and MUST be ignored on receipt. 505 o Ingress Node: 128 bits. Defines the node where the packet is 506 expected to enter the SR domain. In the encapsulation case 507 described in Section 2.3.1, this information corresponds to the SA 508 of the encapsulating header. 510 3.1.2. Egress Node TLV 512 The Egress Node TLV is optional and identifies the node this packet 513 is expected to traverse when exiting the SR domain. The Egress Node 514 TLV has following format: 516 0 1 2 3 517 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 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Type | Length | RESERVED | Flags | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | | 522 | Egress Node (16 octets) | 523 | | 524 | | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 where: 529 o Type: to be assigned by IANA (suggested value 2). 531 o Length: 18. 533 o RESERVED: 8 bits. SHOULD be unset on transmission and MUST be 534 ignored on receipt. 536 o Flags: 8 bits. No flags are defined in this document. SHOULD be 537 set to 0 on transmission and MUST be ignored on receipt. 539 o Egress Node: 128 bits. Defines the node where the packet is 540 expected to exit the SR domain. In the encapsulation case 541 described in Section 2.3.1, this information corresponds to the 542 last segment of the SRH in the encapsulating header. 544 3.1.3. Opaque Container TLV 546 The Opaque Container TLV is optional and has the following format: 548 0 1 2 3 549 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 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Type | Length | RESERVED | Flags | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | | 554 | Opaque Container (16 octets) | 555 | | 556 | | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 where: 561 o Type: to be assigned by IANA (suggested value 3). 563 o Length: 18. 565 o RESERVED: 8 bits. SHOULD be unset on transmission and MUST be 566 ignored on receipt. 568 o Flags: 8 bits. No flags are defined in this document. SHOULD be 569 set to 0 on transmission and MUST be ignored on receipt. 571 o Opaque Container: 128 bits of opaque data not relevant for the 572 routing layer. Typically, this information is consumed by a non- 573 routing component of the node receiving the packet (i.e.: the node 574 in the DA). 576 3.1.4. Padding TLV 578 The Padding TLV is optional and with the purpose of aligning the SRH 579 on a 8 octet boundary. The Padding TLV has the following format: 581 0 1 2 3 582 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 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Type | Length | Padding (variable) | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 // Padding (variable) // 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 where: 591 o Type: to be assigned by IANA (suggested value 4). 593 o Length: 0 to 7 595 o Padding: from 0 to 7 octets of padding. Padding bits have no 596 semantic. They SHOULD be set to 0 on transmission and MUST be 597 ignored on receipt. 599 The following applies to the Padding TLV: 601 o Padding TLV is optional and MAY only appear once in the SRH. 603 o The Padding TLV is used in order to align the SRH total length on 604 the 8 octet boundary. 606 o When present, the Padding TLV MUST appear as the last TLV before 607 the HMAC TLV (if HMAC TLV is present). 609 o When present, the Padding TLV MUST have a length from 0 to 7 in 610 order to align the SRH total lenght on a 8-octet boundary. 612 o When a router inspecting the SRH encounters the Padding TLV, it 613 MUST assume that no other TLV (other than the HMAC) follow the 614 Padding TLV. 616 3.1.5. HMAC TLV 618 HMAC TLV is optional and contains the HMAC information. The HMAC TLV 619 has the following format: 621 0 1 2 3 622 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 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Type | Length | RESERVED | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | HMAC Key ID (4 octets) | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | // 629 | HMAC (32 octets) // 630 | // 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 where: 635 o Type: to be assigned by IANA (suggested value 5). 637 o Length: 38. 639 o RESERVED: 2 octets. SHOULD be unset on transmission and MUST be 640 ignored on receipt. 642 o HMAC Key ID: 4 octets. 644 o HMAC: 32 octets. 646 o HMAC and HMAC Key ID usage is described in Section 6 648 The Following applies to the HMAC TLV: 650 o When present, the HMAC TLV MUST be encoded as the last TLV of the 651 SRH. 653 o If the HMAC TLV is present, the SRH H-Flag (Figure 4) MUST be set. 655 o When the H-flag is set in the SRH, the router inspecting the SRH 656 MUST find the HMAC TLV in the last 38 octets of the SRH. 658 3.1.6. NSH Carrier TLV 660 The NSH Carrier TLV is a container used in order to carry TLVs that 661 have been defined in [I-D.ietf-sfc-nsh]. The NSH Carrier TLV has the 662 following format: 664 0 1 2 3 665 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 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Type | Length | Flags | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 // NSH Carried Object // 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 where: 673 o Type: to be assigned by IANA (suggested value 6). 675 o Length: the total length of the TLV. 677 o Flags: 8 bits. No flags are defined in this document. SHOULD be 678 set to 0 on transmission and MUST be ignored on receipt. 680 o NSH Carried Object: the content of the TLV which consists of the 681 NSH data as defined in [I-D.ietf-sfc-nsh]. 683 3.2. SRH and RFC8200 behavior 685 The SRH being a new type of the Routing Header, it also has the same 686 properties: 688 SHOULD only appear once in the packet. 690 Only the router whose address is in the DA field of the packet 691 header MUST inspect the SRH. 693 Therefore, Segment Routing in IPv6 networks implies that the segment 694 identifier (i.e.: the IPv6 address of the segment) is moved into the 695 DA of the packet. 697 The DA of the packet changes at each segment termination/completion 698 and therefore the final DA of the packet MUST be encoded as the last 699 segment of the path. 701 4. SRH Functions 703 Segment Routing architecture, as defined in 704 [I-D.ietf-spring-segment-routing] defines a segment as an instruction 705 or, more generally, a set of instructions (function). 707 [I-D.filsfils-spring-srv6-network-programming] defines the basic 708 functions associated with SRv6 SID's. 710 In this section we review two of these functions that may be 711 associated to a segment: 713 o End: the endpoint (End) function is the base of the source routing 714 paradigm. It consists of updating the DA with the next segment 715 and forward the packet accordingly. 717 o End.X: The endpoint layer-3 cross-connect function. 719 More functions are defined in 720 [I-D.filsfils-spring-srv6-network-programming]. 722 4.1. Endpoint Function (End) 724 The Endpoint function (End) is the most basic function. 726 When the endpoint node receives a packet destined to DA "S" and S is 727 an entry in the MyLocalSID table and the function associated with S 728 in that entry is "End" then the endpoint does: 730 1. IF SegmentsLeft > 0 THEN 731 2. decrement SL 732 3. update the IPv6 DA with SRH[SL] 733 4. FIB lookup on updated DA 734 5. forward accordingly to the matched entry 735 6. ELSE 736 7. drop the packet 737 It has to be noted that: 739 o The End function performs the FIB lookup in the forwarding table 740 of the ingress interface. 742 o If the FIB lookup matches a multicast state, then the related 743 Reverse Path Forwarding (RPF) check must be considered successful. 745 o An SRv6-capable node MUST include the FlowLabel of the IPv6 header 746 in its hash computation for ECMP load-balancing. 748 o By default, a local SID bound to the End function does not allow 749 the decapsulation of an outer header. As a consequence, an End 750 SID cannot be the last SID of an SRH and cannot be the DA of a 751 packet without SRH. 753 o If the decapsulation is desired, then another function must be 754 bound to the SID (e.g., End.DX6 defined in 755 [I-D.filsfils-spring-srv6-network-programming]). This prevents 756 any unintentional decapsulation by the segment endpoint node. The 757 details of the advertisement of a SID in the control plane are 758 outside the scope of this document (e.g., 759 [I-D.previdi-idr-segment-routing-te-policy], 760 [I-D.dawra-bgp-srv6-vpn] and [I-D.bashandy-isis-srv6-extensions]. 762 4.2. End.X: Endpoint with Layer-3 cross-connect 764 When the endpoint node receives a packet destined to DA "S" and S is 765 an entry in the MyLocalSID table and the function associated with S 766 in that entry is "End.X" then the endpoint does: 768 1. IF SegmentsLeft > 0 THEN 769 2. decrement SL 770 3. update the IPv6 DA with SRH[SL] 771 4. forward to layer-3 adjacency bound to the SID "S" 772 5. ELSE 773 6. drop the packet 775 It has to be noted that: 777 o If an array of layer-3 adjacencies is bound to the End.X SID, then 778 one entry of the array is selected based on a hash of the packet's 779 header (at least SA, DA, Flow Label). 781 o An End.X function does not allow decaps. An End.X SID cannot be 782 the last SID of an SRH and cannot be the DA of a packet without 783 SRH. 785 o The End.X function is required to express any traffic-engineering 786 policy. 788 o The End.X function is the SRv6 instantiation of a Adjacency SID as 789 defined in [I-D.ietf-spring-segment-routing]. 791 o Note that with SR-MPLS ([I-D.ietf-spring-segment-routing-mpls]), 792 an AdjSID is typically preceded by a PrefixSID. This is unlikely 793 in SRv6 as most likely an End.X SID is globally routed address of 794 N. 796 o If a node N has 30 outgoing interfaces to 30 neighbors, usually 797 the operator would explicitly instantiate 30 End.X SID's at N: one 798 per layer-3 adjacency to a neighbor. Potentially, more End.X 799 could be explicitly defined (groups of layer-3 adjacencies to the 800 same neighbor or to different neighbors). 802 o If node N has a bundle outgoing interface I to a neighbor Q made 803 of 10 member links, N may allocate up to 11 End.X local SID's for 804 that bundle: one for the bundle itself and then up to one for each 805 member link. This is the equivalent of the L2-Link Adj SID in SR- 806 MPLS ([I-D.ietf-isis-l2bundles]). 808 5. SR Nodes 810 There are different types of nodes that may be involved in segment 811 routing networks: source nodes that originate packets with an SRH, 812 transit nodes that forward packets having an SRH and segment endpoint 813 nodes that MUST process the SRH. 815 5.1. Source SR Node 817 A Source SR Node can be any node originating an IPv6 packet with its 818 IPv6 and Segment Routing Headers. This include either: 820 A host originating an IPv6 packet. 822 An SR domain ingress router encapsulating a received IPv6 packet 823 into an outer IPv6 header followed by an SRH. 825 The mechanism through which a Segment List is derived is outside of 826 the scope of this document. As an example, the Segment List may be 827 obtained through: 829 Local path computation. 831 Local configuration. 833 Interaction with a centralized controller delivering the path. 835 Any other mechanism. 837 The following are the steps of the creation of the SRH: 839 Next Header and Hdr Ext Len fields are set as specified in 840 [RFC8200]. 842 Routing Type field is set as TBD (to be allocated by IANA, 843 suggested value 4). 845 The DA of the packet is set with the value of the first segment. 846 ). 848 The first element of the segment list is the last segment (the 849 final DA of the packet). The second element is the penultimate 850 segment and so on. 852 In other words, the Segment List is encoded in the reverse order 853 of the path. 855 The Segments Left field is set to n-1 where n is the number of 856 elements in the Segment List. 858 The Last_Entry field is set to n-1 where n is the number of 859 elements in the Segment List. 861 The packet is sent out towards the packet's DA (the first 862 segment). 864 HMAC TLV may be set according to Section 6. 866 If the segment list contains a single segment and there is no need 867 for information in flag or TLV, then the SRH MAY be omitted. 869 5.2. Transit Node 871 As specified in [RFC8200], the only node who is allowed to inspect 872 the Routing Extension Header (and therefore the SRH), is the node 873 corresponding to the DA of the packet. Any other transit node MUST 874 NOT inspect the underneath routing header and MUST forward the packet 875 towards the DA and according to the IPv6 routing table. 877 In the example case described in Section 2.3.2, when SR capable nodes 878 are connected through an overlay spanning multiple third-party 879 infrastructure, it is safe to send SRH packets (i.e.: packet having a 880 Segment Routing Header) between each other overlay/SR-capable nodes 881 as long as the segment list does not include any of the transit 882 provider nodes. In addition, as a generic security measure, any 883 service provider will block any packet destined to one of its 884 internal routers, especially if these packets have an extended header 885 in it. 887 5.3. SR Segment Endpoint Node 889 The SR segment endpoint node is the node whose MyLocalSID table 890 contains an entry for the DA of the packet. 892 The segment endpoint node executes the function bound to the SID as 893 per the matched MyLocalSID entry (Section 4). 895 6. Security Considerations 897 This section analyzes the security threat model, the security issues 898 and proposed solutions related to the new Segment Routing Header. 900 The Segment Routing Header (SRH) is simply another type of the 901 routing header as described in RFC 8200 [RFC8200] and is: 903 o Added by an SR edge router when entering the segment routing 904 domain or by the originating host itself. The source host can 905 even be outside the SR domain; 907 o inspected and acted upon when reaching the destination address of 908 the IP header per RFC 8200 [RFC8200]. 910 Per RFC8200 [RFC8200], routers on the path that simply forward an 911 IPv6 packet (i.e. the IPv6 destination address is none of theirs) 912 will never inspect and process the content of the SRH. Routers whose 913 one interface IPv6 address equals the destination address field of 914 the IPv6 packet MUST parse the SRH and, if supported and if the local 915 configuration allows it, MUST act accordingly to the SRH content. 917 As specified in RFC8200 [RFC8200], the default behavior of a non SR- 918 capable router upon receipt of an IPv6 packet with SRH destined to an 919 address of its, is to: 921 o ignore the SRH completely if the Segment Left field is 0 and 922 proceed to process the next header in the IPv6 packet; 924 o discard the IPv6 packet if Segment Left field is greater than 0, 925 it MAY send a Parameter Problem ICMP message back to the Source 926 Address. 928 6.1. Threat model 930 6.1.1. Source routing threats 932 Using an SRH is similar to source routing, therefore it has some 933 well-known security issues as described in RFC4942 [RFC4942] section 934 2.1.1 and RFC5095 [RFC5095]: 936 o amplification attacks: where a packet could be forged in such a 937 way to cause looping among a set of SR-enabled routers causing 938 unnecessary traffic, hence a Denial of Service (DoS) against 939 bandwidth; 941 o reflection attack: where a hacker could force an intermediate node 942 to appear as the immediate attacker, hence hiding the real 943 attacker from naive forensic; 945 o bypass attack: where an intermediate node could be used as a 946 stepping stone (for example in a De-Militarized Zone) to attack 947 another host (for example in the datacenter or any back-end 948 server). 950 6.1.2. Applicability of RFC 5095 to SRH 952 First of all, the reader must remember this specific part of section 953 1 of RFC5095 [RFC5095], "A side effect is that this also eliminates 954 benign RH0 use-cases; however, such applications may be facilitated 955 by future Routing Header specifications.". In short, it is not 956 forbidden to create new secure type of Routing Header; for example, 957 RFC 6554 (RPL) [RFC6554] also creates a new Routing Header type for a 958 specific application confined in a single network. 960 In the segment routing architecture described in 961 [I-D.ietf-spring-segment-routing] there are basically two kinds of 962 nodes (routers and hosts): 964 o nodes within the SR domain, which is within one single 965 administrative domain, i.e., where all nodes are trusted anyway 966 else the damage caused by those nodes could be worse than 967 amplification attacks: traffic interception, man-in-the-middle 968 attacks, more server DoS by dropping packets, and so on. 970 o nodes outside of the SR domain, which is outside of the 971 administrative segment routing domain hence they cannot be trusted 972 because there is no physical security for those nodes, i.e., they 973 can be replaced by hostile nodes or can be coerced in wrong 974 behaviors. 976 The main use case for SR consists of the single administrative domain 977 where only trusted nodes with SR enabled and configured participate 978 in SR: this is the same model as in RFC6554 [RFC6554]. All non- 979 trusted nodes do not participate as either SR processing is not 980 enabled by default or because they only process SRH from nodes within 981 their domain. 983 Moreover, all SR nodes ignore SRH created by outsiders based on 984 topology information (received on a peering or internal interface) or 985 on presence and validity of the HMAC field. Therefore, if 986 intermediate nodes ONLY act on valid and authorized SRH (such as 987 within a single administrative domain), then there is no security 988 threat similar to RH-0. Hence, the RFC 5095 [RFC5095] attacks are 989 not applicable. 991 6.1.3. Service stealing threat 993 Segment routing is used for added value services, there is also a 994 need to prevent non-participating nodes to use those services; this 995 is called 'service stealing prevention'. 997 6.1.4. Topology disclosure 999 The SRH may also contains IPv6 addresses of some intermediate SR- 1000 nodes in the path towards the destination, this obviously reveals 1001 those addresses to the potentially hostile attackers if those 1002 attackers are able to intercept packets containing SRH. On the other 1003 hand, if the attacker can do a traceroute whose probes will be 1004 forwarded along the SR path, then there is little learned by 1005 intercepting the SRH itself. 1007 6.1.5. ICMP Generation 1009 Per section 4.4 of RFC8200 [RFC8200], when destination nodes (i.e. 1010 where the destination address is one of theirs) receive a Routing 1011 Header with unsupported Routing Type, the required behavior is: 1013 o If Segments Left is zero, the node must ignore the Routing header 1014 and proceed to process the next header in the packet. 1016 o If Segments Left is non-zero, the node must discard the packet and 1017 send an ICMP Parameter Problem, Code 0, message to the packet's 1018 Source Address, pointing to the unrecognized Routing Type. 1020 This required behavior could be used by an attacker to force the 1021 generation of ICMP message by any node. The attacker could send 1022 packets with SRH (with Segment Left set to 0) destined to a node not 1023 supporting SRH. Per RFC8200 [RFC8200], the destination node could 1024 generate an ICMP message, causing a local CPU utilization and if the 1025 source of the offending packet with SRH was spoofed could lead to a 1026 reflection attack without any amplification. 1028 It must be noted that this is a required behavior for any unsupported 1029 Routing Type and not limited to SRH packets. So, it is not specific 1030 to SRH and the usual rate limiting for ICMP generation is required 1031 anyway for any IPv6 implementation and has been implemented and 1032 deployed for many years. 1034 6.2. Security fields in SRH 1036 This section summarizes the use of specific fields in the SRH. They 1037 are based on a key-hashed message authentication code (HMAC). 1039 The security-related fields in the SRH are instantiated by the HMAC 1040 TLV, containing: 1042 o HMAC Key-id, 32 bits wide; 1044 o HMAC, 256 bits wide (optional, exists only if HMAC Key-id is not 1045 0). 1047 The HMAC field is the output of the HMAC computation (per RFC 2104 1048 [RFC2104]) using a pre-shared key identified by HMAC Key-id and of 1049 the text which consists of the concatenation of: 1051 o the source IPv6 address; 1053 o Last Entry field; 1055 o an octet of bit flags; 1057 o HMAC Key-id; 1059 o all addresses in the Segment List. 1061 The purpose of the HMAC TLV is to verify the validity, the integrity 1062 and the authorization of the SRH itself. If an outsider of the SR 1063 domain does not have access to a current pre-shared secret, then it 1064 cannot compute the right HMAC field and the first SR router on the 1065 path processing the SRH and configured to check the validity of the 1066 HMAC will simply reject the packet. 1068 The HMAC TLV is located at the end of the SRH simply because only the 1069 router on the ingress of the SR domain needs to process it, then all 1070 other SR nodes can ignore it (based on local policy) because they 1071 trust the upstream router. This is to speed up forwarding operations 1072 because SR routers which do not validate the SRH do not need to parse 1073 the SRH until the end. 1075 The HMAC Key-id field allows for the simultaneous existence of 1076 several hash algorithms (SHA-256, SHA3-256 ... or future ones) as 1077 well as pre-shared keys. The HMAC Key-id field is opaque, i.e., it 1078 has neither syntax nor semantic except as an index to the right 1079 combination of pre-shared key and hash algorithm and except that a 1080 value of 0 means that there is no HMAC field. Having an HMAC Key-id 1081 field allows for pre-shared key roll-over when two pre-shared keys 1082 are supported for a while when all SR nodes converged to a fresher 1083 pre-shared key. It could also allow for interoperation among 1084 different SR domains if allowed by local policy and assuming a 1085 collision-free HMAC Key Id allocation. 1087 When a specific SRH is linked to a time-related service (such as 1088 turbo-QoS for a 1-hour period) where the DA, Segment ID (SID) are 1089 identical, then it is important to refresh the shared-secret 1090 frequently as the HMAC validity period expires only when the HMAC 1091 Key-id and its associated shared-secret expires. 1093 6.2.1. Selecting a hash algorithm 1095 The HMAC field in the HMAC TLV is 256 bit wide. Therefore, the HMAC 1096 MUST be based on a hash function whose output is at least 256 bits. 1097 If the output of the hash function is 256, then this output is simply 1098 inserted in the HMAC field. If the output of the hash function is 1099 larger than 256 bits, then the output value is truncated to 256 by 1100 taking the least-significant 256 bits and inserting them in the HMAC 1101 field. 1103 SRH implementations can support multiple hash functions but MUST 1104 implement SHA-2 [FIPS180-4] in its SHA-256 variant. 1106 NOTE: SHA-1 is currently used by some early implementations used for 1107 quick interoperations testing, the 160-bit hash value must then be 1108 right-hand padded with 96 bits set to 0. The authors understand that 1109 this is not secure but is ok for limited tests. 1111 6.2.2. Performance impact of HMAC 1113 While adding an HMAC to each and every SR packet increases the 1114 security, it has a performance impact. Nevertheless, it must be 1115 noted that: 1117 o the HMAC field is used only when SRH is added by a device (such as 1118 a home set-up box) which is outside of the segment routing domain. 1119 If the SRH is added by a router in the trusted segment routing 1120 domain, then, there is no need for an HMAC field, hence no 1121 performance impact. 1123 o when present, the HMAC field MUST only be checked and validated by 1124 the first router of the segment routing domain, this router is 1125 named 'validating SR router'. Downstream routers may not inspect 1126 the HMAC field. 1128 o this validating router can also have a cache of to improve the performance. It is not the 1130 same use case as in IPsec where HMAC value was unique per packet, 1131 in SRH, the HMAC value is unique per flow. 1133 o Last point, hash functions such as SHA-2 have been optimized for 1134 security and performance and there are multiple implementations 1135 with good performance. 1137 With the above points in mind, the performance impact of using HMAC 1138 is minimized. 1140 6.2.3. Pre-shared key management 1142 The field HMAC Key-id allows for: 1144 o key roll-over: when there is a need to change the key (the hash 1145 pre-shared secret), then multiple pre-shared keys can be used 1146 simultaneously. The validating routing can have a table of for the currently active and future 1148 keys. 1150 o different algorithms: by extending the previous table to , the validating router 1152 can also support simultaneously several hash algorithms (see 1153 section Section 6.2.1) 1155 The pre-shared secret distribution can be done: 1157 o in the configuration of the validating routers, either by static 1158 configuration or any SDN oriented approach; 1160 o dynamically using a trusted key distribution such as [RFC6407] 1162 The intent of this document is NOT to define yet-another-key- 1163 distribution-protocol. 1165 6.3. Deployment Models 1167 6.3.1. Nodes within the SR domain 1169 An SR domain is defined as a set of interconnected routers where all 1170 routers at the perimeter are configured to add and act on SRH. Some 1171 routers inside the SR domain can also act on SRH or simply forward 1172 IPv6 packets. 1174 The routers inside an SR domain can be trusted to generate SRH and to 1175 process SRH received on interfaces that are part of the SR domain. 1176 These nodes MUST drop all SRH packets received on an interface that 1177 is not part of the SR domain and containing an SRH whose HMAC field 1178 cannot be validated by local policies. This includes obviously 1179 packet with an SRH generated by a non-cooperative SR domain. 1181 If the validation fails, then these packets MUST be dropped, ICMP 1182 error messages (parameter problem) SHOULD be generated (but rate 1183 limited) and SHOULD be logged. 1185 6.3.2. Nodes outside of the SR domain 1187 Nodes outside of the SR domain cannot be trusted for physical 1188 security; hence, they need to request by some trusted means (outside 1189 of the scope of this document) a complete SRH for each new connection 1190 (i.e. new destination address). The received SRH MUST include an 1191 HMAC TLV which is computed correctly (see Section 6.2). 1193 When an outside node sends a packet with an SRH and towards an SR 1194 domain ingress node, the packet MUST contain the HMAC TLV (with a 1195 Key-id and HMAC fields) and the the destination address MUST be an 1196 address of an SR domain ingress node . 1198 The ingress SR router, i.e., the router with an interface address 1199 equals to the destination address, MUST verify the HMAC TLV. 1201 If the validation is successful, then the packet is simply forwarded 1202 as usual for an SR packet. As long as the packet travels within the 1203 SR domain, no further HMAC check needs to be done. Subsequent 1204 routers in the SR domain MAY verify the HMAC TLV when they process 1205 the SRH (i.e. when they are the destination). 1207 If the validation fails, then this packet MUST be dropped, an ICMP 1208 error message (parameter problem) SHOULD be generated (but rate 1209 limited) and SHOULD be logged. 1211 6.3.3. SR path exposure 1213 As the intermediate SR nodes addresses appears in the SRH, if this 1214 SRH is visible to an outsider then he/she could reuse this knowledge 1215 to launch an attack on the intermediate SR nodes or get some insider 1216 knowledge on the topology. This is especially applicable when the 1217 path between the source node and the first SR domain ingress router 1218 is on the public Internet. 1220 The first remark is to state that 'security by obscurity' is never 1221 enough; in other words, the security policy of the SR domain MUST 1222 assume that the internal topology and addressing is known by the 1223 attacker. A simple traceroute will also give the same information 1224 (with even more information as all intermediate nodes between SID 1225 will also be exposed). IPsec Encapsulating Security Payload 1226 [RFC4303] cannot be use to protect the SRH as per RFC4303 the ESP 1227 header must appear after any routing header (including SRH). 1229 To prevent a user to leverage the gained knowledge by intercepting 1230 SRH, it it recommended to apply an infrastructure Access Control List 1231 (iACL) at the edge of the SR domain. This iACL will drop all packets 1232 from outside the SR-domain whose destination is any address of any 1233 router inside the domain. This security policy should be tuned for 1234 local operations. 1236 6.3.4. Impact of BCP-38 1238 BCP-38 [RFC2827], also known as "Network Ingress Filtering", checks 1239 whether the source address of packets received on an interface is 1240 valid for this interface. The use of loose source routing such as 1241 SRH forces packets to follow a path which differs from the expected 1242 routing. Therefore, if BCP-38 was implemented in all routers inside 1243 the SR domain, then SR packets could be received by an interface 1244 which is not expected one and the packets could be dropped. 1246 As an SR domain is usually a subset of one administrative domain, and 1247 as BCP-38 is only deployed at the ingress routers of this 1248 administrative domain and as packets arriving at those ingress 1249 routers have been normally forwarded using the normal routing 1250 information, then there is no reason why this ingress router should 1251 drop the SRH packet based on BCP-38. Routers inside the domain 1252 commonly do not apply BCP-38; so, this is not a problem. 1254 7. IANA Considerations 1256 This document makes the following registrations in the Internet 1257 Protocol Version 6 (IPv6) Parameters "Routing Type" registry 1258 maintained by IANA: 1260 Suggested Description Reference 1261 Value 1262 ---------------------------------------------------------- 1263 4 Segment Routing Header (SRH) This document 1265 This document request IANA to create and maintain a new Registry: 1266 "Segment Routing Header TLVs" 1268 7.1. Segment Routing Header TLVs Register 1270 This document requests the creation of a new IANA managed registry to 1271 identify SRH TLVs. The registration procedure is "Expert Review" as 1272 defined in [RFC8126]. Suggested registry name is "Segment Routing 1273 Header TLVs". A TLV is identified through an unsigned 8 bit 1274 codepoint value. The following codepoints are defined in this 1275 document: 1277 Suggested Description Reference 1278 Value 1279 ----------------------------------------------------- 1280 1 Ingress Node TLV This document 1281 2 Egress Node TLV This document 1282 3 Opaque Container TLV This document 1283 4 Padding TLV This document 1284 5 HMAC TLV This document 1285 6 NSH Carrier TLV This document 1287 8. Manageability Considerations 1289 TBD 1291 9. Contributors 1293 Kamran Raza, Darren Dukes, Brian Field, Daniel Bernier, Ida Leung, 1294 Jen Linkova, Ebben Aries, Tomoya Kosugi, Eric Vyncke, David Lebrun, 1295 Dirk Steinberg, Robert Raszuk, Dave Barach, John Brzozowski, Pierre 1296 Francois, Nagendra Kumar, Mark Townsley, Christian Martin, Roberta 1297 Maglione, James Connolly, Aloys Augustin contributed to the content 1298 of this document. 1300 10. Acknowledgements 1302 The authors would like to thank Ole Troan, Bob Hinden, Fred Baker, 1303 Brian Carpenter, Alexandru Petrescu, Punit Kumar Jaiswal, and David 1304 Lebrun for their comments to this document. 1306 11. References 1308 11.1. Normative References 1310 [FIPS180-4] 1311 National Institute of Standards and Technology, "FIPS 1312 180-4 Secure Hash Standard (SHS)", March 2012, 1313 . 1316 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1317 Requirement Levels", BCP 14, RFC 2119, 1318 DOI 10.17487/RFC2119, March 1997, 1319 . 1321 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1322 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1323 . 1325 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1326 of Type 0 Routing Headers in IPv6", RFC 5095, 1327 DOI 10.17487/RFC5095, December 2007, 1328 . 1330 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 1331 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 1332 October 2011, . 1334 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1335 (IPv6) Specification", STD 86, RFC 8200, 1336 DOI 10.17487/RFC8200, July 2017, 1337 . 1339 11.2. Informative References 1341 [I-D.bashandy-isis-srv6-extensions] 1342 Ginsberg, L., Bashandy, A., Filsfils, C., and B. Decraene, 1343 "IS-IS Extensions to Support Routing over IPv6 Dataplane", 1344 draft-bashandy-isis-srv6-extensions-01 (work in progress), 1345 September 2017. 1347 [I-D.dawra-bgp-srv6-vpn] 1348 (Unknown), (., Dawra, G., Filsfils, C., Dukes, D., 1349 Brissette, P., Camarillo, P., Leddy, J., 1350 daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., 1351 Steinberg, D., Raszuk, R., Decraene, B., and S. 1352 Matsushima, "BGP Signaling of IPv6-Segment-Routing-based 1353 VPN Networks", draft-dawra-bgp-srv6-vpn-00 (work in 1354 progress), March 2017. 1356 [I-D.filsfils-spring-srv6-network-programming] 1357 Filsfils, C., Li, Z., Leddy, J., daniel.voyer@bell.ca, d., 1358 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 1359 Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., 1360 Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., and 1361 M. Sharif, "SRv6 Network Programming", draft-filsfils- 1362 spring-srv6-network-programming-04 (work in progress), 1363 March 2018. 1365 [I-D.ietf-isis-l2bundles] 1366 Ginsberg, L., Bashandy, A., Filsfils, C., Nanduri, M., and 1367 E. Aries, "Advertising L2 Bundle Member Link Attributes in 1368 IS-IS", draft-ietf-isis-l2bundles-07 (work in progress), 1369 May 2017. 1371 [I-D.ietf-isis-segment-routing-extensions] 1372 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 1373 Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, 1374 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 1375 segment-routing-extensions-15 (work in progress), December 1376 2017. 1378 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 1379 Psenak, P., Filsfils, C., Previdi, S., Gredler, H., 1380 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 1381 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 1382 segment-routing-extensions-11 (work in progress), January 1383 2018. 1385 [I-D.ietf-sfc-nsh] 1386 Quinn, P., Elzur, U., and C. Pignataro, "Network Service 1387 Header (NSH)", draft-ietf-sfc-nsh-28 (work in progress), 1388 November 2017. 1390 [I-D.ietf-spring-ipv6-use-cases] 1391 Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R., and 1392 M. Townsley, "IPv6 SPRING Use Cases", draft-ietf-spring- 1393 ipv6-use-cases-12 (work in progress), December 2017. 1395 [I-D.ietf-spring-resiliency-use-cases] 1396 Filsfils, C., Previdi, S., Decraene, B., and R. Shakir, 1397 "Resiliency use cases in SPRING networks", draft-ietf- 1398 spring-resiliency-use-cases-12 (work in progress), 1399 December 2017. 1401 [I-D.ietf-spring-segment-routing] 1402 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 1403 Litkowski, S., and R. Shakir, "Segment Routing 1404 Architecture", draft-ietf-spring-segment-routing-15 (work 1405 in progress), January 2018. 1407 [I-D.ietf-spring-segment-routing-mpls] 1408 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 1409 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1410 data plane", draft-ietf-spring-segment-routing-mpls-12 1411 (work in progress), February 2018. 1413 [I-D.previdi-idr-segment-routing-te-policy] 1414 Previdi, S., Filsfils, C., Mattes, P., Rosen, E., and S. 1415 Lin, "Advertising Segment Routing Policies in BGP", draft- 1416 previdi-idr-segment-routing-te-policy-07 (work in 1417 progress), June 2017. 1419 [RFC1940] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D. 1420 Zappala, "Source Demand Routing: Packet Format and 1421 Forwarding Specification (Version 1)", RFC 1940, 1422 DOI 10.17487/RFC1940, May 1996, 1423 . 1425 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1426 Hashing for Message Authentication", RFC 2104, 1427 DOI 10.17487/RFC2104, February 1997, 1428 . 1430 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1431 Defeating Denial of Service Attacks which employ IP Source 1432 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1433 May 2000, . 1435 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 1436 Co-existence Security Considerations", RFC 4942, 1437 DOI 10.17487/RFC4942, September 2007, 1438 . 1440 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 1441 Routing Header for Source Routes with the Routing Protocol 1442 for Low-Power and Lossy Networks (RPL)", RFC 6554, 1443 DOI 10.17487/RFC6554, March 2012, 1444 . 1446 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 1447 Litkowski, S., Horneffer, M., and R. Shakir, "Source 1448 Packet Routing in Networking (SPRING) Problem Statement 1449 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 1450 2016, . 1452 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1453 Writing an IANA Considerations Section in RFCs", BCP 26, 1454 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1455 . 1457 Authors' Addresses 1459 Stefano Previdi 1460 Individual 1461 Italy 1463 Email: stefano@previdi.net 1465 Clarence Filsfils (editor) 1466 Cisco Systems, Inc. 1467 Brussels 1468 BE 1470 Email: cfilsfil@cisco.com 1472 John Leddy 1473 Comcast 1474 4100 East Dry Creek Road 1475 Centennial, CO 80122 1476 US 1478 Email: John_Leddy@comcast.com 1480 Satoru Matsushima 1481 Softbank 1483 Email: satoru.matsushima@g.softbank.co.jp 1484 Daniel Voyer (editor) 1485 Bell Canada 1487 Email: daniel.voyer@bell.ca