idnits 2.17.1 draft-ietf-6man-segment-routing-header-06.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 -- Couldn't find a document date in the document -- date freshness check skipped. 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 453 == Missing Reference: 'SL' is mentioned on line 791, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180-4' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-05) exists of draft-bashandy-isis-srv6-extensions-00 == Outdated reference: A later version (-07) exists of draft-filsfils-spring-srv6-network-programming-00 == Outdated reference: A later version (-07) exists of draft-ietf-isis-l2bundles-03 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-11 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-09 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-12 == Outdated reference: A later version (-12) exists of draft-ietf-spring-ipv6-use-cases-09 == Outdated reference: A later version (-12) exists of draft-ietf-spring-resiliency-use-cases-08 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-11 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-08 == Outdated reference: A later version (-07) exists of draft-previdi-idr-segment-routing-te-policy-05 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 13 warnings (==), 4 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 K. Raza 5 Expires: September 14, 2017 D. Dukes 6 Cisco Systems, Inc. 7 J. Leddy 8 B. Field 9 Comcast 10 D. Voyer 11 D. Bernier 12 Bell Canada 13 S. Matsushima 14 Softbank 15 I. Leung 16 Rogers Communications 17 J. Linkova 18 Google 19 E. Aries 20 Facebook 21 T. Kosugi 22 NTT 23 E. Vyncke 24 Cisco Systems, Inc. 25 D. Lebrun 26 Universite Catholique de Louvain 27 D. Steinberg 28 Steinberg Consulting 29 R. Raszuk 30 Bloomberg 31 March 13, 2017 33 IPv6 Segment Routing Header (SRH) 34 draft-ietf-6man-segment-routing-header-06 36 Abstract 38 Segment Routing (SR) allows a node to steer a packet through a 39 controlled set of instructions, called segments, by prepending an SR 40 header to the packet. A segment can represent any instruction, 41 topological or service-based. SR allows to enforce a flow through 42 any path (topological, or application/service based) while 43 maintaining per-flow state only at the ingress node to the SR domain. 45 Segment Routing can be applied to the IPv6 data plane with the 46 addition of a new type of Routing Extension Header. This draft 47 describes the Segment Routing Extension Header Type and how it is 48 used by SR capable nodes. 50 Requirements Language 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in RFC 2119 [RFC2119]. 56 Status of This Memo 58 This Internet-Draft is submitted in full conformance with the 59 provisions of BCP 78 and BCP 79. 61 Internet-Drafts are working documents of the Internet Engineering 62 Task Force (IETF). Note that other groups may also distribute 63 working documents as Internet-Drafts. The list of current Internet- 64 Drafts is at http://datatracker.ietf.org/drafts/current/. 66 Internet-Drafts are draft documents valid for a maximum of six months 67 and may be updated, replaced, or obsoleted by other documents at any 68 time. It is inappropriate to use Internet-Drafts as reference 69 material or to cite them other than as "work in progress." 71 This Internet-Draft will expire on September 14, 2017. 73 Copyright Notice 75 Copyright (c) 2017 IETF Trust and the persons identified as the 76 document authors. All rights reserved. 78 This document is subject to BCP 78 and the IETF Trust's Legal 79 Provisions Relating to IETF Documents 80 (http://trustee.ietf.org/license-info) in effect on the date of 81 publication of this document. Please review these documents 82 carefully, as they describe your rights and restrictions with respect 83 to this document. Code Components extracted from this document must 84 include Simplified BSD License text as described in Section 4.e of 85 the Trust Legal Provisions and are provided without warranty as 86 described in the Simplified BSD License. 88 Table of Contents 90 1. Segment Routing Documents . . . . . . . . . . . . . . . . . . 3 91 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 92 2.1. Data Planes supporting Segment Routing . . . . . . . . . 4 93 2.2. SRv6 Segment . . . . . . . . . . . . . . . . . . . . . . 5 94 2.3. Segment Routing (SR) Domain . . . . . . . . . . . . . . . 5 95 2.3.1. SR Domain in a Service Provider Network . . . . . . . 6 96 2.3.2. SR Domain in a Overlay Network . . . . . . . . . . . 7 97 3. Segment Routing Extension Header (SRH) . . . . . . . . . . . 8 98 3.1. SRH TLVs . . . . . . . . . . . . . . . . . . . . . . . . 10 99 3.1.1. Ingress Node TLV . . . . . . . . . . . . . . . . . . 11 100 3.1.2. Egress Node TLV . . . . . . . . . . . . . . . . . . . 12 101 3.1.3. Opaque Container TLV . . . . . . . . . . . . . . . . 13 102 3.1.4. Padding TLV . . . . . . . . . . . . . . . . . . . . . 13 103 3.1.5. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . 14 104 3.1.6. NSH Carrier TLV . . . . . . . . . . . . . . . . . . . 15 105 3.2. SRH and RFC2460 behavior . . . . . . . . . . . . . . . . 16 106 4. SRH Functions . . . . . . . . . . . . . . . . . . . . . . . . 16 107 4.1. Endpoint Function (End) . . . . . . . . . . . . . . . . . 16 108 4.2. End.X: Endpoint with Layer-3 cross-connect . . . . . . . 17 109 5. SR Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 18 110 5.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 18 111 5.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 19 112 5.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 20 113 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 114 6.1. Threat model . . . . . . . . . . . . . . . . . . . . . . 21 115 6.1.1. Source routing threats . . . . . . . . . . . . . . . 21 116 6.1.2. Applicability of RFC 5095 to SRH . . . . . . . . . . 21 117 6.1.3. Service stealing threat . . . . . . . . . . . . . . . 22 118 6.1.4. Topology disclosure . . . . . . . . . . . . . . . . . 22 119 6.1.5. ICMP Generation . . . . . . . . . . . . . . . . . . . 22 120 6.2. Security fields in SRH . . . . . . . . . . . . . . . . . 23 121 6.2.1. Selecting a hash algorithm . . . . . . . . . . . . . 24 122 6.2.2. Performance impact of HMAC . . . . . . . . . . . . . 25 123 6.2.3. Pre-shared key management . . . . . . . . . . . . . . 25 124 6.3. Deployment Models . . . . . . . . . . . . . . . . . . . . 26 125 6.3.1. Nodes within the SR domain . . . . . . . . . . . . . 26 126 6.3.2. Nodes outside of the SR domain . . . . . . . . . . . 26 127 6.3.3. SR path exposure . . . . . . . . . . . . . . . . . . 27 128 6.3.4. Impact of BCP-38 . . . . . . . . . . . . . . . . . . 27 129 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 130 7.1. Segment Routing Header TLVs Register . . . . . . . . . . 28 131 8. Manageability Considerations . . . . . . . . . . . . . . . . 28 132 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 133 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 134 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 135 11.1. Normative References . . . . . . . . . . . . . . . . . . 29 136 11.2. Informative References . . . . . . . . . . . . . . . . . 29 137 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 139 1. Segment Routing Documents 141 Segment Routing terminology is defined in 142 [I-D.ietf-spring-segment-routing]. 144 The network programming paradigm 145 [I-D.filsfils-spring-srv6-network-programming] defines the basic 146 functions associated to an SRv6 SID. 148 Segment Routing use cases are described in [RFC7855] and 149 [I-D.ietf-spring-ipv6-use-cases]. 151 Segment Routing protocol extensions are defined in 152 [I-D.ietf-isis-segment-routing-extensions], and 153 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 155 2. Introduction 157 Segment Routing (SR), defined in [I-D.ietf-spring-segment-routing], 158 allows a node to steer a packet through a controlled set of 159 instructions, called segments, by prepending an SR header to the 160 packet. A segment can represent any instruction, topological or 161 service-based. SR allows to enforce a flow through any path 162 (topological or service/application based) while maintaining per-flow 163 state only at the ingress node to the SR domain. Segments can be 164 derived from different components: IGP, BGP, Services, Contexts, 165 Locators, etc. The list of segment forming the path is called the 166 Segment List and is encoded in the packet header. 168 SR allows the use of strict and loose source based routing paradigms 169 without requiring any additional signaling protocols in the 170 infrastructure hence delivering an excellent scalability property. 172 The source based routing model described in 173 [I-D.ietf-spring-segment-routing] is inherited from the ones proposed 174 by [RFC1940] and [RFC2460]. The source based routing model offers 175 the support for explicit routing capability. 177 2.1. Data Planes supporting Segment Routing 179 Segment Routing (SR), can be instantiated over MPLS 180 ([I-D.ietf-spring-segment-routing-mpls]) and IPv6. This document 181 defines its instantiation over the IPv6 data-plane based on the use- 182 cases defined in [I-D.ietf-spring-ipv6-use-cases]. 184 This document defines a new type of Routing Header (originally 185 defined in [RFC2460]) called the Segment Routing Header (SRH) in 186 order to convey the Segment List in the packet header as defined in 187 [I-D.ietf-spring-segment-routing]. Mechanisms through which segment 188 are known and advertised are outside the scope of this document. 190 2.2. SRv6 Segment 192 An SRv6 Segment is a 128-bit value. "SRv6 SID" or simply "SID" are 193 often used as a shorter reference for "SRv6 Segment". 195 An SRv6-capable node N maintains a "My Local SID Table". This table 196 contains all the local SRv6 segments explicitly instantiated at node 197 N. N is the parent node for these SID's. 199 A local SID of N could be an IPv6 address of a local interface of N 200 but it does not have to. Most often, a local SID is not an address 201 of a local interface of N. The My Local SID Table is thus not 202 populated by default with all the addresses of a node. 204 An illustration is provided in 205 [I-D.filsfils-spring-srv6-network-programming]. 207 Every SRv6 local SID instantiated has a specific instruction bounded 208 to it. 210 This information is stored in the "My Local SID Table". The "My 211 Local SID Table" has three main purposes: 213 o Define which local SID's are explicitly instantiated. 215 o Specify which instruction is bound to each of the instantiated 216 SID's. 218 o Store the parameters associated to such instruction (i.e. OIF, 219 NextHop,...). 221 A node may receive a packet with an SRv6 SID in the DA without an 222 SRH. In such case the packet should still be processed by the 223 Segment Routing engine. 225 2.3. Segment Routing (SR) Domain 227 We define the concept of the Segment Routing Domain (SR Domain) as 228 the set of nodes participating into the source based routing model. 229 These nodes may be connected to the same physical infrastructure 230 (e.g.: a Service Provider's network) as well as nodes remotely 231 connected to each other (e.g.: an enterprise VPN or an overlay). 233 A non-exhaustive list of examples of SR Domains is: 235 o The network of an operator, service provider, content provider, 236 enterprise including nodes, links and Autonomous Systems. 238 o A set of nodes connected as an overlay over one or more transit 239 providers. The overlay nodes exchange SR-enabled traffic with 240 segments belonging solely to the overlay routers (the SR domain). 241 None of the segments in the SR-enabled packets exchanged by the 242 overlay belong to the transit networks 244 The source based routing model through its instantiation of the 245 Segment Routing Header (SRH) defined in this document equally applies 246 to all the above examples. 248 It is assumed in this document that the SRH is added to the packet by 249 its source, consistently with the source routing model defined in 250 [RFC2460]. For example: 252 o At the node originating the packet (host, server). 254 o At the ingress node of an SR domain where the ingress node 255 receives an IPv6 packet and encapsulates it into an outer IPv6 256 header followed by a Segment Routing header. 258 2.3.1. SR Domain in a Service Provider Network 260 The following figure illustrates an SR domain consisting of an 261 operator's network infrastructure. 263 (-------------------------- Operator 1 -----------------------) 264 ( ) 265 ( (-----AS 1-----) (-------AS 2-------) (----AS 3-------) ) 266 ( ( ) ( ) ( ) ) 267 A1--(--(--11---13--14-)--(-21---22---23--24-)--(-31---32---34--)--)--Z1 268 ( ( /|\ /|\ /| ) ( |\ /|\ /|\ /| ) ( |\ /|\ /| \ ) ) 269 A2--(--(/ | \/ | \/ | ) ( | \/ | \/ | \/ | ) ( | \/ | \/ | \)--)--Z2 270 ( ( | /\ | /\ | ) ( | /\ | /\ | /\ | ) ( | /\ | /\ | ) ) 271 ( ( |/ \|/ \| ) ( |/ \|/ \|/ \| ) ( |/ \|/ \| ) ) 272 A3--(--(--15---17--18-)--(-25---26---27--28-)--(-35---36---38--)--)--Z3 273 ( ( ) ( ) ( ) ) 274 ( (--------------) (------------------) (---------------) ) 275 ( ) 276 (-------------------------------------------------------------) 278 Figure 1: Service Provider SR Domain 280 Figure 1 describes an operator network including several ASes and 281 delivering connectivity between endpoints. In this scenario, Segment 282 Routing is used within the operator networks and across the ASes 283 boundaries (all being under the control of the same operator). In 284 this case segment routing can be used in order to address use cases 285 such as end-to-end traffic engineering, fast re-route, egress peer 286 engineering, data-center traffic engineering as described in 287 [RFC7855], [I-D.ietf-spring-ipv6-use-cases] and 288 [I-D.ietf-spring-resiliency-use-cases]. 290 Typically, an IPv6 packet received at ingress (i.e.: from outside the 291 SR domain), is classified according to network operator policies and 292 such classification results into an outer header with an SRH applied 293 to the incoming packet. The SRH contains the list of segment 294 representing the path the packet must take inside the SR domain. 295 Thus, the SA of the packet is the ingress node, the DA (due to SRH 296 procedures described in Section 5) is set as the first segment of the 297 path and the last segment of the path is the egress node of the SR 298 domain. 300 The path may include intra-AS as well as inter-AS segments. It has 301 to be noted that all nodes within the SR domain are under control of 302 the same administration. When the packet reaches the egress point of 303 the SR domain, the outer header and its SRH are removed so that the 304 destination of the packet is unaware of the SR domain the packet has 305 traversed. 307 The outer header with the SRH is no different from any other 308 tunneling encapsulation mechanism and allows a network operator to 309 implement traffic engineering mechanisms so to efficiently steer 310 traffic across his infrastructure. 312 2.3.2. SR Domain in a Overlay Network 314 The following figure illustrates an SR domain consisting of an 315 overlay network over multiple operator's networks. 317 (--Operator 1---) (-----Operator 2-----) (--Operator 3---) 318 ( ) ( ) ( ) 319 A1--(--11---13--14--)--(--21---22---23--24--)--(-31---32---34--)--C1 320 ( /|\ /|\ /| ) ( |\ /|\ /|\ /| ) ( |\ /|\ /| \ ) 321 A2--(/ | \/ | \/ | ) ( | \/ | \/ | \/ | ) ( | \/ | \/ | \)--C2 322 ( | /\ | /\ | ) ( | /\ | /\ | /\ | ) ( | /\ | /\ | ) 323 ( |/ \|/ \| ) ( |/ \|/ \|/ \| ) ( |/ \|/ \| ) 324 A3--(--15---17--18--)--(--25---26---27--28--)--(-35---36---38--)--C3 325 ( ) ( | | | ) ( ) 326 (---------------) (--|----|---------|--) (---------------) 327 | | | 328 B1 B2 B3 330 Figure 2: Overlay SR Domain 332 Figure 2 describes an overlay consisting of nodes connected to three 333 different network operators and forming a single overlay network 334 where Segment routing packets are exchanged. 336 The overlay consists of nodes A1, A2, A3, B1, B2, B3, C1, C2 and C3. 337 These nodes are connected to their respective network operator and 338 form an overlay network. 340 Each node may originate packets with an SRH which contains, in the 341 segment list of the SRH or in the DA, segments identifying other 342 overlay nodes. This implies that packets with an SRH may traverse 343 operator's networks but, obviously, these SRHs cannot contain an 344 address/segment of the transit operators 1, 2 and 3. The SRH 345 originated by the overlay can only contain address/segment under the 346 administration of the overlay (e.g. address/segments supported by A1, 347 A2, A3, B1, B2, B3, C1,C2 or C3). 349 In this model, the operator network nodes are transit nodes and, 350 according to [RFC2460], MUST NOT inspect the routing extension header 351 since they are not the DA of the packet. 353 It is a common practice in operators networks to filter out, at 354 ingress, any packet whose DA is the address of an internal node and 355 it is also possible that an operator would filter out any packet 356 destined to an internal address and having an extension header in it. 358 This common practice does not impact the SR-enabled traffic between 359 the overlay nodes as the intermediate transit networks never see a 360 destination address belonging to their infrastructure. These SR- 361 enabled overlay packets will thus never be filtered by the transit 362 operators. 364 In all cases, transit packets (i.e.: packets whose DA is outside the 365 domain of the operator's network) will be forwarded accordingly 366 without introducing any security concern in the operator's network. 367 This is similar to tunneled packets. 369 3. Segment Routing Extension Header (SRH) 371 A new type of the Routing Header (originally defined in [RFC2460]) is 372 defined: the Segment Routing Header (SRH) which has a new Routing 373 Type, (suggested value 4) to be assigned by IANA. 375 The Segment Routing Header (SRH) is defined as follows: 377 0 1 2 3 378 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 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Last Entry | Flags | Tag | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | | 385 | Segment List[0] (128 bits IPv6 address) | 386 | | 387 | | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | | 390 | | 391 ... 392 | | 393 | | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | | 396 | Segment List[n] (128 bits IPv6 address) | 397 | | 398 | | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 // // 401 // Optional Type Length Value objects (variable) // 402 // // 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 where: 407 o Next Header: 8-bit selector. Identifies the type of header 408 immediately following the SRH. 410 o Hdr Ext Len: 8-bit unsigned integer, is the length of the SRH 411 header in 8-octet units, not including the first 8 octets. 413 o Routing Type: TBD, to be assigned by IANA (suggested value: 4). 415 o Segments Left. Defined in [RFC2460], it contains the index, in 416 the Segment List, of the next segment to inspect. Segments Left 417 is decremented at each segment. 419 o Last Entry: contains the index, in the Segment List, of the last 420 element of the Segment List. 422 o Flags: 8 bits of flags. Following flags are defined: 424 0 1 2 3 4 5 6 7 425 +-+-+-+-+-+-+-+-+ 426 |U|P|O|A|H| U | 427 +-+-+-+-+-+-+-+-+ 429 U: Unused and for future use. SHOULD be unset on transmission 430 and MUST be ignored on receipt. 432 P-flag: Protected flag. Set when the packet has been rerouted 433 through FRR mechanism by an SR endpoint node. 435 O-flag: OAM flag. When set, it indicates that this packet is 436 an operations and management (OAM) packet. 438 A-flag: Alert flag. If present, it means important Type Length 439 Value (TLV) objects are present. See Section 3.1 for details 440 on TLVs objects. 442 H-flag: HMAC flag. If set, the HMAC TLV is present and is 443 encoded as the last TLV of the SRH. In other words, the last 444 36 octets of the SRH represent the HMAC information. See 445 Section 3.1.5 for details on the HMAC TLV. 447 o Tag: tag a packet as part of a class or group of packets, e.g., 448 packets sharing the same set of properties. 450 o Segment List[n]: 128 bit IPv6 addresses representing the nth 451 segment in the Segment List. The Segment List is encoded starting 452 from the last segment of the path. I.e., the first element of the 453 segment list (Segment List [0]) contains the last segment of the 454 path, the second element contains the penultimate segment of the 455 path and so on. 457 o Type Length Value (TLV) are described in Section 3.1. 459 3.1. SRH TLVs 461 This section defines TLVs of the Segment Routing Header. 463 Type Length Value (TLV) contain optional information that may be used 464 by the node identified in the DA of the packet. It has to be noted 465 that the information carried in the TLVs is not intended to be used 466 by the routing layer. Typically, TLVs carry information that is 467 consumed by other components (e.g.: OAM) than the routing function. 469 Each TLV has its own length, format and semantic. The code-point 470 allocated (by IANA) to each TLV defines both the format and the 471 semantic of the information carried in the TLV. Multiple TLVs may be 472 encoded in the same SRH. 474 The "Length" field of the TLV is primarily used to skip the TLV while 475 inspecting the SRH in case the node doesn't support or recognize the 476 TLV codepoint. The "Length" defines the TLV length in octets and not 477 including the "Type" and "Length" fields. 479 The following TLVs are defined in this document: 481 Ingress Node TLV 483 Egress Node TLV 485 Opaque TLV 487 Padding TLV 489 HMAC TLV 491 NSH Carrier TLV 493 Additional TLVs may be defined in the future. 495 3.1.1. Ingress Node TLV 497 The Ingress Node TLV is optional and identifies the node this packet 498 traversed when entered the SR domain. The Ingress Node TLV has 499 following format: 501 0 1 2 3 502 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 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Type | Length | RESERVED | Flags | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | | 507 | Ingress Node (16 octets) | 508 | | 509 | | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 where: 514 o Type: to be assigned by IANA (suggested value 1). 516 o Length: 18. 518 o RESERVED: 8 bits. SHOULD be unset on transmission and MUST be 519 ignored on receipt. 521 o Flags: 8 bits. No flags are defined in this document. SHOULD be 522 set to 0 on transmission and MUST be ignored on receipt. 524 o Ingress Node: 128 bits. Defines the node where the packet is 525 expected to enter the SR domain. In the encapsulation case 526 described in Section 2.3.1, this information corresponds to the SA 527 of the encapsulating header. 529 3.1.2. Egress Node TLV 531 The Egress Node TLV is optional and identifies the node this packet 532 is expected to traverse when exiting the SR domain. The Egress Node 533 TLV has following format: 535 0 1 2 3 536 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 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Type | Length | RESERVED | Flags | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | | 541 | Egress Node (16 octets) | 542 | | 543 | | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 where: 548 o Type: to be assigned by IANA (suggested value 2). 550 o Length: 18. 552 o RESERVED: 8 bits. SHOULD be unset on transmission and MUST be 553 ignored on receipt. 555 o Flags: 8 bits. No flags are defined in this document. SHOULD be 556 set to 0 on transmission and MUST be ignored on receipt. 558 o Egress Node: 128 bits. Defines the node where the packet is 559 expected to exit the SR domain. In the encapsulation case 560 described in Section 2.3.1, this information corresponds to the 561 last segment of the SRH in the encapsulating header. 563 3.1.3. Opaque Container TLV 565 The Opaque Container TLV is optional and has the following format: 567 0 1 2 3 568 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 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Type | Length | RESERVED | Flags | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | | 573 | Opaque Container (16 octets) | 574 | | 575 | | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 where: 580 o Type: to be assigned by IANA (suggested value 3). 582 o Length: 18. 584 o RESERVED: 8 bits. SHOULD be unset on transmission and MUST be 585 ignored on receipt. 587 o Flags: 8 bits. No flags are defined in this document. SHOULD be 588 set to 0 on transmission and MUST be ignored on receipt. 590 o Opaque Container: 128 bits of opaque data not relevant for the 591 routing layer. Typically, this information is consumed by a non- 592 routing component of the node receiving the packet (i.e.: the node 593 in the DA). 595 3.1.4. Padding TLV 597 The Padding TLV is optional and with the purpose of aligning the SRH 598 on a 8 octet boundary. The Padding TLV has the following format: 600 0 1 2 3 601 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 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Type | Length | Padding (variable) | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 // Padding (variable) // 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 where: 610 o Type: to be assigned by IANA (suggested value 4). 612 o Length: 1 to 7 614 o Padding: from 1 to 7 octets of padding. Padding bits have no 615 semantic. They SHOULD be set to 0 on transmission and MUST be 616 ignored on receipt. 618 The following applies to the Padding TLV: 620 o Padding TLV is optional and MAY only appear once in the SRH. If 621 present, it MUST have a length between 1 and 7 octets. 623 o The Padding TLV is used in order to align the SRH total length on 624 the 8 octet boundary. 626 o When present, the Padding TLV MUST appear as the last TLV before 627 the HMAC TLV (if HMAC TLV is present). 629 o When present, the Padding TLV MUST have a length from 1 to 7 in 630 order to align the SRH total lenght on a 8-octet boundary. 632 o When a router inspecting the SRH encounters the Padding TLV, it 633 MUST assume that no other TLV (other than the HMAC) follow the 634 Padding TLV. 636 3.1.5. HMAC TLV 638 HMAC TLV is optional and contains the HMAC information. The HMAC TLV 639 has the following format: 641 0 1 2 3 642 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 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | Type | Length | RESERVED | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | HMAC Key ID (4 octets) | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | // 649 | HMAC (32 octets) // 650 | // 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 where: 655 o Type: to be assigned by IANA (suggested value 5). 657 o Length: 38. 659 o RESERVED: 2 octets. SHOULD be unset on transmission and MUST be 660 ignored on receipt. 662 o HMAC Key ID: 4 octets. 664 o HMAC: 32 octets. 666 o HMAC and HMAC Key ID usage is described in Section 6 668 The Following applies to the HMAC TLV: 670 o When present, the HMAC TLV MUST be encoded as the last TLV of the 671 SRH. 673 o If the HMAC TLV is present, the SRH H-Flag (Figure 4) MUST be set. 675 o When the H-flag is set in the SRH, the router inspecting the SRH 676 MUST find the HMAC TLV in the last 38 octets of the SRH. 678 3.1.6. NSH Carrier TLV 680 The NSH Carrier TLV is a container used in order to carry TLVs that 681 have been defined in [I-D.ietf-sfc-nsh]. The NSH Carrier TLV has the 682 following format: 684 0 1 2 3 685 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 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | Type | Length | Flags | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 // NSH Carried Object // 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 where: 693 o Type: to be assigned by IANA (suggested value 6). 695 o Length: the total length of the TLV. 697 o Flags: 8 bits. No flags are defined in this document. SHOULD be 698 set to 0 on transmission and MUST be ignored on receipt. 700 o NSH Carried Object: the content of the TLV which consists of the 701 NSH data as defined in [I-D.ietf-sfc-nsh]. 703 3.2. SRH and RFC2460 behavior 705 The SRH being a new type of the Routing Header, it also has the same 706 properties: 708 SHOULD only appear once in the packet. 710 Only the router whose address is in the DA field of the packet 711 header MUST inspect the SRH. 713 Therefore, Segment Routing in IPv6 networks implies that the segment 714 identifier (i.e.: the IPv6 address of the segment) is moved into the 715 DA of the packet. 717 The DA of the packet changes at each segment termination/completion 718 and therefore the final DA of the packet MUST be encoded as the last 719 segment of the path. 721 4. SRH Functions 723 Segment Routing architecture, as defined in 724 [I-D.ietf-spring-segment-routing] defines a segment as an instruction 725 or, more generally, a set of instructions (function). 727 [I-D.filsfils-spring-srv6-network-programming] defines the basic 728 functions associated with SRv6 SID's. 730 In this section we review two of these functions that may be 731 associated to a segment: 733 o End: the endpoint (End) function is the base of the source routing 734 paradigm. It consists of updating the DA with the next segment 735 and forward the packet accordingly. 737 o End.X: The endpoint layer-3 cross-connect function. 739 More functions are defined in 740 [I-D.filsfils-spring-srv6-network-programming]. 742 4.1. Endpoint Function (End) 744 The Endpoint function (End) is the most basic function. 746 When the endpoint node receives a packet destined to DA "S" and S is 747 an entry in the MyLocalSID table and the function associated with S 748 in that entry is "End" then the endpoint does: 750 1. IF SegmentsLeft > 0 THEN 751 2. decrement SL 752 3. update the IPv6 DA with SRH[SL] 753 4. FIB lookup on updated DA 754 5. forward accordingly to the matched entry 755 6. ELSE 756 7. drop the packet 758 It has to be noted that: 760 o The End function performs the FIB lookup in the forwarding table 761 of the ingress interface. 763 o If the FIB lookup matches a multicast state, then the related 764 Reverse Path Forwarding (RPF) check must be considered successful. 766 o An SRv6-capable node MUST include the FlowLabel of the IPv6 header 767 in its hash computation for ECMP load-balancing. 769 o By default, a local SID bound to the End function does not allow 770 the decapsulation of an outer header. As a consequence, an End 771 SID cannot be the last SID of an SRH and cannot be the DA of a 772 packet without SRH. 774 o If the decapsulation is desired, then another function must be 775 bound to the SID (e.g., End.DX6 defined in 776 [I-D.filsfils-spring-srv6-network-programming]). This prevents 777 any unintentional decapsulation by the segment endpoint node. The 778 details of the advertisement of a SID in the control plane are 779 outside the scope of this document (e.g., 780 [I-D.previdi-idr-segment-routing-te-policy], 781 [I-D.dawra-bgp-srv6-vpn] and [I-D.bashandy-isis-srv6-extensions]. 783 4.2. End.X: Endpoint with Layer-3 cross-connect 785 When the endpoint node receives a packet destined to DA "S" and S is 786 an entry in the MyLocalSID table and the function associated with S 787 in that entry is "End.X" then the endpoint does: 789 1. IF SegmentsLeft > 0 THEN 790 2. decrement SL 791 3. update the IPv6 DA with SRH[SL] 792 4. forward to layer-3 adjacency bound to the SID "S" 793 5. ELSE 794 6. drop the packet 796 It has to be noted that: 798 o If an array of layer-3 adjacencies is bound to the End.X SID, then 799 one entry of the array is selected based on a hash of the packet's 800 header (at least SA, DA, Flow Label). 802 o An End.X function does not allow decaps. An End.X SID cannot be 803 the last SID of an SRH and cannot be the DA of a packet without 804 SRH. 806 o The End.X function is required to express any traffic-engineering 807 policy. 809 o The End.X function is the SRv6 instantiation of a Adjacency SID as 810 defined in [I-D.ietf-spring-segment-routing]. 812 o Note that with SR-MPLS ([I-D.ietf-spring-segment-routing-mpls]), 813 an AdjSID is typically preceded by a PrefixSID. This is unlikely 814 in SRv6 as most likely an End.X SID is globally routed address of 815 N. 817 o If a node N has 30 outgoing interfaces to 30 neighbors, usually 818 the operator would explicitly instantiate 30 End.X SID's at N: one 819 per layer-3 adjacency to a neighbor. Potentially, more End.X 820 could be explicitly defined (groups of layer-3 adjacencies to the 821 same neighbor or to different neighbors). 823 o If node N has a bundle outgoing interface I to a neighbor Q made 824 of 10 member links, N may allocate up to 11 End.X local SID's for 825 that bundle: one for the bundle itself and then up to one for each 826 member link. This is the equivalent of the L2-Link Adj SID in SR- 827 MPLS ([I-D.ietf-isis-l2bundles]). 829 5. SR Nodes 831 There are different types of nodes that may be involved in segment 832 routing networks: source nodes that originate packets with an SRH, 833 transit nodes that forward packets having an SRH and segment endpoint 834 nodes that MUST process the SRH. 836 5.1. Source SR Node 838 A Source SR Node can be any node originating an IPv6 packet with its 839 IPv6 and Segment Routing Headers. This include either: 841 A host originating an IPv6 packet. 843 An SR domain ingress router encapsulating a received IPv6 packet 844 into an outer IPv6 header followed by an SRH. 846 The mechanism through which a Segment List is derived is outside of 847 the scope of this document. As an example, the Segment List may be 848 obtained through: 850 Local path computation. 852 Local configuration. 854 Interaction with a centralized controller delivering the path. 856 Any other mechanism. 858 The following are the steps of the creation of the SRH: 860 Next Header and Hdr Ext Len fields are set according to [RFC2460]. 862 Routing Type field is set as TBD (to be allocated by IANA, 863 suggested value 4). 865 The DA of the packet is set with the value of the first segment. 866 ). 868 The first element of the segment list is the last segment (the 869 final DA of the packet). The second element is the penultimate 870 segment and so on. 872 In other words, the Segment List is encoded in the reverse order 873 of the path. 875 The Segments Left field is set to n-1 where n is the number of 876 elements in the Segment List. 878 The Last_Entry field is set to n-1 where n is the number of 879 elements in the Segment List. 881 The packet is sent out towards the packet's DA (the first 882 segment). 884 HMAC TLV may be set according to Section 6. 886 If the segment list contains a single segment and there is no need 887 for information in flag or TLV, then the SRH MAY be omitted. 889 5.2. Transit Node 891 According to [RFC2460], the only node who is allowed to inspect the 892 Routing Extension Header (and therefore the SRH), is the node 893 corresponding to the DA of the packet. Any other transit node MUST 894 NOT inspect the underneath routing header and MUST forward the packet 895 towards the DA and according to the IPv6 routing table. 897 In the example case described in Section 2.3.2, when SR capable nodes 898 are connected through an overlay spanning multiple third-party 899 infrastructure, it is safe to send SRH packets (i.e.: packet having a 900 Segment Routing Header) between each other overlay/SR-capable nodes 901 as long as the segment list does not include any of the transit 902 provider nodes. In addition, as a generic security measure, any 903 service provider will block any packet destined to one of its 904 internal routers, especially if these packets have an extended header 905 in it. 907 5.3. SR Segment Endpoint Node 909 The SR segment endpoint node is the node whose MyLocalSID table 910 contains an entry for the DA of the packet. 912 The segment endpoint node executes the function bound to the SID as 913 per the matched MyLocalSID entry (Section 4). 915 6. Security Considerations 917 This section analyzes the security threat model, the security issues 918 and proposed solutions related to the new Segment Routing Header. 920 The Segment Routing Header (SRH) is simply another type of the 921 routing header as described in RFC 2460 [RFC2460] and is: 923 o Added by an SR edge router when entering the segment routing 924 domain or by the originating host itself. The source host can 925 even be outside the SR domain; 927 o inspected and acted upon when reaching the destination address of 928 the IP header per RFC 2460 [RFC2460]. 930 Per RFC2460 [RFC2460], routers on the path that simply forward an 931 IPv6 packet (i.e. the IPv6 destination address is none of theirs) 932 will never inspect and process the content of the SRH. Routers whose 933 one interface IPv6 address equals the destination address field of 934 the IPv6 packet MUST parse the SRH and, if supported and if the local 935 configuration allows it, MUST act accordingly to the SRH content. 937 According to RFC2460 [RFC2460], the default behavior of a non SR- 938 capable router upon receipt of an IPv6 packet with SRH destined to an 939 address of its, is to: 941 o ignore the SRH completely if the Segment Left field is 0 and 942 proceed to process the next header in the IPv6 packet; 944 o discard the IPv6 packet if Segment Left field is greater than 0, 945 it MAY send a Parameter Problem ICMP message back to the Source 946 Address. 948 6.1. Threat model 950 6.1.1. Source routing threats 952 Using an SRH is similar to source routing, therefore it has some 953 well-known security issues as described in RFC4942 [RFC4942] section 954 2.1.1 and RFC5095 [RFC5095]: 956 o amplification attacks: where a packet could be forged in such a 957 way to cause looping among a set of SR-enabled routers causing 958 unnecessary traffic, hence a Denial of Service (DoS) against 959 bandwidth; 961 o reflection attack: where a hacker could force an intermediate node 962 to appear as the immediate attacker, hence hiding the real 963 attacker from naive forensic; 965 o bypass attack: where an intermediate node could be used as a 966 stepping stone (for example in a De-Militarized Zone) to attack 967 another host (for example in the datacenter or any back-end 968 server). 970 6.1.2. Applicability of RFC 5095 to SRH 972 First of all, the reader must remember this specific part of section 973 1 of RFC5095 [RFC5095], "A side effect is that this also eliminates 974 benign RH0 use-cases; however, such applications may be facilitated 975 by future Routing Header specifications.". In short, it is not 976 forbidden to create new secure type of Routing Header; for example, 977 RFC 6554 (RPL) [RFC6554] also creates a new Routing Header type for a 978 specific application confined in a single network. 980 In the segment routing architecture described in 981 [I-D.ietf-spring-segment-routing] there are basically two kinds of 982 nodes (routers and hosts): 984 o nodes within the SR domain, which is within one single 985 administrative domain, i.e., where all nodes are trusted anyway 986 else the damage caused by those nodes could be worse than 987 amplification attacks: traffic interception, man-in-the-middle 988 attacks, more server DoS by dropping packets, and so on. 990 o nodes outside of the SR domain, which is outside of the 991 administrative segment routing domain hence they cannot be trusted 992 because there is no physical security for those nodes, i.e., they 993 can be replaced by hostile nodes or can be coerced in wrong 994 behaviors. 996 The main use case for SR consists of the single administrative domain 997 where only trusted nodes with SR enabled and configured participate 998 in SR: this is the same model as in RFC6554 [RFC6554]. All non- 999 trusted nodes do not participate as either SR processing is not 1000 enabled by default or because they only process SRH from nodes within 1001 their domain. 1003 Moreover, all SR nodes ignore SRH created by outsiders based on 1004 topology information (received on a peering or internal interface) or 1005 on presence and validity of the HMAC field. Therefore, if 1006 intermediate nodes ONLY act on valid and authorized SRH (such as 1007 within a single administrative domain), then there is no security 1008 threat similar to RH-0. Hence, the RFC 5095 [RFC5095] attacks are 1009 not applicable. 1011 6.1.3. Service stealing threat 1013 Segment routing is used for added value services, there is also a 1014 need to prevent non-participating nodes to use those services; this 1015 is called 'service stealing prevention'. 1017 6.1.4. Topology disclosure 1019 The SRH may also contains IPv6 addresses of some intermediate SR- 1020 nodes in the path towards the destination, this obviously reveals 1021 those addresses to the potentially hostile attackers if those 1022 attackers are able to intercept packets containing SRH. On the other 1023 hand, if the attacker can do a traceroute whose probes will be 1024 forwarded along the SR path, then there is little learned by 1025 intercepting the SRH itself. 1027 6.1.5. ICMP Generation 1029 Per section 4.4 of RFC2460 [RFC2460], when destination nodes (i.e. 1030 where the destination address is one of theirs) receive a Routing 1031 Header with unsupported Routing Type, the required behavior is: 1033 o If Segments Left is zero, the node must ignore the Routing header 1034 and proceed to process the next header in the packet. 1036 o If Segments Left is non-zero, the node must discard the packet and 1037 send an ICMP Parameter Problem, Code 0, message to the packet's 1038 Source Address, pointing to the unrecognized Routing Type. 1040 This required behavior could be used by an attacker to force the 1041 generation of ICMP message by any node. The attacker could send 1042 packets with SRH (with Segment Left set to 0) destined to a node not 1043 supporting SRH. Per RFC2460 [RFC2460], the destination node could 1044 generate an ICMP message, causing a local CPU utilization and if the 1045 source of the offending packet with SRH was spoofed could lead to a 1046 reflection attack without any amplification. 1048 It must be noted that this is a required behavior for any unsupported 1049 Routing Type and not limited to SRH packets. So, it is not specific 1050 to SRH and the usual rate limiting for ICMP generation is required 1051 anyway for any IPv6 implementation and has been implemented and 1052 deployed for many years. 1054 6.2. Security fields in SRH 1056 This section summarizes the use of specific fields in the SRH. They 1057 are based on a key-hashed message authentication code (HMAC). 1059 The security-related fields in the SRH are instantiated by the HMAC 1060 TLV, containing: 1062 o HMAC Key-id, 32 bits wide; 1064 o HMAC, 256 bits wide (optional, exists only if HMAC Key-id is not 1065 0). 1067 The HMAC field is the output of the HMAC computation (per RFC 2104 1068 [RFC2104]) using a pre-shared key identified by HMAC Key-id and of 1069 the text which consists of the concatenation of: 1071 o the source IPv6 address; 1073 o Last Entry field; 1075 o an octet of bit flags; 1077 o HMAC Key-id; 1079 o all addresses in the Segment List. 1081 The purpose of the HMAC TLV is to verify the validity, the integrity 1082 and the authorization of the SRH itself. If an outsider of the SR 1083 domain does not have access to a current pre-shared secret, then it 1084 cannot compute the right HMAC field and the first SR router on the 1085 path processing the SRH and configured to check the validity of the 1086 HMAC will simply reject the packet. 1088 The HMAC TLV is located at the end of the SRH simply because only the 1089 router on the ingress of the SR domain needs to process it, then all 1090 other SR nodes can ignore it (based on local policy) because they 1091 trust the upstream router. This is to speed up forwarding operations 1092 because SR routers which do not validate the SRH do not need to parse 1093 the SRH until the end. 1095 The HMAC Key-id field allows for the simultaneous existence of 1096 several hash algorithms (SHA-256, SHA3-256 ... or future ones) as 1097 well as pre-shared keys. The HMAC Key-id field is opaque, i.e., it 1098 has neither syntax nor semantic except as an index to the right 1099 combination of pre-shared key and hash algorithm and except that a 1100 value of 0 means that there is no HMAC field. Having an HMAC Key-id 1101 field allows for pre-shared key roll-over when two pre-shared keys 1102 are supported for a while when all SR nodes converged to a fresher 1103 pre-shared key. It could also allow for interoperation among 1104 different SR domains if allowed by local policy and assuming a 1105 collision-free HMAC Key Id allocation. 1107 When a specific SRH is linked to a time-related service (such as 1108 turbo-QoS for a 1-hour period) where the DA, Segment ID (SID) are 1109 identical, then it is important to refresh the shared-secret 1110 frequently as the HMAC validity period expires only when the HMAC 1111 Key-id and its associated shared-secret expires. 1113 6.2.1. Selecting a hash algorithm 1115 The HMAC field in the HMAC TLV is 256 bit wide. Therefore, the HMAC 1116 MUST be based on a hash function whose output is at least 256 bits. 1117 If the output of the hash function is 256, then this output is simply 1118 inserted in the HMAC field. If the output of the hash function is 1119 larger than 256 bits, then the output value is truncated to 256 by 1120 taking the least-significant 256 bits and inserting them in the HMAC 1121 field. 1123 SRH implementations can support multiple hash functions but MUST 1124 implement SHA-2 [FIPS180-4] in its SHA-256 variant. 1126 NOTE: SHA-1 is currently used by some early implementations used for 1127 quick interoperations testing, the 160-bit hash value must then be 1128 right-hand padded with 96 bits set to 0. The authors understand that 1129 this is not secure but is ok for limited tests. 1131 6.2.2. Performance impact of HMAC 1133 While adding an HMAC to each and every SR packet increases the 1134 security, it has a performance impact. Nevertheless, it must be 1135 noted that: 1137 o the HMAC field is used only when SRH is added by a device (such as 1138 a home set-up box) which is outside of the segment routing domain. 1139 If the SRH is added by a router in the trusted segment routing 1140 domain, then, there is no need for an HMAC field, hence no 1141 performance impact. 1143 o when present, the HMAC field MUST only be checked and validated by 1144 the first router of the segment routing domain, this router is 1145 named 'validating SR router'. Downstream routers may not inspect 1146 the HMAC field. 1148 o this validating router can also have a cache of to improve the performance. It is not the 1150 same use case as in IPsec where HMAC value was unique per packet, 1151 in SRH, the HMAC value is unique per flow. 1153 o Last point, hash functions such as SHA-2 have been optimized for 1154 security and performance and there are multiple implementations 1155 with good performance. 1157 With the above points in mind, the performance impact of using HMAC 1158 is minimized. 1160 6.2.3. Pre-shared key management 1162 The field HMAC Key-id allows for: 1164 o key roll-over: when there is a need to change the key (the hash 1165 pre-shared secret), then multiple pre-shared keys can be used 1166 simultaneously. The validating routing can have a table of for the currently active and future 1168 keys. 1170 o different algorithms: by extending the previous table to , the validating router 1172 can also support simultaneously several hash algorithms (see 1173 section Section 6.2.1) 1175 The pre-shared secret distribution can be done: 1177 o in the configuration of the validating routers, either by static 1178 configuration or any SDN oriented approach; 1180 o dynamically using a trusted key distribution such as [RFC6407] 1182 The intent of this document is NOT to define yet-another-key- 1183 distribution-protocol. 1185 6.3. Deployment Models 1187 6.3.1. Nodes within the SR domain 1189 An SR domain is defined as a set of interconnected routers where all 1190 routers at the perimeter are configured to add and act on SRH. Some 1191 routers inside the SR domain can also act on SRH or simply forward 1192 IPv6 packets. 1194 The routers inside an SR domain can be trusted to generate SRH and to 1195 process SRH received on interfaces that are part of the SR domain. 1196 These nodes MUST drop all SRH packets received on an interface that 1197 is not part of the SR domain and containing an SRH whose HMAC field 1198 cannot be validated by local policies. This includes obviously 1199 packet with an SRH generated by a non-cooperative SR domain. 1201 If the validation fails, then these packets MUST be dropped, ICMP 1202 error messages (parameter problem) SHOULD be generated (but rate 1203 limited) and SHOULD be logged. 1205 6.3.2. Nodes outside of the SR domain 1207 Nodes outside of the SR domain cannot be trusted for physical 1208 security; hence, they need to request by some trusted means (outside 1209 of the scope of this document) a complete SRH for each new connection 1210 (i.e. new destination address). The received SRH MUST include an 1211 HMAC TLV which is computed correctly (see Section 6.2). 1213 When an outside node sends a packet with an SRH and towards an SR 1214 domain ingress node, the packet MUST contain the HMAC TLV (with a 1215 Key-id and HMAC fields) and the the destination address MUST be an 1216 address of an SR domain ingress node . 1218 The ingress SR router, i.e., the router with an interface address 1219 equals to the destination address, MUST verify the HMAC TLV. 1221 If the validation is successful, then the packet is simply forwarded 1222 as usual for an SR packet. As long as the packet travels within the 1223 SR domain, no further HMAC check needs to be done. Subsequent 1224 routers in the SR domain MAY verify the HMAC TLV when they process 1225 the SRH (i.e. when they are the destination). 1227 If the validation fails, then this packet MUST be dropped, an ICMP 1228 error message (parameter problem) SHOULD be generated (but rate 1229 limited) and SHOULD be logged. 1231 6.3.3. SR path exposure 1233 As the intermediate SR nodes addresses appears in the SRH, if this 1234 SRH is visible to an outsider then he/she could reuse this knowledge 1235 to launch an attack on the intermediate SR nodes or get some insider 1236 knowledge on the topology. This is especially applicable when the 1237 path between the source node and the first SR domain ingress router 1238 is on the public Internet. 1240 The first remark is to state that 'security by obscurity' is never 1241 enough; in other words, the security policy of the SR domain MUST 1242 assume that the internal topology and addressing is known by the 1243 attacker. A simple traceroute will also give the same information 1244 (with even more information as all intermediate nodes between SID 1245 will also be exposed). IPsec Encapsulating Security Payload 1246 [RFC4303] cannot be use to protect the SRH as per RFC4303 the ESP 1247 header must appear after any routing header (including SRH). 1249 To prevent a user to leverage the gained knowledge by intercepting 1250 SRH, it it recommended to apply an infrastructure Access Control List 1251 (iACL) at the edge of the SR domain. This iACL will drop all packets 1252 from outside the SR-domain whose destination is any address of any 1253 router inside the domain. This security policy should be tuned for 1254 local operations. 1256 6.3.4. Impact of BCP-38 1258 BCP-38 [RFC2827], also known as "Network Ingress Filtering", checks 1259 whether the source address of packets received on an interface is 1260 valid for this interface. The use of loose source routing such as 1261 SRH forces packets to follow a path which differs from the expected 1262 routing. Therefore, if BCP-38 was implemented in all routers inside 1263 the SR domain, then SR packets could be received by an interface 1264 which is not expected one and the packets could be dropped. 1266 As an SR domain is usually a subset of one administrative domain, and 1267 as BCP-38 is only deployed at the ingress routers of this 1268 administrative domain and as packets arriving at those ingress 1269 routers have been normally forwarded using the normal routing 1270 information, then there is no reason why this ingress router should 1271 drop the SRH packet based on BCP-38. Routers inside the domain 1272 commonly do not apply BCP-38; so, this is not a problem. 1274 7. IANA Considerations 1276 This document makes the following registrations in the Internet 1277 Protocol Version 6 (IPv6) Parameters "Routing Type" registry 1278 maintained by IANA: 1280 Suggested Description Reference 1281 Value 1282 ---------------------------------------------------------- 1283 4 Segment Routing Header (SRH) This document 1285 This document request IANA to create and maintain a new Registry: 1286 "Segment Routing Header TLVs" 1288 7.1. Segment Routing Header TLVs Register 1290 This document requests the creation of a new IANA managed registry to 1291 identify SRH TLVs. The registration procedure is "Expert Review" as 1292 defined in [RFC5226]. Suggested registry name is "Segment Routing 1293 Header TLVs". A TLV is identified through an unsigned 8 bit 1294 codepoint value. The following codepoints are defined in this 1295 document: 1297 Suggested Description Reference 1298 Value 1299 ----------------------------------------------------- 1300 1 Ingress Node TLV This document 1301 2 Egress Node TLV This document 1302 3 Opaque Container TLV This document 1303 4 Padding TLV This document 1304 5 HMAC TLV This document 1305 6 NSH Carrier TLV This document 1307 8. Manageability Considerations 1309 TBD 1311 9. Contributors 1313 Dave Barach, John Brzozowski, Pierre Francois, Nagendra Kumar, Mark 1314 Townsley, Christian Martin, Roberta Maglione, James Connolly, Aloys 1315 Augustin contributed to the content of this document. 1317 10. Acknowledgements 1319 The authors would like to thank Ole Troan, Bob Hinden, Fred Baker, 1320 Brian Carpenter, Alexandru Petrescu and Punit Kumar Jaiswal for their 1321 comments to this document. 1323 11. References 1325 11.1. Normative References 1327 [FIPS180-4] 1328 National Institute of Standards and Technology, "FIPS 1329 180-4 Secure Hash Standard (SHS)", March 2012, 1330 . 1333 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1334 Requirement Levels", BCP 14, RFC 2119, 1335 DOI 10.17487/RFC2119, March 1997, 1336 . 1338 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1339 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1340 December 1998, . 1342 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1343 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1344 . 1346 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1347 of Type 0 Routing Headers in IPv6", RFC 5095, 1348 DOI 10.17487/RFC5095, December 2007, 1349 . 1351 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 1352 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 1353 October 2011, . 1355 11.2. Informative References 1357 [I-D.bashandy-isis-srv6-extensions] 1358 Bashandy, A., Filsfils, C., Ginsberg, L., and B. Decraene, 1359 "IS-IS Extensions to Support Segment Routing over IPv6 1360 Dataplane", draft-bashandy-isis-srv6-extensions-00 (work 1361 in progress), March 2017. 1363 [I-D.dawra-bgp-srv6-vpn] 1364 (Unknown), (., Dawra, G., Filsfils, C., Dukes, D., 1365 Brissette, P., Camarillo, P., Leddy, J., 1366 daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., 1367 Steinberg, D., Raszuk, R., Decraene, B., and S. 1368 Matsushima, "BGP Signaling of IPv6-Segment-Routing-based 1369 VPN Networks", draft-dawra-bgp-srv6-vpn-00 (work in 1370 progress), March 2017. 1372 [I-D.filsfils-spring-srv6-network-programming] 1373 Filsfils, C., Leddy, J., daniel.voyer@bell.ca, d., 1374 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 1375 Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., 1376 Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., 1377 Sharif, M., Ayyangar, A., Mynam, S., Bashandy, A., Raza, 1378 K., Dukes, D., Clad, F., and P. Camarillo, "SRv6 Network 1379 Programming", draft-filsfils-spring-srv6-network- 1380 programming-00 (work in progress), March 2017. 1382 [I-D.ietf-isis-l2bundles] 1383 Ginsberg, L., Bashandy, A., Filsfils, C., Previdi, S., 1384 Nanduri, M., and E. Aries, "Advertising L2 Bundle Member 1385 Link Attributes in IS-IS", draft-ietf-isis-l2bundles-03 1386 (work in progress), February 2017. 1388 [I-D.ietf-isis-segment-routing-extensions] 1389 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 1390 Litkowski, S., Decraene, B., and j. jefftant@gmail.com, 1391 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 1392 segment-routing-extensions-11 (work in progress), March 1393 2017. 1395 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 1396 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1397 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 1398 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 1399 segment-routing-extensions-09 (work in progress), March 1400 2017. 1402 [I-D.ietf-sfc-nsh] 1403 Quinn, P. and U. Elzur, "Network Service Header", draft- 1404 ietf-sfc-nsh-12 (work in progress), February 2017. 1406 [I-D.ietf-spring-ipv6-use-cases] 1407 Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R., and 1408 W. Townsley, "IPv6 SPRING Use Cases", draft-ietf-spring- 1409 ipv6-use-cases-09 (work in progress), February 2017. 1411 [I-D.ietf-spring-resiliency-use-cases] 1412 Filsfils, C., Previdi, S., Decraene, B., and R. Shakir, 1413 "Resiliency use cases in SPRING networks", draft-ietf- 1414 spring-resiliency-use-cases-08 (work in progress), October 1415 2016. 1417 [I-D.ietf-spring-segment-routing] 1418 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 1419 and R. Shakir, "Segment Routing Architecture", draft-ietf- 1420 spring-segment-routing-11 (work in progress), February 1421 2017. 1423 [I-D.ietf-spring-segment-routing-mpls] 1424 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1425 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1426 data plane", draft-ietf-spring-segment-routing-mpls-08 1427 (work in progress), March 2017. 1429 [I-D.previdi-idr-segment-routing-te-policy] 1430 Previdi, S., Filsfils, C., Sreekantiah, A., Sivabalan, S., 1431 Mattes, P., Rosen, E., and S. Lin, "Advertising Segment 1432 Routing Policies in BGP", draft-previdi-idr-segment- 1433 routing-te-policy-05 (work in progress), February 2017. 1435 [RFC1940] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D. 1436 Zappala, "Source Demand Routing: Packet Format and 1437 Forwarding Specification (Version 1)", RFC 1940, 1438 DOI 10.17487/RFC1940, May 1996, 1439 . 1441 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1442 Hashing for Message Authentication", RFC 2104, 1443 DOI 10.17487/RFC2104, February 1997, 1444 . 1446 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1447 Defeating Denial of Service Attacks which employ IP Source 1448 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1449 May 2000, . 1451 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 1452 Co-existence Security Considerations", RFC 4942, 1453 DOI 10.17487/RFC4942, September 2007, 1454 . 1456 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1457 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1458 DOI 10.17487/RFC5226, May 2008, 1459 . 1461 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 1462 Routing Header for Source Routes with the Routing Protocol 1463 for Low-Power and Lossy Networks (RPL)", RFC 6554, 1464 DOI 10.17487/RFC6554, March 2012, 1465 . 1467 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 1468 Litkowski, S., Horneffer, M., and R. Shakir, "Source 1469 Packet Routing in Networking (SPRING) Problem Statement 1470 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 1471 2016, . 1473 Authors' Addresses 1475 Stefano Previdi (editor) 1476 Cisco Systems, Inc. 1477 Via Del Serafico, 200 1478 Rome 00142 1479 Italy 1481 Email: sprevidi@cisco.com 1483 Clarence Filsfils 1484 Cisco Systems, Inc. 1485 Brussels 1486 BE 1488 Email: cfilsfil@cisco.com 1490 Kamran Raza 1491 Cisco Systems, Inc. 1493 Email: skraza@cisco.com 1495 "Darren Dukes 1496 Cisco Systems, Inc. 1498 Email: ddukes@cisco.com 1499 John Leddy 1500 Comcast 1501 4100 East Dry Creek Road 1502 Centennial, CO 80122 1503 US 1505 Email: John_Leddy@comcast.com 1507 Brian Field 1508 Comcast 1509 4100 East Dry Creek Road 1510 Centennial, CO 80122 1511 US 1513 Email: Brian_Field@cable.comcast.com 1515 Daniel Voyer 1516 Bell Canada 1518 Email: daniel.voyer@bell.ca 1520 Daniel Bernier 1521 Bell Canada 1523 Email: daniel.bernier@bell.ca 1525 Satoru Matsushima 1526 Softbank 1528 Email: satoru.matsushima@g.softbank.co.jp 1530 Ida Leung 1531 Rogers Communications 1532 8200 Dixie Road 1533 Brampton, ON L6T 0C1 1534 CA 1536 Email: Ida.Leung@rci.rogers.com 1537 Jen Linkova 1538 Google 1539 1600 Amphitheatre Parkway 1540 Mountain View, CA 94043 1541 US 1543 Email: furry@google.com 1545 Ebben Aries 1546 Facebook 1547 US 1549 Email: exa@fb.com 1551 Tomoya Kosugi 1552 NTT 1553 3-9-11, Midori-Cho Musashino-Shi, 1554 Tokyo 180-8585 1555 JP 1557 Email: kosugi.tomoya@lab.ntt.co.jp 1559 Eric Vyncke 1560 Cisco Systems, Inc. 1561 De Kleetlaann 6A 1562 Diegem 1831 1563 Belgium 1565 Email: evyncke@cisco.com 1567 David Lebrun 1568 Universite Catholique de Louvain 1569 Place Ste Barbe, 2 1570 Louvain-la-Neuve, 1348 1571 Belgium 1573 Email: david.lebrun@uclouvain.be 1575 Dirk Steinberg 1576 Steinberg Consulting 1578 Email: dws@dirksteinberg.de 1579 Robert Raszuk 1580 Bloomberg 1582 Email: robert@raszuk.net