idnits 2.17.1 draft-rahman-rtg-router-alert-considerations-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 9, 2009) is 5527 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC5350' is defined on line 513, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Le Faucheur, Ed. 3 Internet-Draft Cisco 4 Intended status: BCP March 9, 2009 5 Expires: September 10, 2009 7 IP Router Alert Considerations and Usage 8 draft-rahman-rtg-router-alert-considerations-01 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on September 10, 2009. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 The IP Router Alert Option is an IP option that alerts transit 57 routers to more closely examine the contents of an IP packet. RSVP, 58 PGM, IGMP/MLD and MRD are some of the protocols which make use of the 59 IP Router Alert option. This document discusses security aspects and 60 common practices around the use of the current IP Router Alert option 61 and discusses consequences on the use of IP Router Alert by existing 62 or new applications. Common practices in IP Router Alert 63 implementation facilitating router protection are also discussed. 65 Table of Contents 67 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 69 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. Guidelines for use of Router Alert . . . . . . . . . . . . . . 7 71 3.1. Reliance on Router Alert by Applications . . . . . . . . . 7 72 3.2. When Consenting Adults Exchange IP Router Alert Packets . 8 73 4. Example Protection Mechanisms in a Router Alert 74 Implementation . . . . . . . . . . . . . . . . . . . . . . . . 10 75 4.1. Handling Packets Carrying the Router Alert Option . . . . 10 76 4.2. Applying Rate Limiting . . . . . . . . . . . . . . . . . . 10 77 4.3. Router Alert in Congested Systems . . . . . . . . . . . . 11 78 4.4. Handling Unknown Payload Protocols . . . . . . . . . . . . 11 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 81 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 85 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 1. Terminology 90 For readability, this document uses the following loosely defined 91 terms: 93 o Slow path : Software processing path for packets 95 o Fast path : ASIC/Hardware processing path for packets 97 1.1. Conventions Used in This Document 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 2. Introduction 105 [RFC2113] and [RFC2711] respectively define the IPv4 and IPv6 Router 106 Alert Option. In this document, we collectively refer to those as 107 the IP Router Alert. RSVP ([RFC2205], [RFC3175], [RFC3209]), PGM 108 ([RFC3208]), IGMP ([RFC2236] [RFC3376]), MLD ([RFC2710], [RFC3810]) 109 and MRD ([RFC4286]) are some of the protocols which make use of the 110 IP Router Alert. Those protocols are used to support critical 111 elements of the Internet infrastructure (e.g. RSVP-TE for traffic 112 engineering within a service provider network) and as such they need 113 to be protected. 115 IP datagrams carrying the IP Router Alert are usually examined in a 116 router's slow path and an excess of such datagrams can cause 117 performance degradation or packet drops in a router's slow path. 118 (Note that a router's slow path can potentially also be attacked with 119 IP packets destined to one of the router's local IP addresses and 120 requires corresponding security protection.) 122 [RFC4081] and [RFC2711] mention the security risks associated with 123 the use of the IP Router Alert: flooding a router with bogus IP 124 datagrams which contain the IP Router Alert would cause a performance 125 degradation of the router's slow path and can also lead to packet 126 drops in the slow path. 128 [RFC2113] specifies no mechanism for identifying different users of 129 IP Router Alert. As a result, many fast switching implementations of 130 IP Router Alert punt most/all packets marked with IP Router Alert 131 into the slow path. Some IP Router Alert implementations may be able 132 to take into account the IP PID [RFC0791] as a discriminator for the 133 punting decision for different protocols using IP Router Alert. 134 However, this still only allows very coarse triage among various 135 protocols using IP Router Alert for two reasons. First, the IP PID 136 is the same when IP Router Alert is used for different applications 137 of the same protocol (e.g., RSVP vs. RSVP-TE), or when IP Router 138 Alert is used for different contexts of the same application (e.g., 139 different levels of RSVP aggregation [RFC3175]). Thus, it is not 140 possible to achieve the necessary triage in the fast path across IP 141 Router Alert packets from different applications or from different 142 contexts of an application. Secondly, some protocols requiring 143 punting may be carried over a transport protocol (e.g., TCP or UDP) 144 possibly because they require the services of that transport protocol 145 or perhaps because the protocol does not justify allocation of a 146 scarce IP PID value. Thus, considering the PID does not allow triage 147 in the fast path of IP Router Alert packets from different protocols 148 sharing the same transport protocol. Therefore, It is generally not 149 possible to ensure that only the IP Router Alert packets of interest 150 are punted to the slow path while other IP Router Alert packets are 151 efficiently forwarded (i.e., in fast path). This means that an 152 operator will often have to choose between a mode where the routers 153 ignore IP Router Alert and forwards all packets in fast path and a 154 mode where the routers honor IP Router Alert but then punt to slow 155 path all/most of the IP Router Alert packets including those that are 156 not of interest to the router. 158 [RFC2711] mentions that limiting, by rate or some other means, the 159 use of IP Router Alert option is a way of protecting against a 160 potential attack. However, if rate limiting is used as a protection 161 mechanism but if the granularity of the rate limiting is not fine 162 enough to distinguish among IP Router Alert packet of interest from 163 unwanted IP Router Alert packet, a IP Router Alert attack could still 164 severely degrade operation of protocols of interest that depend on 165 the use of IP Router Alert. Section 4 discusses examples of 166 protection mechanisms that may be available from a router 167 implementation of the IP Router Alert. 169 In some environments where it is not possible to accurately and 170 reliably distinguish between IP Router Alert packets of interest and 171 unwanted IP Router Alert packets, operators have resorted to actively 172 protecting themselves against externally generated IP Router Alert 173 packets in ways that result in end to end IP Router Alert packets 174 being (occasionally or systematically) dropped and/or ignored on a 175 segment. The consequences of such practises on the use of IP Router 176 Alert by existing or new applications are discussed in Section 3 of 177 the present document. Section 3 also discusses environments where IP 178 Router Alert can be used effectively. 180 The present document discusses considerations and practises based on 181 the current specification of IP Router Alert ([RFC2113], [RFC2711]). 182 Possible future enhancements to the specification of IP Router Alert 183 (in view of reducing the security risks associated with the use of IP 184 Router Alert) are outside the scope of this document. A proposal for 185 such enhancements can be found in [I-D.narayanan-rtg-router-alert- 186 extension] . 188 3. Guidelines for use of Router Alert 190 3.1. Reliance on Router Alert by Applications 192 First, as mentioned earlier, some networks actively protect 193 themselves against externally generated IP Router Alert packets. 194 This may be by tunneling IP Router Alert packets 195 [I-D.dasmith-mpls-ip-options] so that the IP Router Alert option is 196 hidden through that network or it may be via mechanisms resulting in 197 occasional (e.g., rate limiting) or systematic drop of IP Router 198 Alert packets. 200 Secondly, application protocols are often not carried directly on top 201 of IP but rather are carried by a transport protocol such as UDP, 202 TCP, or SCTP that in turns runs over IP. In these cases, the 203 application protocol is not visible in the IP header (that only 204 contains information about the transport protocol) and could not be 205 determined without further "deep packet" inspection. In the event of 206 the IP Router Alert option being used for an application protocol 207 carried in a transport protocol, the intercepted IP packet would be 208 delivered to the transport protocol for processing in accordance with 209 [RFC2113] (as opposed to being delivered directly to the application 210 protocol). However, the behavior of the transport protocol in these 211 circumstances is not defined, and may cause rejection of the packet 212 for various reasons. 214 As a consequence, in the general case of open networks, applications 215 can not safely rely on IP Router Alert packets being visible to all 216 nodes on the path today, and importantly can not even rely on IP 217 Router Alert packets being transported end to end. 219 [RFC2113] implies that the router may examine other fields of a 220 received packet that contains the IP Router Alert option to decide 221 whether that packet needs further processing, but no further advice 222 is given. Examination of other fields of the received IP packet that 223 carries the IP Router Alert to help determine what to do with the 224 packet would result in implementation-specific behavior that is 225 unpredictable to the sender of the packet. Therefore applications 226 cannot depend on IP Router Alert interception involving inspection of 227 fields in the packet outside the IP header. 229 Thus, creating a new application or end-to-end protocol that depends 230 on use of the current IP Router Alert ([RFC2113], [RFC2711]) is 231 considered harmful and it is RECOMMENDED that such new application or 232 protocol be developed without using IP Router Alert. A different 233 mechanism SHOULD be used in order to increase likelihood of operation 234 of that application/protocol end-to-end and to decrease the risk of 235 impacting existing protocols that use the IP Router Alert option. 237 3.2. When Consenting Adults Exchange IP Router Alert Packets 239 In some controlled environments, the network administrator can 240 determine that IP Router Alert packets will only be received from 241 trusted well-behaved devices or can establish that the protection 242 mechanisms discussed in the present document against the plausible 243 RAO-based DoS attacks (e.g., RAO filtering and rate-limiting) are 244 sufficient. In that case, an application relying on exchange and 245 handling of RAO packets (e.g., RSVP) may be safely deployed within 246 the controlled network. In other words, a network that feels 247 appropriately protected against the risks associated with his 248 environment, may decide to freely and openly partake in IP Router 249 Alert message exchange with consenting entities. A private 250 enterprise network firewalled from the Internet and using RSVP for 251 voice and video reservation/admission control may be an example of 252 such controlled environment. 254 In some environments, the network administrator can reliably ensure 255 that router alert packets from any untrusted device (e.g., from 256 external routers) are prevented from entering a trusted area (e.g., 257 the internal routers). For example, this may be achieved by ensuring 258 that routers straddling the trust boundary (e.g., edge routers) 259 always encapsulate those packets (without setting IP Router Alert -or 260 equivalent- in the encapsulating header) through the trusted area (as 261 discussed in [I-D.dasmith-mpls-ip-options]). In such environments, 262 the risks of DOS attacks through the IP Router Alert vector is 263 removed in the trusted area (or greatly reduced) even if IP Router 264 Alert is used inside the trusted area (say for RSVP-TE). Thus an 265 application relying on IP Router Alert may be safely deployed within 266 the trusted area. In other words, the network protects itself from 267 the risks of partaking in IP Router Alert exchange with strangers but 268 feels free to exchange IP Router Alert messages among trusted 269 parties. A Service Provider running RSVP-TE within his network may 270 be an example of such protected environment. 272 When a controlled environment requires RAO packet exchange across his 273 routers for some application (e.g., RSVP) and transits via a Service 274 Provider network (that is not part of the controlled environment), 275 the administrator of the controlled environment needs to ensure with 276 the Service Provider that the IP Router Alert messages will not be 277 dropped when transiting the Service Provider network. In other 278 words, the network ought to ensure that another network that needs to 279 be involved in the exchange of IP Router Alert packets is consenting. 281 [Editor's Note: the authors of this document are seeking feedback on 282 the recommendations suggested below] 284 Since some existing applications would benefit from end-to-end 285 transport of IP Router Alert packets, it is RECOMMENDED that a 286 Service Provider protects his network from attacks based on IP Router 287 Alert using mechanisms that avoid (or at least minimize) dropping of 288 end to end IP Router Alert packets (other than those involved in the 289 attack). For example, if the Service Provider does not run any 290 protocol depending on IP Router Alert within his network, he may 291 elect to simply turn-off punting of IP Router Alert packet on his 292 routers; this will ensure that end-to-end IP Router Alert packet 293 transit transparently and safely through his network. As another 294 example, using protection mechanisms such as those described in 295 Section 4 a Service Provider can protect the operation of a protocol 296 depending on IP Router Alert within his network (e.g., RSVP-TE) while 297 at the same time transporting IP Router Alert packets carrying 298 another protocol that may be used end to end. As yet another 299 example, using mechanisms such as those discussed in 300 [I-D.dasmith-mpls-ip-options] a Service Provider can safely protect 301 the operation of a protocol depending on IP Router Alert within his 302 network (e.g., RSVP-TE) while at the same time safely transporting IP 303 Router Alert packets carrying another protocol that may be used end 304 to end (e.g., IPv4/IPv6 RSVP). 306 As a last resort, if the Service Provider does not have any means to 307 safely transport end to end IP Router Alert packets over his network, 308 it is RECOMMENDED that, rather than dropping those packets, the 309 Service Provider forwards these packets through his network after 310 removing the IP Router Alert option from the IP header on ingress/ 311 receipt of the packet. This ensures that the packet will, at least, 312 make it through the Service Provider network allowing the packet to 313 be potentially intercepted on the other side via other means than the 314 IP Router Alert. 316 Where the Service Provider does not ensure reliable transport of IP 317 Router Alert packets (i.e., those are systematically or likely 318 dropped) for an end to end protocol of interest to a user, the user 319 can consider removing the IP Router Alert option from the IP header 320 before sending the packet to the Service Provider and may then 321 intercept the packet on the other side using some other interception 322 technique (and then possibly restore the IP Router alert option). 324 4. Example Protection Mechanisms in a Router Alert Implementation 326 Implementations of IP Router Alert on routers generally include 327 mechanisms for protection against the associated security risk. This 328 section provides examples of behaviors that may be supported by 329 router implementations to help protect the router. 331 [Editor's Note: the authors of this document are seeking feedback 332 about whether such mechanisms (or a subset/superset of those) ought 333 to be elevated to BCP requirements, recommendations and options 334 instead of simply described as examples.] 336 4.1. Handling Packets Carrying the Router Alert Option 338 o a router implementation may elect to perform packet inspection to 339 see whether they carry the IP Router Alert option in the "fast 340 path". This avoids punting all packets to the slow path when the 341 router is interested in some IP Router Alert packets. 343 o a router implementation may elect to not send to the "slow path" 344 IP packets carrying the IP Router Alert option unless IP Router 345 Alert interception is explicitly enabled on the router (or 346 interface). This avoids punting any IP Router Alert packet when 347 the router is not interested in any of those. 349 o a router implementation may elect to not send to the "slow path" 350 IP packets carrying the IP Router Alert option unless there is at 351 least one protocol explicitly enabled on the router (or interface) 352 which is defined to use the IP Router Alert option. This avoids 353 punting any IP Router Alert packet when the router is not 354 interested in any of those. 356 o a router implementation may elect to allow configuration of which 357 protocol is "of interest" for the IP Router Alert option 358 interception (on router or interface level). The router 359 implementation may then elect to not send packets carrying the 360 Router Alert option to the "slow path" unless the payload protocol 361 carried in the packet (as identified by the Protocol ID) is 362 configured as "protocol of interest". This avoids punting IP 363 Router Alert packet carrying a protocol in which the router is not 364 interested. 366 4.2. Applying Rate Limiting 368 o a router implementation may elect to support (in the fast path) 369 rate limiting of the number of IP Router Alert IP datagrams (e.g., 370 at router or interface level) which go to the "slow path". The 371 benefits of rate limiting is described in [RFC2711]. 373 o a router implementation may elect to support (in the fast path) 374 separate rate limiting per payload protocol. This allows one 375 protocol relying on IP Router Alert to be protected from DOS 376 attacks using IP Router Alert with a different protocol. 378 4.3. Router Alert in Congested Systems 380 o a router implementation may elect to support selective dropping of 381 packets carrying the IP Router Alert option (rather than pass them 382 to the "slow path") in preference to dropping other control plane 383 packets, in the face of control plane congestion. This protects 384 other control plane protocols from IP Router Alert attacks. 386 4.4. Handling Unknown Payload Protocols 388 If an IP packet contains the IP Router Alert option, but the payload 389 protocol is not explicitly identified as a Payload of interest by the 390 router examining the packet, the behavior is not defined by 391 [RFC2113]. However, the definition of RSVP in [RFC2205] assumes that 392 the packet will be forwarded using normal forwarding based on the 393 destination IP address. 395 o a router implementation may elect to forward within the "fast 396 path" (subject to all normal policies and forwarding rules) a 397 packet carrying the IP Router Alert option containing a payload 398 that is not a payload of interest to that router. The "not 399 passing" behavior protects the router from DOS attacks using IP 400 Router Alert packets of a protocol unknown to the router. The 401 "forwarding" behavior contributes to transparent end to end 402 transport of IP Router Alert packets (e.g., to facilitate their 403 use by end to end application). 405 5. Security Considerations 407 This document discusses security risks associated with current usage 408 of the IP Router Alert Option and associated practices. 410 6. IANA Considerations 412 None. 414 7. Contributors 416 The contributors to this document (in addition to the editors) are: 418 o Reshad Rahman: 420 * Cisco Systems 422 * rrahman@cisco.com 424 o David Ward: 426 * Cisco Systems 428 * wardd@cisco.com 430 o Ashok Narayanan: 432 * Cisco Systems 434 * ashokn@cisco.com 436 o Adrian Farrell: 438 * OldDog Consulting 440 * adrian@olddog.co.uk 442 o Tony Li: 444 * tony.li@tony.li 446 8. Acknowledgments 448 We would like to thank Dave Oran, Magnus Westerlund, John Scudder, 449 Ron Bonica, Ross Callon and Alfred Hines for their comments. 451 9. References 453 9.1. Normative References 455 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 456 September 1981. 458 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 459 February 1997. 461 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 462 RFC 2711, October 1999. 464 9.2. Informative References 466 [I-D.dasmith-mpls-ip-options] 467 Jaeger, W., Mullooly, J., Scholl, T., and D. Smith, 468 "Requirements for Label Edge Router Forwarding of IPv4 469 Option Packets", draft-dasmith-mpls-ip-options-01 (work in 470 progress), October 2008. 472 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 473 Requirement Levels", BCP 14, RFC 2119, March 1997. 475 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 476 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 477 Functional Specification", RFC 2205, September 1997. 479 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 480 2", RFC 2236, November 1997. 482 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 483 Listener Discovery (MLD) for IPv6", RFC 2710, 484 October 1999. 486 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 487 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 488 RFC 3175, September 2001. 490 [RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, D., 491 Lin, S., Leshchiner, D., Luby, M., Montgomery, T., Rizzo, 492 L., Tweedly, A., Bhaskar, N., Edmonstone, R., 493 Sumanasekera, R., and L. Vicisano, "PGM Reliable Transport 494 Protocol Specification", RFC 3208, December 2001. 496 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 497 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 498 Tunnels", RFC 3209, December 2001. 500 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 501 Thyagarajan, "Internet Group Management Protocol, Version 502 3", RFC 3376, October 2002. 504 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 505 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 507 [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for 508 Next Steps in Signaling (NSIS)", RFC 4081, June 2005. 510 [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", 511 RFC 4286, December 2005. 513 [RFC5350] Manner, J. and A. McDonald, "IANA Considerations for the 514 IPv4 and IPv6 Router Alert Options", RFC 5350, 515 September 2008. 517 Author's Address 519 Francois Le Faucheur (editor) 520 Cisco Systems 521 Greenside, 400 Avenue de Roumanille 522 Sophia Antipolis 06410 523 France 525 Phone: +33 4 97 23 26 19 526 Email: flefauch@cisco.com