idnits 2.17.1 draft-ietf-6man-segment-routing-header-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 14, 2015) is 3046 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 451 -- Looks like a reference, but probably isn't: '1' on line 360 -- Looks like a reference, but probably isn't: '2' on line 365 -- Looks like a reference, but probably isn't: '3' on line 370 -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180-4' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-05 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-03 == Outdated reference: A later version (-12) exists of draft-ietf-spring-ipv6-use-cases-05 == Outdated reference: A later version (-08) exists of draft-ietf-spring-problem-statement-05 == Outdated reference: A later version (-12) exists of draft-ietf-spring-resiliency-use-cases-02 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-06 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-02 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Previdi, Ed. 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: June 16, 2016 B. Field 6 Comcast 7 I. Leung 8 Rogers Communications 9 J. Linkova 10 Google 11 E. Aries 12 Facebook 13 T. Kosugi 14 NTT 15 E. Vyncke 16 Cisco Systems, Inc. 17 D. Lebrun 18 Universite Catholique de Louvain 19 December 14, 2015 21 IPv6 Segment Routing Header (SRH) 22 draft-ietf-6man-segment-routing-header-00 24 Abstract 26 Segment Routing (SR) allows a node to steer a packet through a 27 controlled set of instructions, called segments, by prepending a SR 28 header to the packet. A segment can represent any instruction, 29 topological or service-based. SR allows to enforce a flow through 30 any path (topological, or application/service based) while 31 maintaining per-flow state only at the ingress node to the SR domain. 33 Segment Routing can be applied to the IPv6 data plane with the 34 addition of a new type of Routing Extension Header. This draft 35 describes the Segment Routing Extension Header Type and how it is 36 used by SR capable nodes. 38 Requirements Language 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 42 document are to be interpreted as described in RFC 2119 [RFC2119]. 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at http://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on June 16, 2016. 61 Copyright Notice 63 Copyright (c) 2015 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (http://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1. Segment Routing Documents . . . . . . . . . . . . . . . . . . 3 79 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 80 2.1. Data Planes supporting Segment Routing . . . . . . . . . 4 81 2.2. Segment Routing (SR) Domain . . . . . . . . . . . . . . . 4 82 2.2.1. SR Domain in a Service Provider Network . . . . . . . 5 83 2.2.2. SR Domain in a Overlay Network . . . . . . . . . . . 6 84 3. Segment Routing Extension Header (SRH) . . . . . . . . . . . 7 85 3.1. SRH and RFC2460 behavior . . . . . . . . . . . . . . . . 11 86 4. SRH Procedures . . . . . . . . . . . . . . . . . . . . . . . 11 87 4.1. Segment Routing Node Functions . . . . . . . . . . . . . 11 88 4.1.1. Source SR Node . . . . . . . . . . . . . . . . . . . 12 89 4.1.2. SR Domain Ingress Node . . . . . . . . . . . . . . . 13 90 4.1.3. Transit Node . . . . . . . . . . . . . . . . . . . . 13 91 4.1.4. SR Segment Endpoint Node . . . . . . . . . . . . . . 13 92 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 93 5.1. Threat model . . . . . . . . . . . . . . . . . . . . . . 14 94 5.1.1. Source routing threats . . . . . . . . . . . . . . . 15 95 5.1.2. Applicability of RFC 5095 to SRH . . . . . . . . . . 15 96 5.1.3. Service stealing threat . . . . . . . . . . . . . . . 16 97 5.1.4. Topology disclosure . . . . . . . . . . . . . . . . . 16 98 5.1.5. ICMP Generation . . . . . . . . . . . . . . . . . . . 16 99 5.2. Security fields in SRH . . . . . . . . . . . . . . . . . 17 100 5.2.1. Selecting a hash algorithm . . . . . . . . . . . . . 18 101 5.2.2. Performance impact of HMAC . . . . . . . . . . . . . 18 102 5.2.3. Pre-shared key management . . . . . . . . . . . . . . 19 103 5.3. Deployment Models . . . . . . . . . . . . . . . . . . . . 20 104 5.3.1. Nodes within the SR domain . . . . . . . . . . . . . 20 105 5.3.2. Nodes outside of the SR domain . . . . . . . . . . . 20 106 5.3.3. SR path exposure . . . . . . . . . . . . . . . . . . 21 107 5.3.4. Impact of BCP-38 . . . . . . . . . . . . . . . . . . 21 108 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 109 7. Manageability Considerations . . . . . . . . . . . . . . . . 22 110 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 111 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 112 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 113 10.1. Normative References . . . . . . . . . . . . . . . . . . 22 114 10.2. Informative References . . . . . . . . . . . . . . . . . 23 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 117 1. Segment Routing Documents 119 Segment Routing terminology is defined in 120 [I-D.ietf-spring-segment-routing]. 122 Segment Routing use cases are described in 123 [I-D.ietf-spring-problem-statement] and 124 [I-D.ietf-spring-ipv6-use-cases]. 126 Segment Routing protocol extensions are defined in 127 [I-D.ietf-isis-segment-routing-extensions], and 128 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 130 2. Introduction 132 Segment Routing (SR), defined in [I-D.ietf-spring-segment-routing], 133 allows a node to steer a packet through a controlled set of 134 instructions, called segments, by prepending a SR header to the 135 packet. A segment can represent any instruction, topological or 136 service-based. SR allows to enforce a flow through any path 137 (topological or service/application based) while maintaining per-flow 138 state only at the ingress node to the SR domain. Segments can be 139 derived from different components: IGP, BGP, Services, Contexts, 140 Locators, etc. The list of segment forming the path is called the 141 Segment List and is encoded in the packet header. 143 SR allows the use of strict and loose source based routing paradigms 144 without requiring any additional signaling protocols in the 145 infrastructure hence delivering an excellent scalability property. 147 The source based routing model described in 148 [I-D.ietf-spring-segment-routing] is inherited from the ones proposed 149 by [RFC1940] and [RFC2460]. The source based routing model offers 150 the support for explicit routing capability. 152 2.1. Data Planes supporting Segment Routing 154 Segment Routing (SR), can be instantiated over MPLS 155 ([I-D.ietf-spring-segment-routing-mpls]) and IPv6. This document 156 defines its instantiation over the IPv6 data-plane based on the use- 157 cases defined in [I-D.ietf-spring-ipv6-use-cases]. 159 This document defines a new type of Routing Header (originally 160 defined in [RFC2460]) called the Segment Routing Header (SRH) in 161 order to convey the Segment List in the packet header as defined in 162 [I-D.ietf-spring-segment-routing]. Mechanisms through which segment 163 are known and advertised are outside the scope of this document. 165 A segment is materialized by an IPv6 address. A segment identifies a 166 topological instruction or a service instruction. A segment can be 167 either: 169 o global: a global segment represents an instruction supported by 170 all nodes in the SR domain and it is instantiated through an IPv6 171 address globally known in the SR domain. 173 o local: a local segment represents an instruction supported only by 174 the node who originates it and it is instantiated through an IPv6 175 address that is known only by the local node. 177 2.2. Segment Routing (SR) Domain 179 We define the concept of the Segment Routing Domain (SR Domain) as 180 the set of nodes participating into the source based routing model. 181 These nodes may be connected to the same physical infrastructure 182 (e.g.: a Service Provider's network) as well as nodes remotely 183 connected to each other (e.g.: an enterprise VPN or an overlay). 185 A non-exhaustive list of examples of SR Domains is: 187 o The network of an operator, service provider, content provider, 188 enterprise including nodes, links and Autonomous Systems. 190 o A set of nodes connected as an overlay over one or more transit 191 providers. The overlay nodes exchange SR-enabled traffic with 192 segments belonging solely to the overlay routers (the SR domain). 193 None of the segments in the SR-enabled packets exchanged by the 194 overlay belong to the transit networks 196 The source based routing model through its instantiation of the 197 Segment Routing Header (SRH) defined in this document equally applies 198 to all the above examples. 200 While the source routing model defined in [RFC2460] doesn't mandate 201 which node is allowed to insert (or modify) the SRH, it is assumed in 202 this document that the SRH is inserted in the packet by its source. 203 For example: 205 o At the node originating the packet (host, server). 207 o At the ingress node of a SR domain where the ingress node receives 208 an IPv6 packet and encapsulates it into an outer IPv6 header 209 followed by a Segment Routing header. 211 2.2.1. SR Domain in a Service Provider Network 213 The following figure illustrates an SR domain consisting of an 214 operator's network infrastructure. 216 (-------------------------- Operator 1 -----------------------) 217 ( ) 218 ( (-----AS 1-----) (-------AS 2-------) (----AS 3-------) ) 219 ( ( ) ( ) ( ) ) 220 A1--(--(--11---13--14-)--(-21---22---23--24-)--(-31---32---34--)--)--Z1 221 ( ( /|\ /|\ /| ) ( |\ /|\ /|\ /| ) ( |\ /|\ /| \ ) ) 222 A2--(--(/ | \/ | \/ | ) ( | \/ | \/ | \/ | ) ( | \/ | \/ | \)--)--Z2 223 ( ( | /\ | /\ | ) ( | /\ | /\ | /\ | ) ( | /\ | /\ | ) ) 224 ( ( |/ \|/ \| ) ( |/ \|/ \|/ \| ) ( |/ \|/ \| ) ) 225 A3--(--(--15---17--18-)--(-25---26---27--28-)--(-35---36---38--)--)--Z3 226 ( ( ) ( ) ( ) ) 227 ( (--------------) (------------------) (---------------) ) 228 ( ) 229 (-------------------------------------------------------------) 231 Figure 1: Service Provider SR Domain 233 Figure 1 describes an operator network including several ASes and 234 delivering connectivity between endpoints. In this scenario, Segment 235 Routing is used within the operator networks and across the ASes 236 boundaries (all being under the control of the same operator). In 237 this case segment routing can be used in order to address use cases 238 such as end-to-end traffic engineering, fast re-route, egress peer 239 engineering, data-center traffic engineering as described in 240 [I-D.ietf-spring-problem-statement], [I-D.ietf-spring-ipv6-use-cases] 241 and [I-D.ietf-spring-resiliency-use-cases]. 243 Typically, an IPv6 packet received at ingress (i.e.: from outside the 244 SR domain), is classified according to network operator policies and 245 such classification results into an outer header with an SRH applied 246 to the incoming packet. The SRH contains the list of segment 247 representing the path the packet must take inside the SR domain. 248 Thus, the SA of the packet is the ingress node, the DA (due to SRH 249 procedures described in Section 4) is set as the first segment of the 250 path and the last segment of the path is the egress node of the SR 251 domain. 253 The path may include intra-AS as well as inter-AS segments. It has 254 to be noted that all nodes within the SR domain are under control of 255 the same administration. When the packet reaches the egress point of 256 the SR domain, the outer header and its SRH are removed so that the 257 destination of the packet is unaware of the SR domain the packet has 258 traversed. 260 The outer header with the SRH is no different from any other 261 tunneling encapsulation mechanism and allows a network operator to 262 implement traffic engineering mechanisms so to efficiently steer 263 traffic across his infrastructure. 265 2.2.2. SR Domain in a Overlay Network 267 The following figure illustrates an SR domain consisting of an 268 overlay network over multiple operator's networks. 270 (--Operator 1---) (-----Operator 2-----) (--Operator 3---) 271 ( ) ( ) ( ) 272 A1--(--11---13--14--)--(--21---22---23--24--)--(-31---32---34--)--C1 273 ( /|\ /|\ /| ) ( |\ /|\ /|\ /| ) ( |\ /|\ /| \ ) 274 A2--(/ | \/ | \/ | ) ( | \/ | \/ | \/ | ) ( | \/ | \/ | \)--C2 275 ( | /\ | /\ | ) ( | /\ | /\ | /\ | ) ( | /\ | /\ | ) 276 ( |/ \|/ \| ) ( |/ \|/ \|/ \| ) ( |/ \|/ \| ) 277 A3--(--15---17--18--)--(--25---26---27--28--)--(-35---36---38--)--C3 278 ( ) ( | | | ) ( ) 279 (---------------) (--|----|---------|--) (---------------) 280 | | | 281 B1 B2 B3 283 Figure 2: Overlay SR Domain 285 Figure 2 describes an overlay consisting of nodes connected to three 286 different network operators and forming a single overlay network 287 where Segment routing packets are exchanged. 289 The overlay consists of nodes A1, A2, A3, B1, B2, B3, C1, C2 and C3. 290 These nodes are connected to their respective network operator and 291 form an overlay network. 293 Each node may originate packets with an SRH which contains, in the 294 segment list of the SRH or in the DA, segments identifying other 295 overlay nodes. This implies that packets with an SRH may traverse 296 operator's networks but, obviously, these SRHs cannot contain an 297 address/segment of the transit operators 1, 2 and 3. The SRH 298 originated by the overlay can only contain address/segment under the 299 administration of the overlay (e.g. address/segments supported by A1, 300 A2, A3, B1, B2, B3, C1,C2 or C3). 302 In this model, the operator network nodes are transit nodes and, 303 according to [RFC2460], MUST NOT inspect the routing extension header 304 since there are not the DA of the packet. 306 It is a common practice in operators networks to filter out, at 307 ingress, any packet whose DA is the address of an internal node and 308 it is also possible that an operator would filter out any packet 309 destined to an internal address and having an extension header in it. 311 This common practice does not impact the SR-enabled traffic between 312 the overlay nodes as the intermediate transit networks do never see a 313 destination address belonging to their infrastructure. These SR- 314 enabled overlay packets will thus never be filtered by the transit 315 operators. 317 In all cases, transit packets (i.e.: packets whose DA is outside the 318 domain of the operator's network) will be forwarded accordingly 319 without introducing any security concern in the operator's network. 320 This is similar to tunneled packets. 322 3. Segment Routing Extension Header (SRH) 324 A new type of the Routing Header (originally defined in [RFC2460]) is 325 defined: the Segment Routing Header (SRH) which has a new Routing 326 Type, (suggested value 4) to be assigned by IANA. 328 The Segment Routing Header (SRH) is defined as follows: 330 0 1 2 3 331 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 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | First Segment | Flags | HMAC Key ID | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | | 339 | Segment List[0] (128 bits IPv6 address) | 340 | | 341 | | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | | 344 | | 345 ... 346 | | 347 | | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | | 350 | Segment List[n] (128 bits IPv6 address) | 351 | | 352 | | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | | 355 | Policy List[0] (optional) | 356 | | 357 | | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | | 360 | Policy List[1] (optional) | 361 | | 362 | | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | | 365 | Policy List[2] (optional) | 366 | | 367 | | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | | 370 | Policy List[3] (optional) | 371 | | 372 | | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | | 375 | | 376 | | 377 | HMAC (256 bits) | 378 | (optional) | 379 | | 380 | | 381 | | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 where: 386 o Next Header: 8-bit selector. Identifies the type of header 387 immediately following the SRH. 389 o Hdr Ext Len: 8-bit unsigned integer, is the length of the SRH 390 header in 8-octet units, not including the first 8 octets. 392 o Routing Type: TBD, to be assigned by IANA (suggested value: 4). 394 o Segments Left. Defined in [RFC2460], it contains the index, in 395 the Segment List, of the next segment to inspect. Segments Left 396 is decremented at each segment. 398 o First Segment: contains the index, in the Segment List, of the 399 first segment of the path which is in fact the last element of the 400 Segment List. 402 o Flags: 16 bits of flags. Following flags are defined: 404 1 405 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 |C|P|R|R| Policy Flags | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 C-flag: Clean-up flag. Set when the SRH has to be removed from 411 the packet when packet reaches the last segment. 413 P-flag: Protected flag. Set when the packet has been rerouted 414 through FRR mechanism by a SR endpoint node. 416 R-flags. Reserved and for future use. 418 Policy Flags. Define the type of the IPv6 addresses encoded 419 into the Policy List (see below). The following have been 420 defined: 422 Bits 4-6: determine the type of the first element after the 423 segment list. 425 Bits 7-9: determine the type of the second element. 427 Bits 10-12: determine the type of the third element. 429 Bits 13-15: determine the type of the fourth element. 431 The following values are used for the type: 433 0x0: Not present. If value is set to 0x0, it means the 434 element represented by these bits is not present. 436 0x1: SR Ingress. 438 0x2: SR Egress. 440 0x3: Original Source Address. 442 0x4 to 0x7: currently unused and SHOULD be ignored on 443 reception. 445 o HMAC Key ID and HMAC field, and their use are defined in 446 Section 5. 448 o Segment List[n]: 128 bit IPv6 addresses representing the nth 449 segment in the Segment List. The Segment List is encoded starting 450 from the last segment of the path. I.e., the first element of the 451 segment list (Segment List [0]) contains the last segment of the 452 path while the last segment of the Segment List (Segment List[n]) 453 contains the first segment of the path. The index contained in 454 "Segments Left" identifies the current active segment. 456 o Policy List. Optional addresses representing specific nodes in 457 the SR path such as: 459 SR Ingress: a 128 bit generic identifier representing the 460 ingress in the SR domain (i.e.: it needs not to be a valid IPv6 461 address). 463 SR Egress: a 128 bit generic identifier representing the egress 464 in the SR domain (i.e.: it needs not to be a valid IPv6 465 address). 467 Original Source Address: IPv6 address originally present in the 468 SA field of the packet. 470 The segments in the Policy List are encoded after the segment list 471 and they are optional. If none are in the SRH, all bits of the 472 Policy List Flags MUST be set to 0x0. 474 3.1. SRH and RFC2460 behavior 476 The SRH being a new type of the Routing Header, it also has the same 477 properties: 479 SHOULD only appear once in the packet. 481 Only the router whose address is in the DA field of the packet 482 header MUST inspect the SRH. 484 Therefore, Segment Routing in IPv6 networks implies that the segment 485 identifier (i.e.: the IPv6 address of the segment) is moved into the 486 DA of the packet. 488 The DA of the packet changes at each segment termination/completion 489 and therefore the final DA of the packet MUST be encoded as the last 490 segment of the path. 492 4. SRH Procedures 494 In this section we describe the different procedures on the SRH. 496 4.1. Segment Routing Node Functions 498 SR packets are forwarded to segments endpoints (i.e.: the segment 499 endpoint is the node representing the segment and whose address is in 500 the segment list and in the DA of the packet when traveling in the 501 segment). The segment endpoint, when receiving a SR packet destined 502 to itself, does: 504 o Inspect the SRH. 506 o Determine the next active segment. 508 o Update the Segments Left field (or, if requested, remove the SRH 509 from the packet). 511 o Update the DA. 513 o Forward the packet to the next segment. 515 The procedures applied to the SRH are related to the node function. 516 Following nodes functions are defined: 518 Source SR Node. 520 SR Domain Ingress Node. 522 Transit Node. 524 SR Endpoint Node. 526 4.1.1. Source SR Node 528 A Source SR Node can be any node originating an IPv6 packet with its 529 IPv6 and Segment Routing Headers. This include either: 531 A host originating an IPv6 packet 533 A SR domain ingress router encapsulating a received IPv6 packet 534 into an outer IPv6 header followed by a SRH 536 The mechanism through which a Segment List is derived is outside of 537 the scope of this document. As an example, the Segment List may be 538 obtained through: 540 Local path computation. 542 Local configuration. 544 Interaction with a centralized controller delivering the path. 546 Any other mechanism. 548 The following are the steps of the creation of the SRH: 550 Next Header and Hdr Ext Len fields are set according to [RFC2460]. 552 Routing Type field is set as TBD (SRH). 554 The Segment List is built with the FIRST segment of the path 555 encoded in the LAST element of the Segment List. Subsequent 556 segments are encoded on top of the first segment. Finally, the 557 LAST segment of the path is encoded in the FIRST element of the 558 Segment List. In other words, the Segment List is encoded in the 559 reverse order of the path. 561 The final DA of the packet is encoded as the last segment of the 562 path (encoded in the first element of the Segment List). 564 The DA of the packet is set with the value of the first segment 565 (found in the last element of the segment list). 567 The Segments Left field is set to n-1 where n is the number of 568 elements in the Segment List. 570 The First Segment field is set to n-1 where n is the number of 571 elements in the Segment List. 573 The packet is sent out towards the first segment (i.e.: 574 represented in the packet DA). 576 HMAC and HMAC Key ID may be set according to Section 5. 578 4.1.2. SR Domain Ingress Node 580 The SR Domain Ingress Node is the node where ingress policies are 581 applied and where the packet path (and processing) is determined. 583 After policies are applied and packet classification is done, the 584 result may be instantiated into a Segment List representing the path 585 the packet should take. In such case, the SR Domain Ingress Node 586 instantiate a new outer IPv6 header to which the SRH is appended 587 (with the computed Segment List). The procedures for the creation 588 and insertion of the new SRH are described in Section 4.1.1. 590 4.1.3. Transit Node 592 According to [RFC2460], the only node who is allowed to inspect the 593 Routing Extension Header (and therefore the SRH), is the node 594 corresponding to the DA of the packet. Any other transit node MUST 595 NOT inspect the underneath routing header and MUST forward the packet 596 towards the DA and according to the IPv6 routing table. 598 In the example case described in Section 2.2.2, when SR capable nodes 599 are connected through an overlay spanning multiple third-party 600 infrastructure, it is safe to send SRH packets (i.e.: packet having a 601 Segment Routing Header) between each other overlay/SR-capable nodes 602 as long as the segment list does not include any of the transit 603 provider nodes. In addition, as a generic security measure, any 604 service provider will block any packet destined to one of its 605 internal routers, especially if these packets have an extended header 606 in it. 608 4.1.4. SR Segment Endpoint Node 610 The SR segment endpoint node is the node whose address is in the DA. 611 The segment endpoint node inspects the SRH and does: 613 1. IF DA = myself (segment endpoint) 614 2. IF Segments Left > 0 THEN 615 decrement Segments Left 616 update DA with Segment List[Segments Left] 617 3. IF Segments Left == 0 THEN 618 IF Clean-up bit is set THEN remove the SRH 619 4. ELSE continue IPv6 processing of the packet 620 End of processing. 621 5. Forward the packet out 623 5. Security Considerations 625 This section analyzes the security threat model, the security issues 626 and proposed solutions related to the new Segment Routing Header. 628 The Segment Routing Header (SRH) is simply another type of the 629 routing header as described in RFC 2460 [RFC2460] and is: 631 o inserted by a SR edge router when entering the segment routing 632 domain or by the originating host itself. The source host can 633 even be outside the SR domain; 635 o inspected and acted upon when reaching the destination address of 636 the IP header per RFC 2460 [RFC2460]. 638 Per RFC2460 [RFC2460], routers on the path that simply forward an 639 IPv6 packet (i.e. the IPv6 destination address is none of theirs) 640 will never inspect and process the content of SRH. Routers whose one 641 interface IPv6 address equals the destination address field of the 642 IPv6 packet MUST to parse the SRH and, if supported and if the local 643 configuration allows it, MUST act accordingly to the SRH content. 645 According to RFC2460 [RFC2460], the default behavior of a non SR- 646 capable router upon receipt of an IPv6 packet with SRH destined to an 647 address of its, is to: 649 o ignore the SRH completely if the Segment Left field is 0 and 650 proceed to process the next header in the IPv6 packet; 652 o discard the IPv6 packet if Segment Left field is greater than 0, 653 it MAY send a Parameter Problem ICMP message back to the Source 654 Address. 656 5.1. Threat model 657 5.1.1. Source routing threats 659 Using a SRH is similar to source routing, therefore it has some well- 660 known security issues as described in RFC4942 [RFC4942] section 2.1.1 661 and RFC5095 [RFC5095]: 663 o amplification attacks: where a packet could be forged in such a 664 way to cause looping among a set of SR-enabled routers causing 665 unnecessary traffic, hence a Denial of Service (DoS) against 666 bandwidth; 668 o reflection attack: where a hacker could force an intermediate node 669 to appear as the immediate attacker, hence hiding the real 670 attacker from naive forensic; 672 o bypass attack: where an intermediate node could be used as a 673 stepping stone (for example in a De-Militarized Zone) to attack 674 another host (for example in the datacenter or any back-end 675 server). 677 5.1.2. Applicability of RFC 5095 to SRH 679 First of all, the reader must remember this specific part of section 680 1 of RFC5095 [RFC5095], "A side effect is that this also eliminates 681 benign RH0 use-cases; however, such applications may be facilitated 682 by future Routing Header specifications.". In short, it is not 683 forbidden to create new secure type of Routing Header; for example, 684 RFC 6554 (RPL) [RFC6554] also creates a new Routing Header type for a 685 specific application confined in a single network. 687 In the segment routing architecture described in 688 [I-D.ietf-spring-segment-routing] there are basically two kinds of 689 nodes (routers and hosts): 691 o nodes within the SR domain, which is within one single 692 administrative domain, i.e., where all nodes are trusted anyway 693 else the damage caused by those nodes could be worse than 694 amplification attacks: traffic interception, man-in-the-middle 695 attacks, more server DoS by dropping packets, and so on. 697 o nodes outside of the SR domain, which is outside of the 698 administrative segment routing domain hence they cannot be trusted 699 because there is no physical security for those nodes, i.e., they 700 can be replaced by hostile nodes or can be coerced in wrong 701 behaviors. 703 The main use case for SR consists of the single administrative domain 704 where only trusted nodes with SR enabled and configured participate 705 in SR: this is the same model as in RFC6554 [RFC6554]. All non- 706 trusted nodes do not participate as either SR processing is not 707 enabled by default or because they only process SRH from nodes within 708 their domain. 710 Moreover, all SR nodes ignore SRH created by outsiders based on 711 topology information (received on a peering or internal interface) or 712 on presence and validity of the HMAC field. Therefore, if 713 intermediate nodes ONLY act on valid and authorized SRH (such as 714 within a single administrative domain), then there is no security 715 threat similar to RH-0. Hence, the RFC 5095 [RFC5095] attacks are 716 not applicable. 718 5.1.3. Service stealing threat 720 Segment routing is used for added value services, there is also a 721 need to prevent non-participating nodes to use those services; this 722 is called 'service stealing prevention'. 724 5.1.4. Topology disclosure 726 The SRH may also contains IPv6 addresses of some intermediate SR- 727 nodes in the path towards the destination, this obviously reveals 728 those addresses to the potentially hostile attackers if those 729 attackers are able to intercept packets containing SRH. On the other 730 hand, if the attacker can do a traceroute whose probes will be 731 forwarded along the SR path, then there is little learned by 732 intercepting the SRH itself. Also the clean-bit of SRH can help by 733 removing the SRH before forwarding the packet to potentially a non- 734 trusted part of the network. 736 5.1.5. ICMP Generation 738 Per section 4.4 of RFC2460 [RFC2460], when destination nodes (i.e. 739 where the destination address is one of theirs) receive a Routing 740 Header with unsupported Routing Type, the required behavior is: 742 o If Segments Left is zero, the node must ignore the Routing header 743 and proceed to process the next header in the packet. 745 o If Segments Left is non-zero, the node must discard the packet and 746 send an ICMP Parameter Problem, Code 0, message to the packet's 747 Source Address, pointing to the unrecognized Routing Type. 749 This required behavior could be used by an attacker to force the 750 generation of ICMP message by any node. The attacker could send 751 packets with SRH (with Segment Left set to 0) destined to a node not 752 supporting SRH. Per RFC2460 [RFC2460], the destination node could 753 generate an ICMP message, causing a local CPU utilization and if the 754 source of the offending packet with SRH was spoofed could lead to a 755 reflection attack without any amplification. 757 It must be noted that this is a required behavior for any unsupported 758 Routing Type and not limited to SRH packets. So, it is not specific 759 to SRH and the usual rate limiting for ICMP generation is required 760 anyway for any IPv6 implementation and has been implemented and 761 deployed for many years. 763 5.2. Security fields in SRH 765 This section summarizes the use of specific fields in the SRH. They 766 are based on a key-hashed message authentication code (HMAC). 768 The security-related fields in SRH are: 770 o HMAC Key-id, 8 bits wide; 772 o HMAC, 256 bits wide (optional, exists only if HMAC Key-id is not 773 0). 775 The HMAC field is the output of the HMAC computation (per RFC 2104 776 [RFC2104]) using a pre-shared key identified by HMAC Key-id and of 777 the text which consists of the concatenation of: 779 o the source IPv6 address; 781 o First Segment field; 783 o an octet whose bit-0 is the clean-up bit flag and others are 0; 785 o HMAC Key-id; 787 o all addresses in the Segment List. 789 The purpose of the HMAC field is to verify the validity, the 790 integrity and the authorization of the SRH itself. If an outsider of 791 the SR domain does not have access to a current pre-shared secret, 792 then it cannot compute the right HMAC field and the first SR router 793 on the path processing the SRH and configured to check the validity 794 of the HMAC will simply reject the packet. 796 The HMAC field is located at the end of the SRH simply because only 797 the router on the ingress of the SR domain needs to process it, then 798 all other SR nodes can ignore it (based on local policy) because they 799 trust the upstream router. This is to speed up forwarding operations 800 because SR routers which do not validate the SRH do not need to parse 801 the SRH until the end. 803 The HMAC Key-id field allows for the simultaneous existence of 804 several hash algorithms (SHA-256, SHA3-256 ... or future ones) as 805 well as pre-shared keys. The HMAC Key-id field is opaque, i.e., it 806 has neither syntax nor semantic except as an index to the right 807 combination of pre-shared key and hash algorithm and except that a 808 value of 0 means that there is no HMAC field. Having a HMAC Key-id 809 field allows for pre-shared key roll-over when two pre-shared keys 810 are supported for a while when all SR nodes converged to a fresher 811 pre-shared key. It could also allow for interoperation among 812 different SR domains if allowed by local policy and assuming a 813 collision-free HMAC Key Id allocation. 815 When a specific SRH is linked to a time-related service (such as 816 turbo-QoS for a 1-hour period) where the DA, Segment ID (SID) are 817 identical, then it is important to refresh the shared-secret 818 frequently as the HMAC validity period expires only when the HMAC 819 Key-id and its associated shared-secret expires. 821 5.2.1. Selecting a hash algorithm 823 The HMAC field in the SRH is 256 bit wide. Therefore, the HMAC MUST 824 be based on a hash function whose output is at least 256 bits. If 825 the output of the hash function is 256, then this output is simply 826 inserted in the HMAC field. If the output of the hash function is 827 larger than 256 bits, then the output value is truncated to 256 by 828 taking the least-significant 256 bits and inserting them in the HMAC 829 field. 831 SRH implementations can support multiple hash functions but MUST 832 implement SHA-2 [FIPS180-4] in its SHA-256 variant. 834 NOTE: SHA-1 is currently used by some early implementations used for 835 quick interoperations testing, the 160-bit hash value must then be 836 right-hand padded with 96 bits set to 0. The authors understand that 837 this is not secure but is ok for limited tests. 839 5.2.2. Performance impact of HMAC 841 While adding a HMAC to each and every SR packet increases the 842 security, it has a performance impact. Nevertheless, it must be 843 noted that: 845 o the HMAC field is used only when SRH is inserted by a device (such 846 as a home set-up box) which is outside of the segment routing 847 domain. If the SRH is added by a router in the trusted segment 848 routing domain, then, there is no need for a HMAC field, hence no 849 performance impact. 851 o when present, the HMAC field MUST only be checked and validated by 852 the first router of the segment routing domain, this router is 853 named 'validating SR router'. Downstream routers may not inspect 854 the HMAC field. 856 o this validating router can also have a cache of to improve the performance. It is not the 858 same use case as in IPsec where HMAC value was unique per packet, 859 in SRH, the HMAC value is unique per flow. 861 o Last point, hash functions such as SHA-2 have been optimized for 862 security and performance and there are multiple implementations 863 with good performance. 865 With the above points in mind, the performance impact of using HMAC 866 is minimized. 868 5.2.3. Pre-shared key management 870 The field HMAC Key-id allows for: 872 o key roll-over: when there is a need to change the key (the hash 873 pre-shared secret), then multiple pre-shared keys can be used 874 simultaneously. The validating routing can have a table of for the currently active and future 876 keys. 878 o different algorithms: by extending the previous table to , the validating router 880 can also support simultaneously several hash algorithms (see 881 section Section 5.2.1) 883 The pre-shared secret distribution can be done: 885 o in the configuration of the validating routers, either by static 886 configuration or any SDN oriented approach; 888 o dynamically using a trusted key distribution such as [RFC6407] 890 The intent of this document is NOT to define yet-another-key- 891 distribution-protocol. 893 5.3. Deployment Models 895 5.3.1. Nodes within the SR domain 897 A SR domain is defined as a set of interconnected routers where all 898 routers at the perimeter are configured to insert and act on SRH. 899 Some routers inside the SR domain can also act on SRH or simply 900 forward IPv6 packets. 902 The routers inside a SR domain can be trusted to generate SRH and to 903 process SRH received on interfaces that are part of the SR domain. 904 These nodes MUST drop all SRH packets received on an interface that 905 is not part of the SR domain and containing a SRH whose HMAC field 906 cannot be validated by local policies. This includes obviously 907 packet with a SRH generated by a non-cooperative SR domain. 909 If the validation fails, then these packets MUST be dropped, ICMP 910 error messages (parameter problem) SHOULD be generated (but rate 911 limited) and SHOULD be logged. 913 5.3.2. Nodes outside of the SR domain 915 Nodes outside of the SR domain cannot be trusted for physical 916 security; hence, they need to request by some trusted means (outside 917 of the scope of this document) a complete SRH for each new connection 918 (i.e. new destination address). The received SRH MUST include a HMAC 919 Key-id and HMAC field which is computed correctly (see Section 5.2). 921 When an outside node sends a packet with an SRH and towards a SR 922 domain ingress node, the packet MUST contain the HMAC Key-id and HMAC 923 field and the the destination address MUST be an address of a SR 924 domain ingress node . 926 The ingress SR router, i.e., the router with an interface address 927 equals to the destination address, MUST verify the HMAC field with 928 respect to the HMAC Key-id. 930 If the validation is successful, then the packet is simply forwarded 931 as usual for a SR packet. As long as the packet travels within the 932 SR domain, no further HMAC check needs to be done. Subsequent 933 routers in the SR domain MAY verify the HMAC field when they process 934 the SRH (i.e. when they are the destination). 936 If the validation fails, then this packet MUST be dropped, an ICMP 937 error message (parameter problem) SHOULD be generated (but rate 938 limited) and SHOULD be logged. 940 5.3.3. SR path exposure 942 As the intermediate SR nodes addresses appears in the SRH, if this 943 SRH is visible to an outsider then he/she could reuse this knowledge 944 to launch an attack on the intermediate SR nodes or get some insider 945 knowledge on the topology. This is especially applicable when the 946 path between the source node and the first SR domain ingress router 947 is on the public Internet. 949 The first remark is to state that 'security by obscurity' is never 950 enough; in other words, the security policy of the SR domain MUST 951 assume that the internal topology and addressing is known by the 952 attacker. A simple traceroute will also give the same information 953 (with even more information as all intermediate nodes between SID 954 will also be exposed). IPsec Encapsulating Security Payload 955 [RFC4303] cannot be use to protect the SRH as per RFC4303 the ESP 956 header must appear after any routing header (including SRH). 958 To prevent a user to leverage the gained knowledge by intercepting 959 SRH, it it recommended to apply an infrastructure Access Control List 960 (iACL) at the edge of the SR domain. This iACL will drop all packets 961 from outside the SR-domain whose destination is any address of any 962 router inside the domain. This security policy should be tuned for 963 local operations. 965 5.3.4. Impact of BCP-38 967 BCP-38 [RFC2827], also known as "Network Ingress Filtering", checks 968 whether the source address of packets received on an interface is 969 valid for this interface. The use of loose source routing such as 970 SRH forces packets to follow a path which differs from the expected 971 routing. Therefore, if BCP-38 was implemented in all routers inside 972 the SR domain, then SR packets could be received by an interface 973 which is not expected one and the packets could be dropped. 975 As a SR domain is usually a subset of one administrative domain, and 976 as BCP-38 is only deployed at the ingress routers of this 977 administrative domain and as packets arriving at those ingress 978 routers have been normally forwarded using the normal routing 979 information, then there is no reason why this ingress router should 980 drop the SRH packet based on BCP-38. Routers inside the domain 981 commonly do not apply BCP-38; so, this is not a problem. 983 6. IANA Considerations 985 This document makes the following registrations in the Internet 986 Protocol Version 6 (IPv6) Parameters "Routing Type" registry 987 maintained by IANA: 989 Suggested Description Reference 990 Value 991 ---------------------------------------------------------- 992 4 Segment Routing Header (SRH) This document 994 7. Manageability Considerations 996 TBD 998 8. Contributors 1000 Dave Barach, John Leddy, John Brzozowski, Pierre Francois, Nagendra 1001 Kumar, Mark Townsley, Christian Martin, Roberta Maglione, James 1002 Connolly, Aloys Augustin contributed to the content of this document. 1004 9. Acknowledgements 1006 The authors would like to thank Ole Troan, Bob Hinden, Fred Baker, 1007 Brian Carpenter and Alexandru Petrescu for their comments to this 1008 document. 1010 10. References 1012 10.1. Normative References 1014 [FIPS180-4] 1015 National Institute of Standards and Technology, "FIPS 1016 180-4 Secure Hash Standard (SHS)", March 2012, 1017 . 1020 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1021 Requirement Levels", BCP 14, RFC 2119, 1022 DOI 10.17487/RFC2119, March 1997, 1023 . 1025 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1026 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1027 December 1998, . 1029 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1030 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1031 . 1033 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1034 of Type 0 Routing Headers in IPv6", RFC 5095, 1035 DOI 10.17487/RFC5095, December 2007, 1036 . 1038 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 1039 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 1040 October 2011, . 1042 10.2. Informative References 1044 [I-D.ietf-isis-segment-routing-extensions] 1045 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 1046 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 1047 Extensions for Segment Routing", draft-ietf-isis-segment- 1048 routing-extensions-05 (work in progress), June 2015. 1050 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 1051 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1052 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 1053 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 1054 segment-routing-extensions-03 (work in progress), June 1055 2015. 1057 [I-D.ietf-spring-ipv6-use-cases] 1058 Brzozowski, J., Leddy, J., Leung, I., Previdi, S., 1059 Townsley, W., Martin, C., Filsfils, C., and R. Maglione, 1060 "IPv6 SPRING Use Cases", draft-ietf-spring-ipv6-use- 1061 cases-05 (work in progress), September 2015. 1063 [I-D.ietf-spring-problem-statement] 1064 Previdi, S., Filsfils, C., Decraene, B., Litkowski, S., 1065 Horneffer, M., and r. rjs@rob.sh, "SPRING Problem 1066 Statement and Requirements", draft-ietf-spring-problem- 1067 statement-05 (work in progress), October 2015. 1069 [I-D.ietf-spring-resiliency-use-cases] 1070 Francois, P., Filsfils, C., Decraene, B., and r. 1071 rjs@rob.sh, "Use-cases for Resiliency in SPRING", draft- 1072 ietf-spring-resiliency-use-cases-02 (work in progress), 1073 December 2015. 1075 [I-D.ietf-spring-segment-routing] 1076 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 1077 and r. rjs@rob.sh, "Segment Routing Architecture", draft- 1078 ietf-spring-segment-routing-06 (work in progress), October 1079 2015. 1081 [I-D.ietf-spring-segment-routing-mpls] 1082 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1083 Litkowski, S., Horneffer, M., rjs@rob.sh, r., Tantsura, 1084 J., and E. Crabbe, "Segment Routing with MPLS data plane", 1085 draft-ietf-spring-segment-routing-mpls-02 (work in 1086 progress), October 2015. 1088 [RFC1940] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D. 1089 Zappala, "Source Demand Routing: Packet Format and 1090 Forwarding Specification (Version 1)", RFC 1940, 1091 DOI 10.17487/RFC1940, May 1996, 1092 . 1094 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1095 Hashing for Message Authentication", RFC 2104, 1096 DOI 10.17487/RFC2104, February 1997, 1097 . 1099 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1100 Defeating Denial of Service Attacks which employ IP Source 1101 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1102 May 2000, . 1104 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 1105 Co-existence Security Considerations", RFC 4942, 1106 DOI 10.17487/RFC4942, September 2007, 1107 . 1109 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 1110 Routing Header for Source Routes with the Routing Protocol 1111 for Low-Power and Lossy Networks (RPL)", RFC 6554, 1112 DOI 10.17487/RFC6554, March 2012, 1113 . 1115 Authors' Addresses 1117 Stefano Previdi (editor) 1118 Cisco Systems, Inc. 1119 Via Del Serafico, 200 1120 Rome 00142 1121 Italy 1123 Email: sprevidi@cisco.com 1124 Clarence Filsfils 1125 Cisco Systems, Inc. 1126 Brussels 1127 BE 1129 Email: cfilsfil@cisco.com 1131 Brian Field 1132 Comcast 1133 4100 East Dry Creek Road 1134 Centennial, CO 80122 1135 US 1137 Email: Brian_Field@cable.comcast.com 1139 Ida Leung 1140 Rogers Communications 1141 8200 Dixie Road 1142 Brampton, ON L6T 0C1 1143 CA 1145 Email: Ida.Leung@rci.rogers.com 1147 Jen Linkova 1148 Google 1149 1600 Amphitheatre Parkway 1150 Mountain View, CA 94043 1151 US 1153 Email: furry@google.com 1155 Ebben Aries 1156 Facebook 1157 US 1159 Email: exa@fb.com 1160 Tomoya Kosugi 1161 NTT 1162 3-9-11, Midori-Cho Musashino-Shi, 1163 Tokyo 180-8585 1164 JP 1166 Email: kosugi.tomoya@lab.ntt.co.jp 1168 Eric Vyncke 1169 Cisco Systems, Inc. 1170 De Kleetlaann 6A 1171 Diegem 1831 1172 Belgium 1174 Email: evyncke@cisco.com 1176 David Lebrun 1177 Universite Catholique de Louvain 1178 Place Ste Barbe, 2 1179 Louvain-la-Neuve, 1348 1180 Belgium 1182 Email: david.lebrun@uclouvain.be