idnits 2.17.1 draft-vyncke-6man-segment-routing-security-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: o when present, the HMAC field MUST only be checked and validated by the first router of the segment routing domain, this router is named 'validating SR router'. Downstream routers MAY NOT inspect the HMAC field. -- The document date (February 25, 2015) is 3346 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180-4' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-03 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-02 == Outdated reference: A later version (-12) exists of draft-ietf-spring-ipv6-use-cases-03 == Outdated reference: A later version (-08) exists of draft-ietf-spring-problem-statement-03 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-01 == Outdated reference: A later version (-08) exists of draft-previdi-6man-segment-routing-header-05 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man Group E. Vyncke, Ed. 3 Internet-Draft S. Previdi 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: August 29, 2015 D. Lebrun 6 Universite Catholique de Louvain 7 February 25, 2015 9 IPv6 Segment Routing Security Considerations 10 draft-vyncke-6man-segment-routing-security-02 12 Abstract 14 Segment Routing (SR) allows a node to steer a packet through a 15 controlled set of instructions, called segments, by prepending a SR 16 header to the packet. A segment can represent any instruction, 17 topological or service-based. SR allows to enforce a flow through 18 any path (topological, or application/service based) while 19 maintaining per-flow state only at the ingress node to the SR domain. 21 Segment Routing can be applied to the IPv6 data plane with the 22 addition of a new type of Routing Extension Header. This document 23 analyzes the security aspects of the Segment Routing Extension Header 24 (SRH) and how it is used by SR capable nodes to deliver a secure 25 service. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 29, 2015. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Segment Routing Documents . . . . . . . . . . . . . . . . 3 69 2. Threat model . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2.1. Source routing threats . . . . . . . . . . . . . . . . . 4 71 2.2. Applicability of RFC 5095 to SRH . . . . . . . . . . . . 4 72 2.3. Service stealing threat . . . . . . . . . . . . . . . . . 5 73 2.4. Topology disclosure . . . . . . . . . . . . . . . . . . . 5 74 2.5. ICMP Generation . . . . . . . . . . . . . . . . . . . . . 5 75 3. Security fields in SRH . . . . . . . . . . . . . . . . . . . 6 76 3.1. Selecting a hash algorithm . . . . . . . . . . . . . . . 7 77 3.2. Performance impact of HMAC . . . . . . . . . . . . . . . 7 78 3.3. Pre-shared key management . . . . . . . . . . . . . . . . 8 79 4. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 9 80 4.1. Nodes within the SR domain . . . . . . . . . . . . . . . 9 81 4.2. Nodes outside of the SR domain . . . . . . . . . . . . . 9 82 4.3. SR path exposure . . . . . . . . . . . . . . . . . . . . 10 83 4.4. Impact of BCP-38 . . . . . . . . . . . . . . . . . . . . 10 84 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 85 6. Manageability Considerations . . . . . . . . . . . . . . . . 11 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 87 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 89 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 90 9.2. Informative References . . . . . . . . . . . . . . . . . 11 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 93 1. Introduction 95 This document analyzes the security threat model, the security issues 96 and proposed solutions related to the new routing header for segment 97 routing with an IPv6 data plane. 99 The Segment Routing Header (SRH) is simply another type of the 100 routing header as described in RFC 2460 [RFC2460] and is: 102 o inserted by a SR edge router when entering the segment routing 103 domain or by the originating host itself. The source host can 104 even be outside the SR domain; 106 o inspected and acted upon when reaching the destination address of 107 the IP header per RFC 2460 [RFC2460]. 109 Per RFC2460 [RFC2460], routers on the path that simply forward an 110 IPv6 packet (i.e. the IPv6 destination address is none of theirs) 111 will never inspect and process the content of SRH. Routers whose one 112 interface IPv6 address equals the destination address field of the 113 IPv6 packet MUST to parse the SRH and, if supported and if the local 114 configuration allows it, MUST act accordingly to the SRH content. 116 According to RFC2460 [RFC2460], the default behavior of a non SR- 117 capable router upon receipt of an IPv6 packet with SRH destined to an 118 address of its, is to: 120 o ignore the SRH completely if the Segment Left field is 0 and 121 proceed to process the next header in the IPv6 packet; 123 o discard the IPv6 packet if Segment Left field is greater than 0, 124 it MAY send a Parameter Problem ICMP message back to the Source 125 Address. 127 1.1. Segment Routing Documents 129 Segment Routing terminology is defined in 130 [I-D.ietf-spring-segment-routing] and in 131 [I-D.ietf-spring-problem-statement]. Segment Routing use cases are 132 described in [I-D.filsfils-spring-segment-routing-use-cases]. 133 Segment Routing protocol extensions are defined in 134 [I-D.ietf-isis-segment-routing-extensions], and 135 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 137 Segment Routing IPv6 use cases are described in 138 [I-D.ietf-spring-ipv6-use-cases]. And the IPv6 Segment Routing 139 header is described in [I-D.previdi-6man-segment-routing-header]. 141 2. Threat model 142 2.1. Source routing threats 144 Using a SRH is similar to source routing, therefore it has some well- 145 known security issues as described in RFC4942 [RFC4942] section 2.1.1 146 and RFC5095 [RFC5095]: 148 o amplification attacks: where a packet could be forged in such a 149 way to cause looping among a set of SR-enabled routers causing 150 unnecessary traffic, hence a Denial of Service (DoS) against 151 bandwidth; 153 o reflection attack: where a hacker could force an intermediate node 154 to appear as the immediate attacker, hence hiding the real 155 attacker from naive forensic; 157 o bypass attack: where an intermediate node could be used as a 158 stepping stone (for example in a De-Militarized Zone) to attack 159 another host (for example in the datacenter or any back-end 160 server). 162 2.2. Applicability of RFC 5095 to SRH 164 First of all, the reader must remember this specific part of section 165 1 of RFC5095 [RFC5095], "A side effect is that this also eliminates 166 benign RH0 use-cases; however, such applications may be facilitated 167 by future Routing Header specifications.". In short, it is not 168 forbidden to create new secure type of Routing Header; for example, 169 RFC 6554 (RPL) [RFC6554] also creates a new Routing Header type for a 170 specific application confined in a single network. 172 In the segment routing architecture described in 173 [I-D.ietf-spring-segment-routing] there are basically two kinds of 174 nodes (routers and hosts): 176 o nodes within the SR domain, which is within one single 177 administrative domain, i.e., where all nodes are trusted anyway 178 else the damage caused by those nodes could be worse than 179 amplification attacks: traffic interception, man-in-the-middle 180 attacks, more server DoS by dropping packets, and so on. 182 o nodes outside of the SR domain, which is outside of the 183 administrative segment routing domain hence they cannot be trusted 184 because there is no physical security for those nodes, i.e., they 185 can be replaced by hostile nodes or can be coerced in wrong 186 behaviors. 188 The main use case for SR consists of the single administrative domain 189 where only trusted nodes with SR enabled and configured participate 190 in SR: this is the same model as in RFC6554 [RFC6554]. All non- 191 trusted nodes do not participate as either SR processing is not 192 enabled by default or because they only process SRH from nodes within 193 their domain. 195 Moreover, all SR nodes ignore SRH created by outsiders based on 196 topology information (received on a peering or internal interface) or 197 on presence and validity of the HMAC field. Therefore, if 198 intermediate nodes ONLY act on valid and authorized SRH (such as 199 within a single administrative domain), then there is no security 200 threat similar to RH-0. Hence, the RFC 5095 [RFC5095] attacks are 201 not applicable. 203 2.3. Service stealing threat 205 Segment routing is used for added value services, there is also a 206 need to prevent non-participating nodes to use those services; this 207 is called 'service stealing prevention'. 209 2.4. Topology disclosure 211 The SRH may also contains IPv6 addresses of some intermediate SR- 212 nodes in the path towards the destination, this obviously reveals 213 those addresses to the potentially hostile attackers if those 214 attackers are able to intercept packets containing SRH. On the other 215 hand, if the attacker can do a traceroute whose probes will be 216 forwarded along the SR path, then there is little learned by 217 intercepting the SRH itself. Also the clean-bit of SRH can help by 218 removing the SRH before forwarding the packet to potentially a non- 219 trusted part of the network. 221 2.5. ICMP Generation 223 Per section 4.4 of RFC2460 [RFC2460], when destination nodes (i.e. 224 where the destination address is one of theirs) receive a Routing 225 Header with unsupported Routing Type, the required behavior is: 227 o If Segments Left is zero, the node must ignore the Routing header 228 and proceed to process the next header in the packet. 230 o If Segments Left is non-zero, the node must discard the packet and 231 send an ICMP Parameter Problem, Code 0, message to the packet's 232 Source Address, pointing to the unrecognized Routing Type. 234 This required behavior could be used by an attacker to force the 235 generation of ICMP message by any node. The attacker could send 236 packets with SRH (with Segment Left set to 0) destined to a node not 237 supporting SRH. Per RFC2460 [RFC2460], the destination node could 238 generate an ICMP message, causing a local CPU utilization and if the 239 source of the offending packet with SRH was spoofed could lead to a 240 reflection attack without any amplification. 242 It must be noted that this is a required behavior for any unsupported 243 Routing Type and not limited to SRH packets. So, it is not specific 244 to SRH and the usual rate limiting for ICMP generation is required 245 anyway for any IPv6 implementation and has been implemented and 246 deployed for many years. 248 3. Security fields in SRH 250 This section summarizes the use of specific fields in the SRH; they 251 are integral part of [I-D.previdi-6man-segment-routing-header] and 252 they are again described here for reader's sake. They are based on a 253 key-hashed message authentication code (HMAC). 255 The security-related fields in SRH are: 257 o HMAC Key-id, 8 bits wide; 259 o HMAC, 256 bits wide (optional, exists only if HMAC Key-id is not 260 0). 262 The HMAC field is the output of the HMAC computation (per RFC 2104 263 [RFC2104]) using a pre-shared key identified by HMAC Key-id and of 264 the text which consists of the concatenation of: 266 o the source IPv6 address; 268 o First Segment field; 270 o an octet whose bit-0 is the clean-up bit flag and others are 0; 272 o HMAC Key-id; 274 o all addresses in the Segment List. 276 The purpose of the HMAC field is to verify the validity, the 277 integrity and the authorization of the SRH itself. If an outsider of 278 the SR domain does not have access to a current pre-shared secret, 279 then it cannot compute the right HMAC field and the first SR router 280 on the path processing the SRH and configured to check the validity 281 of the HMAC will simply reject the packet. 283 The HMAC field is located at the end of the SRH simply because only 284 the router on the ingress of the SR domain needs to process it, then 285 all other SR nodes can ignore it (based on local policy) because they 286 trust the upstream router. This is to speed up forwarding operations 287 because SR routers which do not validate the SRH do not need to parse 288 the SRH until the end. 290 The HMAC Key-id field allows for the simultaneous existence of 291 several hash algorithms (SHA-256, SHA3-256 ... or future ones) as 292 well as pre-shared keys. This allows for pre-shared key roll-over 293 when two pre-shared keys are supported for a while when all SR nodes 294 converged to a fresher pre-shared key. The HMAC Key-id field is 295 opaque, i.e., it has neither syntax not semantic except as an index 296 to the right combination of pre-shared key and hash algorithm and 297 except that a value of 0 means that there is no HMAC field. It could 298 also allow for interoperation among different SR domains if allowed 299 by local policy and assuming a collision-free Key Id allocation. 301 When a specific SRH is linked to a time-related service (such as 302 turbo-QoS for a 1-hour period) where the DA, Segment ID (SID) are 303 identical, then it is important to refresh the shared-secret 304 frequently as the HMAC validity period expires only when the HMAC 305 Key-id and its associated shared-secret expires. 307 3.1. Selecting a hash algorithm 309 The HMAC field in the SRH is 256 bit wide. Therefore, the HMAC MUST 310 be based on a hash function whose output is at least 256 bits. If 311 the output of the hash function is 256, then this output is simply 312 inserted in the HMAC field. If the output of the hash function is 313 larger than 256 bits, then the output value is truncated to 256 by 314 taking the least-significant 256 bits and inserting them in the HMAC 315 field. 317 SRH implementations can support multiple hash functions but MUST 318 implement SHA-2 [FIPS180-4] in its SHA-256 variant. 320 NOTE: SHA-1 is currently used by some early implementations used for 321 quick interoperations testing, the 160-bit hash value must then be 322 right-hand padded with 96 bits set to 0. The authors understand that 323 this is not secure but is ok for limited tests. 325 3.2. Performance impact of HMAC 327 While adding a HMAC to each and every SR packet increases the 328 security, it has a performance impact. Nevertheless, it must be 329 noted that: 331 o the HMAC field is used only when SRH is inserted by a device (such 332 as a home set-up box) which is outside of the segment routing 333 domain. If the SRH is added by a router in the trusted segment 334 routing domain, then, there is no need for a HMAC field, hence no 335 performance impact. 337 o when present, the HMAC field MUST only be checked and validated by 338 the first router of the segment routing domain, this router is 339 named 'validating SR router'. Downstream routers MAY NOT inspect 340 the HMAC field. 342 o this validating router can also have a cache of to improve the performance. It is not the 344 same use case as in IPsec where HMAC value was unique per packet, 345 in SRH, the HMAC value is unique per flow. 347 o Last point, hash functions such as SHA-2 have been optmized for 348 security and performance and there are multiple implementations 349 with good performance. 351 With the above points in mind, the performance impact of using HMAC 352 is minimized. 354 3.3. Pre-shared key management 356 The field HMAC Key-id allows for: 358 o key roll-over: when there is a need to change the key (the hash 359 pre-shared secret), then multiple pre-shared keys can be used 360 simultaneously. The validating routing can have a table of for the currently active and future 362 keys. 364 o different algorithm: by extending the previous table to , the validating router can 366 also support simultaneously several hash algorithms (see section 367 Section 3.1) 369 The pre-shared secret distribution can be done: 371 o in the configuration of the validating routers, either by static 372 configuration or any SDN oriented approach; 374 o dynamically using a trusted key distribution such as [RFC6407] 376 The intent of this document is NOT to define yet-another-key- 377 distribution-protocol. 379 4. Deployment Models 381 4.1. Nodes within the SR domain 383 A SR domain is defined as a set of interconnected routers where all 384 routers at the perimeter are configured to insert and act on SRH. 385 Some routers inside the SR domain can also act on SRH or simply 386 forward IPv6 packets. 388 The routers inside a SR domain can be trusted to generate SRH and to 389 process SRH received on interfaces that are part of the SR domain. 390 These nodes MUST drop all SRH packets received on an interface that 391 is not part of the SR domain and containing a SRH whose HMAC field 392 cannot be validated by local policies. This includes obviously 393 packet with a SRH generated by a non-cooperative SR domain. 395 If the validation fails, then these packets MUST be dropped, ICMP 396 error messages (parameter problem) SHOULD be generated (but rate 397 limited) and SHOULD be logged. 399 4.2. Nodes outside of the SR domain 401 Nodes outside of the SR domain cannot be trusted for physical 402 security; hence, they need to request by some trusted means (outside 403 of the scope of this document) a complete SRH for each new connection 404 (i.e. new destination address). The received SRH MUST include a HMAC 405 Key-id and HMAC field which is computed correctly (see Section 3). 407 When an outside node sends a packet with an SRH and towards a SR 408 domain ingress node, the packet MUST contain the HMAC Key-id and HMAC 409 field and the the destination address MUST be an address of a SR 410 domain ingress node . 412 The ingress SR router, i.e., the router with an interface address 413 equals to the destination address, MUST verify the HMAC field with 414 respect to the HMAC Key-id. 416 If the validation is successful, then the packet is simply forwarded 417 as usual for a SR packet. As long as the packet travels within the 418 SR domain, no further HMAC check needs to be done. Subsequent 419 routers in the SR domain MAY verify the HMAC field when they process 420 the SRH (i.e. when they are the destination). 422 If the validation fails, then this packet MUST be dropped, an ICMP 423 error message (parameter problem) SHOULD be generated (but rate 424 limited) and SHOULD be logged. 426 4.3. SR path exposure 428 As the intermediate SR nodes addresses appears in the SRH, if this 429 SRH is visible to an outsider then he/she could reuse this knowledge 430 to launch an attack on the intermediate SR nodes or get some insider 431 knowledge on the topology. This is especially applicable when the 432 path between the source node and the first SR domain ingress router 433 is on the public Internet. 435 The first remark is to state that 'security by obscurity' is never 436 enough; in other words, the security policy of the SR domain MUST 437 assume that the internal topology and addressing is known by the 438 attacker. A simple traceroute will also give the same information 439 (with even more information as all intermediate nodes between SID 440 will also be exposed). IPsec Encapsulating Security Payload 441 [RFC4303] cannot be use to protect the SRH as per RFC4303 the ESP 442 header must appear after any routing header (including SRH). 444 To prevent a user to leverage the gained knowledge by intercepting 445 SRH, it it recommended to apply an infrastructure Access Control List 446 (iACL) at the edge of the SR domain. This iACL will drop all packets 447 from outside the SR-domain whose destination is any address of any 448 router inside the domain. This security policy should be tuned for 449 local operations. 451 4.4. Impact of BCP-38 453 BCP-38 [RFC2827], also known as "Network Ingress Filtering", checks 454 whether the source address of packets received on an interface is 455 valid for this interface. The use of loose source routing such as 456 SRH forces packets to follow a path which differs from the expected 457 routing. Therefore, if BCP-38 was implemented in all routers inside 458 the SR domain, then SR packets could be received by an interface 459 which is not expected one and the packets could be dropped. 461 As a SR domain is usually a subset of one administrative domain, and 462 as BCP-38 is only deployed at the ingress routers of this 463 administrative domain and as packets arriving at those ingress 464 routers have been normally forwarded using the normal routing 465 information, then there is no reason why this ingress router should 466 drop the SRH packet based on BCP-38. Routers inside the domain 467 commonly do not apply BCP-38; so, this is not a problem. 469 5. IANA Considerations 471 There are no IANA request or impact in this document. 473 6. Manageability Considerations 475 TBD 477 7. Security Considerations 479 Security mechanisms applied to Segment Routing over IPv6 networks are 480 detailed in Section 3. 482 8. Acknowledgements 484 The authors would like to thank Dave Barach and Stewart Bryant for 485 their contributions to this document. 487 9. References 489 9.1. Normative References 491 [FIPS180-4] 492 National Institute of Standards and Technology, "FIPS 493 180-4 Secure Hash Standard (SHS)", March 2012, 494 . 497 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 498 Requirement Levels", BCP 14, RFC 2119, March 1997. 500 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 501 (IPv6) Specification", RFC 2460, December 1998. 503 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 504 4303, December 2005. 506 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 507 of Type 0 Routing Headers in IPv6", RFC 5095, December 508 2007. 510 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 511 of Interpretation", RFC 6407, October 2011. 513 9.2. Informative References 515 [I-D.filsfils-spring-segment-routing-use-cases] 516 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 517 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 518 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 519 Crabbe, "Segment Routing Use Cases", draft-filsfils- 520 spring-segment-routing-use-cases-01 (work in progress), 521 October 2014. 523 [I-D.ietf-isis-segment-routing-extensions] 524 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 525 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 526 Extensions for Segment Routing", draft-ietf-isis-segment- 527 routing-extensions-03 (work in progress), October 2014. 529 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 530 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 531 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 532 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 533 segment-routing-extensions-02 (work in progress), February 534 2015. 536 [I-D.ietf-spring-ipv6-use-cases] 537 Brzozowski, J., Leddy, J., Leung, I., Previdi, S., 538 Townsley, W., Martin, C., Filsfils, C., and R. Maglione, 539 "IPv6 SPRING Use Cases", draft-ietf-spring-ipv6-use- 540 cases-03 (work in progress), November 2014. 542 [I-D.ietf-spring-problem-statement] 543 Previdi, S., Filsfils, C., Decraene, B., Litkowski, S., 544 Horneffer, M., and R. Shakir, "SPRING Problem Statement 545 and Requirements", draft-ietf-spring-problem-statement-03 546 (work in progress), October 2014. 548 [I-D.ietf-spring-segment-routing] 549 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 550 Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., 551 and E. Crabbe, "Segment Routing Architecture", draft-ietf- 552 spring-segment-routing-01 (work in progress), February 553 2015. 555 [I-D.previdi-6man-segment-routing-header] 556 Previdi, S., Filsfils, C., Field, B., and I. Leung, "IPv6 557 Segment Routing Header (SRH)", draft-previdi-6man-segment- 558 routing-header-05 (work in progress), January 2015. 560 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 561 Hashing for Message Authentication", RFC 2104, February 562 1997. 564 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 565 Defeating Denial of Service Attacks which employ IP Source 566 Address Spoofing", BCP 38, RFC 2827, May 2000. 568 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 569 Co-existence Security Considerations", RFC 4942, September 570 2007. 572 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 573 Routing Header for Source Routes with the Routing Protocol 574 for Low-Power and Lossy Networks (RPL)", RFC 6554, March 575 2012. 577 Authors' Addresses 579 Eric Vyncke (editor) 580 Cisco Systems, Inc. 581 De Kleetlaann 6A 582 Diegem 1831 583 Belgium 585 Email: evyncke@cisco.com 587 Stefano Previdi 588 Cisco Systems, Inc. 589 Via Del Serafico, 200 590 Rome 00142 591 Italy 593 Email: sprevidi@cisco.com 595 David Lebrun 596 Universite Catholique de Louvain 597 Place Ste Barbe, 2 598 Louvain-la-Neuve, 1348 599 Belgium 601 Email: david.lebrun@uclouvain.be