idnits 2.17.1 draft-sathyanarayan-ipsecme-advpn-03.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 : ---------------------------------------------------------------------------- ** There are 711 instances of too long lines in the document, the longest one being 5 characters in excess of 72. == There are 12 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 16 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2013) is 3840 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) == Missing Reference: 'RFC3948' is mentioned on line 576, but not defined == Missing Reference: 'RFC5996' is mentioned on line 702, but not defined ** Obsolete undefined reference: RFC 5996 (Obsoleted by RFC 7296) == Unused Reference: 'RFC1034' is defined on line 1190, but no explicit reference was found in the text == Unused Reference: 'RFC5890' is defined on line 1193, but no explicit reference was found in the text == Unused Reference: 'RFC3492' is defined on line 1209, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5996 (ref. 'IKEV2') (Obsoleted by RFC 7296) == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-23 -- No information found for draft-burner-ikev2-mediation - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPSECME Working Group P. Sathyanarayan(Ed.) 2 Internet Draft S. Hanna 3 Intended status: Proposed Standard S. Melam 4 Expires: December 2013 Juniper Networks 5 Y. Nir 6 Check Point 7 D. Migault 8 Francetelecom - Orange 9 K. Pentikousis 10 EICT 11 October 21, 2013 13 Auto Discovery VPN Protocol 14 draft-sathyanarayan-ipsecme-advpn-03 16 Abstract 18 This document defines a protocol for dynamically establishing and tearing 19 down IPsec tunnels as needed without requiring non-scalable configuration. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the provisions 24 of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering Task 27 Force (IETF), its areas, and its working groups. Note that other groups 28 may also distribute working documents as Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months and 31 may be updated, replaced, or obsoleted by other documents at any time. It 32 is inappropriate to use Internet-Drafts as reference material or to cite 33 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 April 21, 2014 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the document 46 authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal Provisions 49 Relating to IETF Documents (http://trustee.ietf.org/license-info) in 50 effect on the date of publication of this document. Please review these 51 documents carefully, as they describe your rights and restrictions with 52 respect to this document. 54 Table of Contents 56 1. Introduction...................................................3 57 1.1. Conventions Used In This Document.........................4 58 1.2. Terminology...............................................4 59 2. Design Considerations..........................................5 60 3. Auto Discovery VPN Protocol....................................6 61 3.1. Prerequisites.............................................7 62 3.2. Shortcut Initiation.......................................7 63 3.3. Shortcut Termination.....................................10 64 3.4. Peer Address Identification Payload......................10 65 3.5. ADVPN_SUPPORTED Notification.............................11 66 3.6. ADVPN_INFO Payload.......................................12 67 3.7. ADVPN_STATUS Notification................................15 68 3.8. The SHORTCUT Exchange....................................17 69 3.8.1. Content of the IDi and IDr payloads.................18 70 3.9. PROTECTED_DOMAIN Attribute Type..........................19 71 3.10. SHORTCUT Response Codes (RCODE).........................20 72 3.10.1. SHORTCUT_ACK.......................................20 73 3.10.2. SHORTCUT_OK........................................20 74 3.10.3. SHORTCUT_PARTNER_UNREACHABLE.......................21 75 3.10.4. TEMPORARILY_DISABLING_SHORTCUT.....................21 76 3.10.5. IKEV2_NEGOTIATION_FAILED...........................22 77 3.10.6. UNMATCHED_SHORTCUT_SPD.............................22 78 3.10.7. UNMATCHED_SHORTCUT_PAD.............................22 79 4. Trusted Suggester.............................................23 80 4.1. Format of Protected Domain Resource......................24 81 4.2. Lifetime of The Data In Protected Domain Resource........24 82 5. IPsec Policy..................................................24 83 5.1. Security Policy Database (SPD)...........................25 84 5.1.1. Security Policy Database Cache (SPD Cache)..........25 85 5.2. Peer Authentication Database (PAD).......................26 86 6. Security Considerations.......................................27 87 7. IANA Considerations...........................................27 88 8. References....................................................28 89 8.1. Normative References.....................................28 90 8.2. Informative References...................................29 91 9. Acknowledgments...............................................29 92 Appendix A. ADVPN Example Use Cases..............................30 93 A.1. Branch Office Videoconference............................30 94 A.2. Optimization for Videoconference with Partner............32 95 A.3. Heterogeneous Wireless Networks Traffic..................35 96 Appendix B. Comparison Against ADVPN Requirements................41 97 Appendix C. PROTECTED_DOMAIN Example.............................48 99 1. Introduction 101 IPsec [IPSECARCH] is currently being deployed in more diverse network 102 environments which exhibit significantly larger numbers of hosts than we 103 have seen before. For example, IPsec is currently used in a broad set of 104 scenarios ranging from remote office VPN deployments to mobile device 105 access to corporate and other sensitive network resources to securing 106 critical telecommunications infrastructure in cellular networks. Large 107 deployments of IPsec may involve thousands of gateways and endpoints with 108 constantly changing traffic patterns. In order to enable efficient and 109 secure traffic flow in such environments, we need to be able to establish 110 tunnels dynamically, as needed. As a result, static IPsec configuration 111 based on presets is no longer deemed adequate. Users expect to be able to 112 connect remotely and securely without compromising their communications 113 quality of experience. In other words, a more dynamic method of 114 establishing and tearing down Security Associations (SAs) [IPSECARCH] than 115 what is currently possible with current standards is desired. This is 116 discussed in [ADVPNreq] where it is shown that, for a variety of use 117 cases, static configuration does not scale for large systems and that a 118 standardized solution is needed where equipment from different vendors may 119 be involved. 121 Motivated by the problem defined in [ADVPNreq], this document proposes a 122 protocol that can demonstratively scale in large IPsec deployments while 123 ensuring that routing stretch is minimized and network resources are used 124 more optimally. The proposed protocol extends [IKEV2] to meet the 125 requirements spelled out in [ADVPNreq], providing a standard way to 126 dynamically establish and tear down IPsec tunnels, as needed, without 127 requiring non-scalable configuration. The protocol introduces the concept 128 of a "shortcut" which can be used by compliant IPsec gateways to optimize 129 the traffic path between two peers. The protocol has provisions for 130 adhering to established policies and is applicable to single- and multi- 131 domain environments. Shortcuts can be established and torn down 132 dynamically and, as we show in Appendix A, the proposed solution is 133 applicable to a variety of use cases and scenarios, pertaining to both 134 wired and wireless networks. 136 The remainder of this document is organized as follows. Section 2 presents 137 our design considerations and discusses the salient protocol 138 characteristics we are after. Section 3 specifies the Auto Discovery VPN 139 Protocol (ADVPN), while Section 4 examines the implications of ADVPN on 140 IPsec policy. Security considerations are discussed in Section 5. 142 Further, this document includes three appendices: Appendix A details 143 several ADVPN use cases, while Appendix B explains how the proposed 144 protocol meets the requirements set in [ADVPNreq]. Finally, Appendix C 145 provides an illustrative example of how the PROTECTED_DOMAIN response can 146 be created. 148 1.1. Conventions Used In This Document 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC 2119 [MUSTSHOULD]. 154 1.2. Terminology 156 This section defines the terms used throughout this document. The terms 157 introduced in [ADVPNreq] apply here as well. For reader convenience, we 158 repeat in particular the following terms: 160 Endpoint - A device that implements IPsec for its own traffic but does not 161 act as a gateway. 163 Gateway - A network device that implements IPsec to protect traffic 164 flowing through the device. 166 In addition, this document defines the following terms: 168 Peer - A host (gateway or endpoint) with an IPsec Security Association. 170 Shortcut - An IPsec Security Association established dynamically (at the 171 suggestion of a shortcut suggester). 173 SHORTCUT exchange - A new IKEv2 exchange that carries all data needed to 174 establish the shortcut IPsec Security Association. 176 Shortcut suggester - A peer that initiates a SHORTCUT exchange. 178 Shortcut partners - The pair of peers that received a SHORTCUT exchange 179 suggesting that they should establish a shortcut. 181 Shortcut initiator - A peer directed by a SHORTCUT exchange to act as the 182 IKEv2 initiator while establishing a shortcut. 184 Shortcut responder - A peer directed by a SHORTCUT exchange to act as the 185 IKEv2 responder while establishing a shortcut. 187 2. Design Considerations 189 The protocol described in this document aims at operational environments 190 with possibly tens of thousands (or more) peers. Peers may belong to the 191 same administrative domain, or to different administrative domains which 192 have already established trust relationships. In this kind of network 193 environment one wants to minimize configuration effort overall and, to the 194 degree possible, eliminate manual labor in administering route 195 optimization. This may not only result in better network resource 196 utilization, but also in increased network resilience as reliance on a few 197 centrally-located gateways is reduced. In addition, the automation 198 introduced by the protocol described herein enables administrators to 199 optimize IPsec traffic flows at time scales that are simply not possible 200 with today's tools. In general, the protocol should allow for self- 201 optimization as permitted by established domain policies. 203 Since IPsec traffic may originate or terminate behind NATs and other 204 policy-enforcing gateways, we aim for a protocol that can work well in 205 this environment. In addition, peers are not expected to be stationary. 206 Given the widespread deployment of wireless networks and the proliferation 207 of mobile devices with multiple interfaces it is reasonable to anticipate 208 that some hosts can join the ADVPN from a range of different access points 209 and this is taken into account in our protocol design. 211 A central aim of the protocol is to enable peers to setup IPsec tunnels 212 without the need for continuous manual configuration. In addition, the 213 establishment of new tunnels should not inadvertently affect other peers, 214 i.e. it should not call for manual configuration elsewhere in the VPN. 215 Moreover, the establishment of new IPsec tunnels should be easily 216 controlled and managed by the administrator. When new tunnels are 217 operational as well as when they are terminated the administrator should 218 be fully aware of it. 220 With these considerations in mind, we design a system that can function 221 purely on the basis of local optimizations and policies. In short, the 222 ADVPN protocol enables each individual gateway to act as a shortcut 223 suggester (as per administrator configuration), i.e. to recommend a 224 "shortcut" to appropriate peers with which it has previously established 225 IPsec security associations. These peers, which we refer to as the 226 shortcut partners, can accept, reject or ignore this recommendation, 227 according to their own policies. If the partner(s) reject the 228 recommendation, the partner response indicates the reasons for the 229 rejection, so the shortcut suggester can properly optimize its VPN 230 topology. In addition, responses may also carry informational data that 231 may be handled by the shortcut suggester in various ways. This foundation 232 bestows scaling properties to the Auto Discovery VPN protocol, as 233 described in the following sections. 235 It is important to highlight that the protocol introduced in this document 236 does not require peers to have a comprehensive understanding of the global 237 network topology. Each peer can act in accordance with its own policy. 238 Taken as a whole, this system optimizes the graph of IPsec Security 239 Associations to match the current traffic flow (subject to policy 240 constraints) and then continuously reoptimizes the IPsec tunnel graph as 241 traffic flows and policies change over time. Appendix A provides 242 illustrative examples of such a (re)optimization. 244 3. Auto Discovery VPN Protocol 246 The Auto Discovery VPN protocol (ADVPN) enables an IPsec gateway to 247 suggest the establishment of a shortcut, i.e. a direct IPsec tunnel 248 between two of its peers. For example, the shortcut could be used to 249 establish a more optimal path for data delivery. 251 Whenever an IPsec gateway decides that a shortcut between two of its peers 252 would be beneficial, it initiates a SHORTCUT exchange with both peers, 253 including all information needed to establish the shortcut in the 254 exchange. The peers can reject the SHORTCUT exchange but they can also use 255 the information contained in the exchange to attempt to establish a direct 256 SA between them. We refer to these peers as the shortcut partners. We 257 refer to the gateway offering the shortcut suggestion to both partners as 258 the shortcut suggester. 260 A shortcut MAY be torn down when it is no longer receiving adequate 261 traffic (as determined by the shortcut partners) or when the timeout for 262 the shortcut expires. Of course, the shortcut partners MAY decide to 263 explicitly terminate the shortcut at any time. 265 Note that this protocol works in an exemplary manner in typical hub-and- 266 spoke topologies but it is also well-suited for arbitrary topologies. For 267 example, consider the case of two endpoints exchanging an adequate amount 268 of traffic (as determined by the shortcut suggester) and connected through 269 a series of gateways, all of which support the Auto Discovery VPN 270 protocol. As detailed in Appendix A (Sections A.2. and A.3. , the protocol 271 enables the step-by-step optimization of the traffic flow between two 272 endpoints through the use of shortcut tunnels. The protocol effectively 273 enables direct and secure communication between the two endpoints without 274 any manual configuration involved in setting up the respective tunnels. 276 3.1. Prerequisites 278 The Auto Discovery VPN protocol MUST only be used with IKEv2. 280 Before the Auto Discovery VPN protocol can be used, all participants (i.e. 281 the shortcut suggester and the shortcut partners) must indicate support 282 for this protocol by sending ADVPN_SUPPORTED notification payload as 283 described in Section 3.5. Any IKEv2 peer that sends this notification is 284 indicating that it supports the protocol defined in this draft. 286 Shortcut partners and shortcut suggesters MUST NOT send any of the 287 messages defined in the remainder of this specification unless the 288 intended recipient of the message has sent the ADVPN_SUPPORTED 289 notification payload during the IKEv2 exchange. Any party that supports 290 this protocol will send this notification payload in the first IKE_AUTH 291 request sent in the IKE exchange. However, it may delay sending this 292 payload until later, for example, if it has a policy that restricts the 293 set of peers with which it is willing to establish a shortcut. 295 3.2. Shortcut Initiation 297 Once the use of the Auto Discovery VPN protocol is enabled, an IPsec 298 gateway which acts as a shortcut suggester can decide that two of its 299 peers (which have indicated support for the ADVPN protocol) should 300 establish a direct IPsec Security Association. Note that the decision- 301 making process for selecting the two peers is outside the scope of this 302 document. As an illustrative example, however, one could consider the 303 observation of excessive transit traffic load between said peers. Another 304 reason could be the realization that certain quality of service (QoS) 305 requirements would be better served through a shortcut. For instance, some 306 of the traffic between the two peers may be delay-sensitive and would 307 benefit from a more direct route. Alternatively, gateway-, policy- and 308 operation-related reasons, such as overload, scheduled maintenance, 309 energy-saving and so on, could also trigger the initiation of a shortcut 310 recommendation. The reasoning behind the trigger that initiates a shortcut 311 exchange to selected peers is beyond the scope of this document. 313 Once an IPsec gateway has decided that two peers should establish a direct 314 SA, it acts as a shortcut suggester and uses its already established IKEv2 315 SAs with these peers to initiate a SHORTCUT exchange to each of the 316 shortcut partners. Each SHORTCUT exchange includes most or all of the 317 information needed to allow the shortcut partners to establish their own 318 SA, such as, the IP address, port number and identity of the other 319 partner, an indication of which partner should be the IKEv2 initiator and 320 which should be the responder, and even an optional Pre-Shared Key, which 321 can facilitate partner authentication with each other. 323 The shortcut suggester MAY also include Traffic Selectors in the SHORTCUT 324 exchange to indicate which traffic should be sent over the shortcut. This 325 allows traffic for certain destinations to use the ADVPN shortcut while 326 traffic for other destinations continues to flow through the gateway (i.e. 327 the shortcut suggester). Further, it allows traffic destined for certain 328 port numbers (e.g. associated to high-volume, delay-sensitive traffic such 329 as video conferencing applications) to follow the path defined by the 330 shortcut, while other types of traffic carrying, for example, sensitive 331 information that ought to be logged or analyzed, continue to be routed 332 through the gateway. 334 The shortcut partners MAY decline to act on the SHORTCUT exchange. 335 Although the decision to do so is outside the scope of this document, one 336 could consider, for example, that there may be implementation-specific or 337 operational reasons for rejecting the newly received shortcut suggestion. 338 For instance, the shortcut partners may be low on resources or they may 339 have recently tried to establish this shortcut and failed. Another reason 340 for not accepting the shortcut recommendation could be that doing so would 341 violate local policy. For instance, one of the shortcut partners may 342 accept shortcuts only within its organization. 344 The shortcut partner(s) MAY ignore the SHORTCUT exchange, but it MUST 345 provide a reason for such refusal to the shortcut suggester by including 346 the ADVPN_STATUS notification in the SHROTCUT exchange. We note that a 347 shortcut suggester SHOULD NOT reinitiate a SHORTCUT exchange just because 348 the shortcut partners have not set up the requested shortcut tunnel. An 349 ADVPN_STATUS notification MAY carry a timeout value as an indication by 350 either of the partners to the shortcut suggester so that the latter defers 351 the re-initiation of a SHORTCUT exchange for this partner pair for the 352 specified amount of time. 354 The shortcut suggester can indicate, during the SHORTCUT initiation 355 exchange, which shortcut partner should act as the initiator and which as 356 the responder. For example, if only one of the two peers is behind a NAT, 357 the shortcut suggester can indicate the peer behind the NAT as the 358 initiator. Once this decision is made, the shortcut suggester initiates 359 the SHORTCUT exchange with the chosen shortcut responder first. Once the 360 responder's response is received and it indicates acceptance of the 361 suggestion, the shortcut suggester can proceed with the notification to 362 the partner that will act as the shortcut initiator. If, on the other 363 hand, the responder rejects the suggestion, the shortcut suggester MAY 364 change the roles of the partners or terminate the process. 366 If the shortcut partner identified as the initiator in the SHORTCUT 367 exchange decides to establish the shortcut suggested by the exchange, it 368 will attempt to establish an IKEv2 exchange with its designated shortcut 369 partner (the "shortcut responder") and then to establish an IPsec security 370 association between the two. Ordinarily, the Initiator in an IKE_AUTH 371 exchange MAY include an IDr payload. In an IKE_AUTH exchange established 372 because of a SHORTCUT, both the IDi and IDr payloads are mandatory, and 373 their content MUST agree with the ID payloads in the SHORTCUT exchange. 374 Once the SA between the two partners is established, both shortcut 375 partners SHOULD send to the shortcut suggester a SHORTCUT response, 376 indicating that the shortcut tunnel has been established. Details of how 377 this is done are specified in the descriptions of specific Shortcut Types 378 in Section 3.4. 380 If the shortcut partners are able to establish an IPsec security 381 association, they can use the Traffic Selectors for this SA to determine 382 which traffic should be sent through this tunnel. Shortcut partners MUST 383 ensure that the Traffic Selectors negotiated for the shortcut tunnel are a 384 subset of the Traffic Selectors they have in place for their SA with the 385 shortcut suggester. Since there may be an overlap between the Traffic 386 Selectors for the shortcut SA and for the SA with the shortcut suggester, 387 preference SHOULD be given in this case to sending traffic over the 388 shortcut SA, as described in Section 4. 390 If a VPN gateway is performing address translation (NAT) for traffic 391 coming from one peer and going to another peer, then in MUST NOT suggest a 392 shortcut between them. Such traffic would have different addresses when 393 flowing directly between the peers, and there is no guarantee that such 394 flows work with the IPsec policy and with the routing in the remote 395 network. 397 3.3. Shortcut Termination 399 After establishing an IPsec Security Association triggered by a SHORTCUT 400 exchange, as described in the following subsection, either of the shortcut 401 partners may decide to terminate the shortcut. This may occur at any point 402 of time and for a variety of reasons (outside the scope of this document), 403 such as, for example, due to lack of traffic using the shortcut, local 404 policy, shortage of resources, or other reasons. However, the shortcut SA 405 SHOULD NOT be terminated simply because the SA with the shortcut suggester 406 was terminated due to inactivity. On the contrary, dropping the SA with 407 the shortcut suggester while maintaining the shortcut SA may be quite a 408 normal occurrence if the only traffic flowing through the shortcut 409 suggester has now been diverted into the shortcut. 411 Note that either shortcut partner may terminate a shortcut by closing the 412 corresponding IKE SA (and therefore all child IPsec SAs) by sending an 413 IKEv2 Delete payload to the other shortcut partner, thus indicating that 414 the IKE SA should be deleted. 416 3.4. Peer Address Identification Payload 418 The Peer Address Identification Payload, denoted as IDa, contains the 419 address of the peer gateway. It is formatted in the same manner as the IDi 420 and IDr payloads which are defined in Section 3.5 of RFC 5996. The ID type 421 in the IDa payload MUST be from one of the following types: 423 . ID_IPV4_ADDR, indicating an IPv4 address 424 . ID_IPV6_ADDR, indicating an IPv6 address 425 . ID_FQDN, indicating a fully qualified domain name; this is allowed if 426 and only if the peer has indicated the capability "FQDN Resolver" in 427 its ADVPN_SUPPORTED notification. See Section 3.5. 429 This payload is currently defined only for the SHORTCUT exchange. It MUST 430 NOT be sent to any peer that has not indicated support for SHORTCUT 431 exchanges by sending the ADVPN_SUPPORTED notification. The Critical bit 432 MUST be set. 434 [RFC EDITOR PLEASE REMOVE THIS PARAGRAPH] For development and 435 interoperability testing while this document is still a draft and IANA 436 actions have not taken place, implementations can use the private-use 437 value of 247 for the payload type of the IDa payload. 439 3.5. ADVPN_SUPPORTED Notification 441 The Notify payload for announcing support of ADVPN is included in the 442 Initial Exchange and is formatted as follows: 444 1 2 3 445 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 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 ! Next Payload !C! RESERVED ! Payload Length ! 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 ! Protocol ID ! SPI Size ! ADVPN Supported Message Type ! 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 ! Capabilities ... ! 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 The fields corresponding to the first 4 octets are defined as described in 455 RFC 5996. The remaining fields are defined as follows: 457 . Protocol ID (1 octet) MUST be zero, as specified in Section 3.10 of 458 RFC 5996. 459 . SPI Size (1 octet) MUST be zero, in conformance with Section 3.10 of 460 RFC 5996. 461 . ADVPN Supported Message Type (2 octets) - MUST be xxxxx. [RFC EDITOR 462 NOTE: value assigned by IANA for ADVPN_SUPPORTED] 463 . The Capabilities field can be two or more octets long, indicating the 464 capabilities that this implementation supports. See the Table below 465 for the capabilities specified in this document. The first of these 466 capabilities MUST indicate the protocol version range (0x01-0x08), 467 and at least one MUST list the features range (0x09-0xff). All 468 version capabilities MUST precede all feature capabilities. 470 +------------+-----------+------------------------------------------+ 471 | Value | Name | Comment | 472 +------------+-----------+------------------------------------------+ 473 | 0x00 | pad | Used to pad the notification to any | 474 | | | desired length. MAY be sent multiple | 475 | | | times at the end of the list, and MUST | 476 | | | be ignored on receipt | 477 | | | | 478 | 0x01 | v1 | The version described in this document. | 479 | | | MUST be sent first by implementations | 480 | | | compliant with this document. | 481 | | | | 482 | 0x02..0x08 | RES1 | Reserved for future versions | 483 | | | | 484 | 0x09 | Suggester | Can act as shortcut suggester in a | 485 | | | SHORTCUT exchange | 486 | | | | 487 | 0x0A | Shortcut | Can act as shortcut partner in a SHORTCUT| 488 | | Partner | | 489 | | | | 490 | 0x0B | FQDN | Can resolve peer locators given as FQDN. | 491 | | Resolver | Relevant only for the shortcut partner. | 492 | | | | 493 | 0x0C | Trusted | This peer can act as a trusted suggester | 494 | | Suggester | as described in Section 4. | 495 | | | | 496 | 0x0D..0x7F | RES2 | Reserved for future extensions | 497 | | | | 498 | 0x80..0xDF | RES3 | Reserved | 499 | | | | 500 | 0xE0..0xFF | RES4 | Reserved for private use | 501 +------------+-----------+------------------------------------------+ 503 The IKE exchange Initiator MAY send multiple version capabilities. The 504 Responder MUST send exactly one version capability, and that capability 505 represents the version of the specification to be used. 507 A receiver MUST ignore any capabilities it does not recognize. Extension 508 documents SHOULD consider the effects of the peer not recognizing such 509 capabilities. If such extensions are critical for the operation of the 510 protocol, a new version number may also be needed. 512 [RFC EDITOR PLEASE REMOVE THIS PARAGRAPH] For development and 513 interoperability testing while this document is still a draft and IANA 514 actions have not taken place, implementations can use the private-use 515 value of 47831 as the ADVPN_SUPPORTED Notify type. 517 3.6. ADVPN_INFO Payload 519 The ADVPN_INFO payload is used in the SHORTCUT exchange to send 520 information from the suggester to a shortcut partner about the shortcut. 522 1 2 3 523 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 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 ! Next Payload !C! RESERVED ! Payload Length ! 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 ! SHORTCUT Identifier ! 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 ! Lifetime ! 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 ! R | Reserved | PSK Length | Peer Port ! 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | | 534 ~ Pre-Shared Key (variable length) ~ 535 | | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | | 538 ~ Peer Description (variable length) ~ 539 | | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 The fields corresponding to the first 4 octets are defined as described in 543 RFC 5996. The remaining fields are defined as follows: 545 . SHORTCUT Identifier (4 octets) - a 32-bit identifier for this 546 shortcut. The same value MUST be used for both shortcut peers and it 547 MUST be unique per suggester and partners pair. The value SHOULD be 548 unique per suggester, i.e. there should not exist in the VPN two 549 SHORTCUTs initiated by the same suggester with the same identifier. 550 . Lifetime (4 octets) - a 32-bit integer that indicates the maximum 551 number of seconds that this shortcut recommendation should last. 552 After this period of time lapses, the shortcut partners SHOULD tear 553 down the shortcut SA. If the field is 0, the shortcut suggestion MAY 554 last indefinitely. The shortcut partners MAY use a smaller timeout 555 value than given here based on their policies. 556 . R - Role (2 bits) - this field indicates to the partner its 557 designated role in the upcoming exchange (i.e. shortcut initiator or 558 responder). Role assignment is decided by the shortcut suggester and, 559 as mentioned earlier, it is outside the scope of this document. Value 560 00 is reserved and MUST NOT be used by implementations compliant to 561 this specification. Value 01 indicates that the receiving peer MUST 562 act as shortcut responder. Value 10 indicates that the peer receiving 563 this payload MUST act as the shortcut initiator. Value 11 indicates 564 that the receiving peer SHOULD NOT initiate the exchange immediately 565 and MAY initiate the exchange at later stage. The waiting time before 566 the peer initiates the exchange could be several minutes. 568 . PSK Length (1 octet) indicates the length in octets of the Pre-Shared 569 Key. It MUST be set to zero if certificate authentication is to be 570 used between the shortcut peers. 571 . Peer Port (16 bit) - is set to zero when none of the shortcut 572 partners are behind a NAT. The suggester has IKEv2 and IPsec channels 573 with both shortcut partners, so it is aware whether partners are 574 behind a NAT or not. If one of the shortcut partners is behind a NAT, 575 the Peer Port MUST be a non-zero value. This value is used for UDP 576 encapsulation as defined in [RFC3948] between the partner that has 577 received the shortcut payload and the peer shortcut partner. 579 If the peer shortcut partner is behind a NAT, the Peer Port 580 designates the port by which the NAT identifies the peer within its 581 private network. The global IP address of the NAT is provided by the 582 Peer Address Identification Payload (IDa). When the shortcut partner 583 receiving the shortcut payload sends an IKEv2 or IPsec ESP packet to 584 the peer shortcut partner, it MUST UDP encapsulate the packet with IP 585 source set to its local IP address, source port set to 4500, IP 586 destination set to the IP provided by the Peer Address Identification 587 Payload, and destination port set to Peer Port. When the packet 588 reaches the NAT gateway, the IP destination and destination port are 589 translated by the NAT to private IP address and 4500. Similarly, 590 IKEv2 and IPsec ESP packets sent by the peer shortcut partner are UDP 591 encapsulated with IP source set to the private IP address of the peer 592 shortcut partner, source port set to 4500. IDa determines the IP 593 destination payload sent to the peer shortcut partner and the 594 counterpart shortcut payload Peer Port field sent to the peer 595 shortcut partner defines the destination port. This field MAY be 4500 596 or another value depending on whether the shortcut partner of the 597 shortcut payload (described in this section) is also behind a NAT. 599 If the peer shortcut partner is not behind a NAT, but the partner 600 receiving this shortcut payload is behind a NAT, then the Peer Port 601 value is set to 4500. When the shortcut partner sends an IKEv2 or an 602 IPsec ESP packet, it MUST UDP encapsulate the packet with IP source 603 set to its private IP, the port source set to 4500, IP destination 604 set to the IP provided by the Peer Address Identification Payload 605 (IDa) and the destination port 4500. When the packet reaches the NAT 606 gateway, IP source and port are translated by the NAT with the global 607 IP address and the port used to identify the shortcut partner. These 608 two values are provided to the peer shortcut partner, by the Peer 609 Address Identification Payload (IDa) and shortcut payload sent by the 610 suggester to the peer shortcut partner. 612 If the Peer Port is set to zero and the partner is behind a NAT, this 613 is obviously a misconfiguration. The partner MAY return a RCODE set 614 to SHORTCUT_PARTNER_UNREACHABLE. If the partner initiates the IKEv2 615 negotiation, it MUST ignore the Peer Port value and proceed to UDP 616 encapsulation. The negotiation MAY be successful only if the peer 617 shortcut partner is not behind a NAT. Similarly if the partner is not 618 initiating the IKEv2 negotiation, the negotiation MAY be successful 619 if the shortcut partner has received a properly configured shortcut 620 payload. 622 . Pre-Shared Key - An octet string used as the PSK in the IKE_AUTH 623 exchange between the shortcut partners. This field MUST be the same 624 in the ADVPN INFO payloads sent to the two shortcut partners. It MUST 625 be randomly generated using a good random source, and it SHOULD be 626 long enough to meet the security requirements of the deployment. In 627 practice, this means that the length of the randomly generated data 628 should be at least 16 octets long. 629 . Peer Description (variable length) - The length of this field is 630 calculated by subtracting the combined lengths of the other fields 631 from the value of the Payload Length field. It contains a description 632 of the other peer, in a format that is simply a name, suitable for 633 logging, and encoded in UTF-8. 635 [RFC EDITOR PLEASE REMOVE THIS PARAGRAPH] For development and 636 interoperability testing while this document is still a draft and IANA 637 actions have not taken place, implementations can use the private-use 638 value of 248 as the ADVPN_INFO payload type. 640 3.7. ADVPN_STATUS Notification 642 The ADVPN_STATUS payload is used by a shortcut partner for conveying to 643 the suggester and to the other SHORTCUT peer the status of the shortcut. 645 1 2 3 646 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 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 ! Next Payload !C! RESERVED ! Payload Length ! 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 ! Protocol ID ! SPI Size ! ADVPN Status Message Type ! 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 ! SHORTCUT Identifier ! 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 !F|C|E| Reserved | RCODE | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 ! Timeout ! 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 The fields corresponding to the first 4 octets are defined as described in 661 RFC 5996. The remaining fields are defined as follows: 663 . Protocol ID (1 octet) MUST be zero, as specified in Section 3.10 of 664 RFC 5996. 665 . SPI Size (1 octet) MUST be zero, in conformance with Section 3.10 of 666 RFC 5996. 667 . ADVPN Status Message Type (2 octets) - MUST be yyyyyy. [RFC EDITOR 668 NOTE: value assigned by IANA for ADVPN_STATUS] 669 . SHORTCUT Identifier - the 32-bit field from the SHORTCUT_INFO 670 notification. 671 . F (1 bit) - Fatal. Set if this notification means that the SHORTCUT 672 no longer exists. 673 . C (1 bit) - Critical. Set if the peer must understand this RCODE, or 674 else delete the shortcut if the F bit is not set. 675 . E (1 bit) - Error. Indicates an error condition (rather than a policy 676 change). 677 . RCODE (2 octets) - a 16-bit field as described in Section 3.8.1. 678 . Timeout - this 32-bit field indicates the maximum number of seconds 679 that the shortcut service is not available by the peer. 681 The SHORTCUT_STATUS notification may be sent to the suggester in the 682 SHORTCUT exchange response message. If either the suggester or a partner 683 needs to communicate a change in status after the original SHORTCUT 684 exchange is over, the same can be communicated in an INFORMATIONAL 685 request. Additionally, the same notification is used in the IKE exchange 686 between the shortcut partners, so that they can match that exchange and 687 the resulting Security Associations to the shortcut. Since there may be 688 more than one active shortcut between a pair of shortcut partners, the 689 notification is inserted into the exchanges that create child SAs, either 690 the IKE_AUTH exchange or the CREATE_CHILD_SA exchange. 692 [RFC EDITOR PLEASE REMOVE THIS PARAGRAPH] For development and 693 interoperability testing while this document is still a draft and IANA 694 actions have not taken place, implementations can use the private-use 695 value of 47833 as the ADVPN_STATUS notify type. 697 3.8. The SHORTCUT Exchange 699 This new exchange type defines how the suggestions are conveyed. It is 700 designed for sending the SHORTCUT data. The suggester initiates the 701 SHORTCUT exchange and each of the shortcut partners responds to the 702 notification. The shortcut partner acts as the [RFC5996] Responder. The 703 exchange is constructed as follows: 705 HDR, SK {IDa, ADVPN_INFO, IDi, 706 IDr[, TSi][, TSr][, VID]} --> 707 <== HDR, SK {N(ADVPN_STATUS)} 709 The IDa payload, defined in Section 3.4. provides the location of the 710 other shortcut peer and it may not necessarily have the same data as the 711 IDi or IDr payloads. 713 The ADVPN_INFO payload contains PSK and any other information needed for 714 establishing the SHORTCUT IKE SA, as well as the optional time out 715 information. 717 The IDi Identification Payload contains the identity of the shortcut 718 initiator. The shortcut initiator MUST use this identifier when 719 establishing the shortcut and the shortcut responder MUST verify that this 720 identifier was used. 722 The IDr Identification Payload contains the identity of the shortcut 723 responder. The shortcut initiator MUST use this payload in the subsequent 724 IKE_AUTH exchange with the shortcut responder. 726 The TSi and TSr Traffic Selector Payloads (when present) contain, 727 respectively, traffic selectors the intended Initiator and intended 728 Responder in the IKE_AUTH exchange between the shortcut partners. The 729 content is as specified in Section 3.13 of RFC 5996 [IKEV2]. 731 The responder checks that everything in the request is acceptable 732 according to local policy. If not, it MUST return an error RCODE. If the 733 shortcut is acceptable, then it either tries to establish the shortcut IKE 734 SA, and reports the results in the SHORTCUT response, or it immediately 735 responds with a SHORTCUT_ACK RCODE, and follows up with more detailed 736 status reports in future Informational exchanges. 738 In the subsequent IKE_AUTH exchange between the two partners, the 739 initiator MUST use the IDi and IDr payloads as specified in the exchange 740 described in this section, and MUST use a subset (not necessarily a proper 741 subset) of the traffic selector payload data, if such data has been 742 included in the SHORTCUT exchange. 744 When shortcut are performed within a single administrative domain, IKE PAD 745 are likely to be configured to trust all partners associated to a given 746 domain. This will most probably be reflected by a common field in the 747 certificate, and the ID is determined by the certificate. On the other 748 end, PSK and a random ID MUST be added in the PAD of the partners. 749 Creation of a new entry in the PAD is done since the suggester is trusted. 750 If not the partner MUST return a SHORTCUT Response with UNMATCHED SHORTCUT 751 PAD. 753 3.8.1. Content of the IDi and IDr payloads 755 The identification payloads in the SHORTCUT request message are later used 756 in the IKE_AUTH exchange between the shortcut partners. They are required 757 to follow the rules in RFC 5996 for authentication of the IKE SA. However, 758 those rules are vague and left to specific profiles, specific 759 implementations and specific administrative decisions. 761 Since AD-VPN is intended to work with multiple implementations and 762 multiple administrative domains, we believe it is necessary to specify the 763 content of these payloads more strictly. 765 If a shortcut partner is supposed to authenticate using a certificate 766 (and, therefore, the PSK Length field in the ADVPN_INFO payload is set to 767 zero), then the ID payload matching this partner MUST match the 768 certificate that it has. In this case, the ID payload MUST be from one of 769 the following types: 771 . ID_IPV4_ADDR or ID_IPV6_ADDR. This ID type MAY be used only if the 772 certificate contains an alternate name extension of type iPAddress, 773 and MUST contain the same IP address as the extension. 774 . ID_FQDN. This ID type MAY be used only if the certificate contains an 775 alternate name extension of type dNSName, and MUST contain the same 776 FQDN as the extension. 777 . ID_RFC822_ADDR. This ID type MAY be used only if the certificate 778 contains an alternate name extension of type rfc822Name, and MUST 779 contain the same NAI as the extension. 780 . ID_DER_ASN1_DN. This ID type can always be used, and if used, MUST 781 contain an exact copy of the subject field of the certificate. 783 If the partners are using a PSK to authenticate, the ID payloads need not 784 reflect any real name of the partners, as that information is conveyed in 785 the ADVPN_INFO payload. The ID payloads do, however, need to be unique so 786 as to allow a quick lookup of the ID payload. To ensure this, the ID 787 payload MUST be of type ID_KEY_ID, and the content MUST be unique. To 788 ensure uniqueness across administrative domains, the content of the ID 789 payload in such cases MUST be randomly or pseudo-randomly generated and 790 MUST have 128 bits. 792 3.9. PROTECTED_DOMAIN Attribute Type 794 This is a new attribute for the CFG payload. In a request, its size MUST 795 be a constant zero. In a response, it MUST be at least 20 octets long, 796 having the following format: 798 1 2 3 799 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 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 |R| Attribute Type | Length | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 | | 804 | | 805 | Resource Hash | 806 | | 807 | | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | | 810 ~ Resource URL ~ 811 | | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 PROTECTED_DOMAIN Configuration Attribute Format 816 In the above diagram, Attribute Type is ZZZ, [RFC EDITOR NOTE: value 817 assigned by IANA for PROTECTED_DOMAIN], Resource Hash is the SHA-1 hash of 818 the resource, and Resource URL is an HTTP URL pointing at the resource. 820 The corresponding entry for this attribute as in the table in section 821 3.15.1 of RFC 5996 is as follows: 823 Attribute Type Value Multi-Valued Length 824 -------------------------------------------------------------- 825 PROTECTED_DOMAIN 1 NO 0, or 20+ octets 827 The format of the resource itself is described in Section 4.1. 829 3.10. SHORTCUT Response Codes (RCODE) 831 This section provides more information on the use of the response codes 832 (RCODE). RCODE is a 16-bit field, used by the shortcut partners to 833 indicate the status on the SHORTCUT notification received. 835 The RCODEs we consider in this document are the following: 837 Value Description 838 --------------------- 839 0 SHORTCUT_ACK 840 1 SHORTCUT_OK 841 2 SHORTCUT_PARTNER_UNREACHABLE 842 3 TEMPORARILY_DISABLING_SHORTCUT 843 4 SHORTCUT_PARTNER_UNREACHABLE 844 5 IKEv2_NEGOTIATION_FAILED 845 6 UNMATCHED_SHORTCUT_SPD 846 7 UNMATCHED_SHORTCUT_PAD 848 3.10.1. SHORTCUT_ACK 850 The RCODE value for SHORTCUT_ACK is: 0 (zero) 852 This RCODE indicates that the receiving partner has accepted the shortcut, 853 but has yet to establish the shortcut IKE SA. This RCODE MUST be used only 854 in the response for a SHORTCUT exchange. 856 3.10.2. SHORTCUT_OK 858 The RCODE value for SHORTCUT_OK is: 1 860 This RCODE indicates that the shortcut has been successfully established 861 between the shortcut partners. 863 3.10.3. SHORTCUT_PARTNER_UNREACHABLE 865 The RCODE value for SHORTCUT_PARTNER_UNREACHABLE is: 2 867 This RCODE indicates that the attempt to establish the recommended 868 shortcut has failed because the partner peer was unreachable. This may 869 happen, for example, if the partner peers are behind separate NATs, or a 870 firewall drops packets between the shortcut partners. It may also be that 871 the partner peer is only available through a specific interface. In 872 addition, the partner peer may have been temporarily disconnected or its 873 shortcut service has been temporarily disabled as explained in subsection 874 3.10.4. 876 It is the responsibility of the shortcut suggester to determine the reason 877 of the observed unreachability as well as what policy to apply. However, 878 the shortcut suggester SHOULD NOT initiate another SHORTCUT exchange to 879 the shortcut partners before the Timeout indicated in the shortcut Data. 880 If the Timeout value is not present, then it is up to the shortcut 881 suggester to decide when a new SHORTCUT exchange should be initiated. 883 3.10.4. TEMPORARILY_DISABLING_SHORTCUT 885 The RCODE for TEMPORARILY_DISABLING_SHORTCUT is: 3 887 This RCODE indicates that the shortcut recommendation is refused by the 888 shortcut peer because it has deactivated the shortcut service. In other 889 words, this RCODE indicates that any attempt to establish shortcuts will 890 be refused independently of the SHORTCUT exchange sent. For example, the 891 shortcut service could be disabled when the shortcut peer is overloaded. 893 If the shortcut initiator generates this response code, then it SHOULD NOT 894 initiate the shortcut negotiation. 896 When receiving an ADVPN_STATUS notification with this response code, the 897 shortcut suggester SHOULD NOT initiate any other SHORTCUT exchange before 898 the Timeout indicated in the shortcut Data. If the Timeout value is not 899 present, then it is up to the shortcut suggester to decide when a new 900 SHORTCUT exchange should be initiated. 902 3.10.5. IKEV2_NEGOTIATION_FAILED 904 The Shortcut Type for IKEV2_NEGOTIATION_FAILED is: 4 906 This RCODE indicates that the IKEv2 negotiation between the two partner 907 peers did not complete successfully. That is, the shortcut recommendation 908 was accepted and acted upon, but the IKEv2 negotiation failed. This RCODE 909 does not provide information on the reasons the shortcut establishment 910 failed, and thus other more specific RCODEs (see below) SHOULD be 911 preferred by implementations when this is possible. 913 3.10.6. UNMATCHED_SHORTCUT_SPD 915 The RCODE for UNMATCHED_SHORTCUT_SPD is: 5 917 This RCODE indicates an error resulting from the analysis of the SHORTCUT 918 exchange. Before establishing a shortcut, the shortcut initiator MUST 919 check that the shortcut partner's IP address matches its Security Policy 920 Database (SPD). If a mismatch occurs with the shortcut initiator's SPD, 921 the shortcut initiator MUST NOT initiate the shortcut. In this case, the 922 initiator MUST use the UNMATCHED_SHORTCUT_SPD RCODE in its ADVPN_STATUS 923 notification. 925 If the mismatch occurs with the shortcut responder, it MUST send to the 926 shortcut suggester the UNMATCHED_SHORTCUT_SPD RCODE in its ADVPN_STATUS 927 notification. Eventually the shortcut initiator will start an IKEv2 928 negotiation. The shortcut responder SHOULD terminate the IKEV2 negotiation 929 with a TS_UNACCEPTABLE. At this stage the shortcut cannot be established 930 and the shortcut initiator MUST respond to the shortcut suggester with the 931 IKEv2_NEGOTIATION_FAILED Shortcut Type in its ADVPN_STATUS Notify Payload. 933 When receiving ADVPN_STATUS with this RCODE, the shortcut suggester SHOULD 934 NOT reinitiate a SHORTCUT exchange with the shortcut partners with the 935 same Traffic Selectors in short order. 937 3.10.7. UNMATCHED_SHORTCUT_PAD 939 The Shortcut Type for UNMATCHED_SHORTCUT_PAD is: 6 941 This RCODE indicates an error resulting from the analysis of the SHORTCUT 942 exchange. Before establishing a shortcut, the shortcut initiator MUST 943 check that the shortcut partner's IP address and Identities IDi/IDr match 944 its Peer Authentication Database (PAD). If a mismatch occurs with the 945 shortcut initiator's PAD, the shortcut initiator MUST NOT initiate the 946 establishment of the recommended shortcut. The initiator then sends the 947 UNMATCHED_SHORTCUT_PAD RCODE in its ADVPN_STATUS notification 949 If the mismatch occurs with the shortcut responder, it MUST send to the 950 shortcut suggester the UNMATCHED_SHORTCUT_PAD RCODE in its ADVPN_STATUS 951 notification. Eventually the shortcut initiator will start an IKEv2 952 negotiation. The shortcut responder SHOULD terminate the IKEV2 negotiation 953 with a TS_UNACCEPTABLE. Thus, the shortcut cannot be established and the 954 shortcut initiator MUST return the shortcut suggester the 955 IKEv2_NEGOTIATION_FAILED Shortcut Type in its ADVPN_STATUS. 957 When receiving ADVPN_STATUS with this RCODE, the shortcut suggester SHOULD 958 NOT reinitiate a SHORTCUT exchange with the shortcut partners with the 959 same Traffic Selectors in short order. 961 4. Trusted Suggester 963 Advertising this capability means that the sender supports sending its 964 entire protected domain through the PROTECTED_DOMAIN attribute in the CFG 965 payload. 967 The intended way to use this is that a spoke node, whether a remote access 968 client or a gateway, is configured only with credentials for a single hub 969 gateway. On the first Initial exchange, the hub gateway advertises the 970 TRUSTED_SUGGESTER capability. In the IKE_AUTH exchange or in a later 971 Informational exchange, the spoke sends a CFG_REQUEST, asking for the 972 PROTECTED_DOMAIN. The reply (see Section 3.8.1. gives the spoke a URL for 973 a resource that contains the entire protected domain of the hub, which is 974 the entire protected domain of the VPN. The CFG_REPLY also contains a hash 975 of the resource, which has an important security benefit. Since there are 976 attacks against HTTP, and no obvious way to secure HTTPS in this context, 977 using a protected exchange to send a hash of the resource makes sure that 978 the retrieved resource is in fact the intended one. 980 The list of IP addresses and ranges returned in the resource is used to 981 populate the SPD, and provides an initial configuration with all VPN 982 traffic going through the hub gateway. Normal ADVPN protocol operation can 983 later optimize the traffic, but this mechanism ensures that bootstrapping 984 does not require extensive manual configuration. 986 The procedure described above begins with the bare minimum of 987 configuration. Some nodes will begin with some initial configuration, in 988 which case it is up to them to harmonize their static configuration with 989 the data from the trusted suggester. It is perfectly valid to use only a 990 subset of the protected domain in populating the SPD. Appendix C provides 991 an illustrative example of the use of the PROTECTED_DOMAIN attribute. 993 4.1. Format of Protected Domain Resource 995 The protected domain resource is formatted much like a CFG reply. It is a 996 series of Configuration Attributes (see section 3.15.1 in RFC 5996), but 997 the only attribute types allowed are INTERNAL_IP4_SUBNET (13) and 998 INTERNAL_IP6_SUBNET (15). The last Configuration Attribute has the R bit 999 set to mark it as the last one. 1001 For an example, the following resource indicates a protected domain 1002 comprised of all three test networks from [RFC5737] and [RFC3849]: 1004 0x0D 0x08 0xC0 0x00 0x02 0x00 0xff 0xff 0xff 0x00 1005 - 8-octet IP4_SUBNET: 192.0.2.0 (255.255.255.0) 1006 0x0D 0x08 0xC6 0x33 0x64 0x00 0xff 0xff 0xff 0x00 1007 - 8-octet IP4_SUBNET: 198.51.100.0 (255.255.255.0) 1008 0x0D 0x08 0xCB 0x00 0xD1 0x00 0xff 0xff 0xff 0x00 1009 - 8-octet IP4_SUBNET: 203.0.113.0 (255.255.255.0) 1010 0x8F 0x11 0x20 0x01 0x0D 0xB8 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 1011 0x00 0x00 0x00 0x00 0x20 1012 - Last 17-octet IP6_SUBNET: 2001:DB8::/32 1014 4.2. Lifetime of The Data In Protected Domain Resource 1016 As the Protected Domain Resource is delivered over HTTP/1.1 or above, the 1017 Cache-Control ([HTTPCache]) directives can be used to assign a lifetime. 1018 The IPsec node MUST expire the entries from the SPD as soon as the data 1019 would expire from the cache, or MUST fetch fresh data beforehand. 1021 5. IPsec Policy 1023 This section discusses the implications of the use of the ADVPN Protocol 1024 on IPsec policy. 1026 5.1. Security Policy Database (SPD) 1028 The SHORTCUT exchange described in Section 3.2. conveys policy in the 1029 sense of Section 4.4.1 of RFC 4301 ([IPSECARCH]). In the terms of that 1030 document, these are SPD elements. Assuming these elements are accepted, 1031 they update the existing security policy of the receiver. 1033 The entries specified in a SHORTCUT exchange are inserted into the SPD 1034 immediately before the entry that they are updating, so that these new 1035 entries take precedence over existing ones. 1037 RFC 4301 does not specify time limits for SPD entries. In that sense, this 1038 document updates RFC 4301. SPD entries now come in two flavors: static 1039 entries, which have no expiration time and are defined by an 1040 administrator, and dynamic entries which have an expiration time as 1041 specified in the SHORTCUT exchange. 1043 For example, suppose a static entry exists for the remote subnet 1044 192.0.2.0/23, and the local subnet is 192.0.1.0/24. Initially, the entry 1045 looks like this: 1047 Local=192.0.1.0/24,Remote=192.0.2.0/23,PROT,Peer=vpngw.example.com 1049 Assume now that a SHORTCUT exchange is received which describes gateway 1050 foo.example.com, and remote subnet 192.0.2.0/24. The database will look as 1051 follows: 1053 Local=192.0.1.0/24,Remote=192.0.2.0/24,PROT,Peer=foo.example.com 1055 Local=192.0.1.0/24,Remote=192.0.2.0/23,PROT,Peer=vpngw.example.com 1057 Because of the rules of processing as specified in Section 5.1 of RFC 1058 4301, the earlier entry takes precedence, and overrides the second entry 1059 for subnet 192.0.2.0/24. The second entry still applies to 192.0.3.0/24. 1061 5.1.1. Security Policy Database Cache (SPD Cache) 1063 The SPD Cache also needs to be updated. With the above entry, a cache 1064 entry was created reflecting the matching SA. If no change to the cache is 1065 made, the IPsec stack will continue to use the existing SA despite the 1066 change in policy. Since implementations of the SPD cache vary widely, we 1067 do not specify the exact way to handle this change, but discuss below some 1068 implementation suggestions. 1070 One way to handle this would be to narrow the existing SPD Cache entry so 1071 as to cover only the selectors which are not affected by the SHORTCUT. 1072 This has the advantage of forcing the SPD cache entry to a failure match 1073 with the negotiated SA. Whether this is a problem depends on the 1074 implementation of these databases. It is likely not a good idea to also 1075 narrow the existing SAs. While it should be fine for outbound SAs, it will 1076 cause the IPsec stack to drop validly encrypted packets on inbound 1077 processing. 1079 Another way to handle this would be to simply delete the SPD cache entry, 1080 forcing a re-evaluation of the SPD for the next packets. This causes an 1081 even more serious discrepancy between the Security Association Database 1082 (SAD) and SPD Cache. This should only be done if it is possible to match 1083 existing SAs to new SPD cache entries, which, again, depends on the 1084 implementation details. 1086 The one foolproof way is to erase both SPD cache entries and SAs, sending 1087 the appropriate DELETE payloads to the peer. This is perfectly compliant 1088 and perfectly functional, but will create more work for the IKE daemon. 1090 5.2. Peer Authentication Database (PAD) 1092 This database will also be updated with a temporary entry when a SHORTCUT 1093 exchange is received. The entry includes the name, IP address and a 1094 specification of either PSK or certificate authentication. This entry MUST 1095 also expire when the SHORTCUT expires. 1097 It is conceivable that peers will appear in both static and dynamic 1098 entries. It is also possible that the same peer will be mentioned in 1099 multiple SHORTCUT exchanges, each with a different expiration time. An 1100 implementation of this specification MUST track all such entries. Two 1101 entries will be considered to represent the same entity if either they 1102 share both ID and certificate, or if they share ID and IP address. 1104 If all entries matching a particular entity expire, then the 1105 implementation MUST delete all IKE and child SAs associated with that 1106 entity. 1108 6. Security Considerations 1110 No lifetime is specified for the Pre-Shared Key (PSK) so the shortcut 1111 suggester SHOULD generate the PSK value with plenty of entropy. See 1112 [RANDOMNESS] for advice on generating random numbers for cryptographic 1113 purposes. The shortcut partners may rekey as needed and may even use the 1114 PSK value for reauthentication, although it is not clear that there is 1115 much value in doing so. If one of the shortcut partners decides that the 1116 PSK is too old (recognizing that it is only used for authentication), it 1117 may simply tear down the shortcut SA. Eventually, the shortcut suggester 1118 will set up the shortcut again, if it is needed. 1120 To head off this situation, the shortcut suggester may periodically 1121 initiate a new SHORTCUT exchange to each of the two shortcut partners. If 1122 a shortcut partner receives a SHORTCUT exchange suggesting a shortcut that 1123 already exists with new parameters, the shortcut partner SHOULD establish 1124 a new shortcut SA with the peer partner using the new parameters and then 1125 tear down the old shortcut SA. 1127 7. IANA Considerations 1129 IANA is requested to allocate a new payload type from the "IKEv2 Payload 1130 Types" registry with the name "Identification - Peer Address", i.e. "IDa", 1131 and this document as the corresponding reference document. 1133 IANA is requested to allocate a new Configuration Payload Attribute Type 1134 with name "PROTECTED_DOMAIN", not multivalued, with a length of "0 or more 1135 octets". 1137 IANA is requested to allocate a new payload type from the "IKEv2 Payload 1138 Types" registry with the name "ADVPN Information", i.e. "ADVPN_INFO", and 1139 this document as the corresponding reference document. 1141 IANA is requested to allocate a new exchange type from the "IKEv2 Exchange 1142 Types" registry with name "SHORTCUT" and this document as reference. 1144 IANA is requested to assign two code points from the "IKEv2 Notify Message 1145 Types - Status Types" registry, as follows. The reference document for all 1146 three shall be this document: 1148 . SHORTCUT_SUPPORTED 1149 . SHORTCUT_STATUS 1151 IANA is requested to set up a new registry called "IKEv2 ADVPN 1152 Capabilities". The value is 8-bit, and the range is partitioned as 1153 follows: 1155 . 0x00 reserved for padding 1156 . 0x01-0x08 used for version indication and negotiation 1157 . 0x09-0x07F used for supported features 1158 . 0x80-0xDF reserved 1159 . 0xE0-0xFF reserved for private use 1161 The policy for allocations from the version range shall be "Standards 1162 Action". The policy for allocation from the features range shall be 1163 "Expert Review". The initial allocation for this registry is as defined in 1164 the table in Section 3.5. with the additional column of reference 1165 specification, which shall be set to this document. 1167 IANA is requested to set up a new registry called "IKEv2 AD-VPN Response 1168 Codes". The value is 16-bit, and the range is partitioned as follows: 1170 . 0x0000-0xBFFF Used for RCODEs 1171 . 0xC000-0xFFFF Reserved for private use 1173 The policy for allocations from this registry shall be FCFS. The initial 1174 allocation is given in the table in Section 3.8.1. 1176 8. References 1178 8.1. Normative References 1180 [IKEV2] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet 1181 Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 1182 2010. 1184 [IPSECARCH] Kent, S. and K. Seo, "Security Architecture for the Internet 1185 Protocol", RFC 4301, December 2005. 1187 [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate 1188 Requirement Levels", BCP 14, RFC 2119, March 1997. 1190 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC 1191 1034, November 1987. 1193 [RFC5890] Klensin, J., "Internationalized Domain Names for Applications 1194 (IDNA): Definitions and Document Framework", RFC 5890, August 1195 2010. 1197 [HTTPCache] Fielding, R., Nottingham, M., and Reschke, J., "Hypertext 1198 Transfer Protocol (HTTP/1.1): Caching", draft-ietf-httpbis-p6- 1199 cache-23 (work in progress), July 2013. 1201 8.2. Informative References 1203 [ADVPNreq] Manral, V., "Auto Discovery VPN Problem Statement and 1204 Requirements",RFC 7018. 1206 [RANDOMNESS] Eastlake, 3rd, D., Schiller, J., and S. Crocker, "Randomness 1207 Requirements for Security", BCP 106, RFC 4086, June 2005. 1209 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for 1210 Internationalized Domain Names in Applications (IDNA)", RFC 1211 3492, March 2003. 1213 [MEDIATION] Brunner, T., "IKEv2 Mediation Extension draft-burner-ikev2- 1214 mediation-00" 1216 [RFC5737] Arkko, J., Cotton, M., and Vegoda, L., "IPv4 Address Blocks 1217 Reserved for Documentation", RFC 5737, January 2010. 1219 [RFC3849] Huston, G., Lord, A., and Smith, P., "IPv6 Address Prefix 1220 Reserved for Documentation", RFC 3849, July, 2004. 1222 9. Acknowledgments 1224 This document was prepared using 2-Word-v2.0.template.dot. 1226 The authors of this draft would like to acknowledge the following people 1227 who have contributed to or provided substantial input on the preparation 1228 of this document or predecessors to it: Scott McKinnon, Vishwas Manral, 1229 Valery Smyslov, Michael Richardson and Yaron Sheffer. 1231 Appendix A. ADVPN Example Use Cases 1233 This appendix presents a few example situations where the ADVPN protocol 1234 may be useful and illustrates how it works. 1236 A.1. Branch Office Videoconference 1238 In this example, users have initiated a videoconference between two branch 1239 offices of SmithCo located in Ashby and Bedford. Each branch office has an 1240 IPsec gateway that is configured to send all traffic to the IPsec gateway 1241 at the main SmithCo office in Paris. Figure 6 illustrates this initial 1242 situation, showing these three IPsec gateways and the IPsec SAs in place 1243 when the videoconference starts. 1245 +----------+ 1246 | Paris GW | 1247 +----------+ 1248 / \ 1249 / \ 1250 / \ 1251 / \ 1252 / \ 1253 / \ 1254 / \ 1255 +----------+ +------------+ 1256 | Ashby GW | | Bedford GW | 1257 +----------+ +------------+ 1259 Figure 6: Initial SmithCo IPsec SAs 1261 All of these gateways support SHORTCUT exchanges and have been configured 1262 to use them within SmithCo. Therefore, they all sent the ADVPN_SUPPORTED 1263 notification payload described in Section 3.4 to each other in their 1264 initial IKE exchanges. This means that they are all aware that SHORTCUT 1265 exchange may be used on the IPsec SAs illustrated in Figure 6. 1267 Once the videoconference begins, the Paris GW notices a large amount of 1268 videoconference traffic between the Ashby GW and the Bedford GW. The Paris 1269 GW has been configured to permit videoconference traffic to trigger a 1270 shortcut between two branch gateways so it initiates a SHORTCUT exchange 1271 to the Ashby and Bedford GWs, suggesting that they establish a shortcut. 1272 In this instance, it identifies the Ashby GW as the shortcut initiator by 1273 setting the I bit in the exchange sent to that gateway and leaving that 1274 bit cleared in the exchange sent to Bedford GW. 1276 Because all gateways in SmithCo have certificates from the same CA and 1277 have been configured to trust that CA to issue certificates, there is no 1278 need to use a PSK. The Paris GW simply sets the IDi Identification Payload 1279 field of the SHORTCUT exchange to the subject DN of the Ashby GW and the 1280 IDr Identification Payload field of the SHORTCUT exchange to the subject 1281 DN of the Bedford GW. 1283 The Paris GW sets the TSi Traffic Selector Payload and TSr Traffic 1284 Selector Payload fields in the SHORTCUT exchange to indicate that the 1285 Ashby GW should only use this shortcut for videoconferencing traffic 1286 destined for the network behind the Bedford GW and vice versa. 1288 After receiving the SHORTCUT exchange, the Ashby GW establishes an IKEv2 1289 exchange with the Bedford GW and then establishes an IPsec security 1290 association between the two. Figure 7 shows the SAs in use after the 1291 shortcut has been established. 1293 +----------+ 1294 | Paris GW | 1295 +----------+ 1296 / \ 1297 / \ 1298 / \ 1299 / \ 1300 / \ 1301 / \ 1302 / \ 1303 +----------+ +------------+ 1304 | Ashby GW |----------------| Bedford GW | 1305 +----------+ +------------+ 1307 Figure 7: SmithCo IPsec SAs with the shortcut established 1309 After the timeout period specified by the Paris GW, the shortcut between 1310 Ashby GW and Bedford GW will be terminated. If the videoconference is 1311 finished before that time, the shortcut may also be terminated due to 1312 inadequate traffic, at the discretion of the Ashby GW and Bedford GW. 1314 A.2. Optimization for Videoconference with Partner 1316 In this example, SmithCo has added a partner JonesCo and established an 1317 IPsec SA between Paris GW (the main SmithCo office) and Tokyo GW (the main 1318 JonesCo office). 1320 Users have initiated a videoconference between the Ashby branch office of 1321 SmithCo and the Concord branch office of JonesCo. Each branch office has 1322 an IPsec gateway that is configured to send all traffic to the IPsec 1323 gateway at the main office for that company. Figure 8 illustrates this 1324 initial situation, showing these four IPsec gateways and the IPsec SAs in 1325 place when the videoconference starts. 1327 +----------+ +----------+ 1328 | Paris GW |-------| Tokyo GW | 1329 +----------+ +----------+ 1330 / \ 1331 / \ 1332 / \ 1333 / \ 1334 / \ 1335 / \ 1336 / \ 1337 +----------+ +------------+ 1338 | Ashby GW | | Concord GW | 1339 +----------+ +------------+ 1341 Figure 8: Initial IPsec SAs within SmithCo and JonesCo 1343 All gateways in this example support SHORTCUT exchange. Therefore, they 1344 all sent the ADVPN_SUPPORTED notification payload described in Section 3.4 1345 to each other in their initial IKE exchanges. This means that they are all 1346 aware that SHORTCUT exchange may be used on the IPsec SAs illustrated in 1347 Figure 8. Further, these gateways have been configured to use SHORTCUT 1348 exchange to optimize routing for video traffic within their organizations 1349 and among SmithCo and JonesCo gateways. 1351 Once the videoconference begins, the Paris GW notices a large amount of 1352 videoconference traffic transiting the Paris GW between the Ashby GW and 1353 the Tokyo GW. Therefore, the Paris GW initiates a SHORTCUT exchange to 1354 the Ashby GW and the Tokyo GW, suggesting that they establish a shortcut. 1355 We will not cover all the details of this process because most are similar 1356 to the previous example. However, assume that the Ashby GW and the Tokyo 1357 GW have certificates from different CAs and may not be configured to trust 1358 each other's CA. Therefore, the Paris GW generates a PSK and sends it to 1359 both the Ashby GW and the Tokyo GW. The Ashby GW and the Tokyo GW use this 1360 PSK to establish a shortcut SA, as shown in Figure 9. Because of the 1361 Traffic Selectors sent by the Paris GW in the SHORTCUT exchange, this 1362 shortcut SA may only be used for video traffic between the Ashby GW and 1363 JonesCo. 1365 +----------+ +----------+ 1366 | Paris GW |-------| Tokyo GW | 1367 +----------+ +----------+ 1368 / --/ \ 1369 / --/ \ 1370 / --/ \ 1371 / --/ \ 1372 / --/ \ 1373 / --/ \ 1374 / / \ 1375 +----------+ +------------+ 1376 | Ashby GW | | Concord GW | 1377 +----------+ +------------+ 1379 Figure 9: SmithCo and JonesCo with First Shortcut 1381 After this first shortcut SA has been established, Tokyo GW notices large 1382 volumes of video traffic between Ashby GW and Concord GW. Therefore, Tokyo 1383 GW initiates a SHORTCUT exchange to the Ashby GW and the Concord GW, 1384 suggesting that they establish a shortcut. We do not cover all details of 1385 this process because they are mostly similar to the previous example. 1386 Again, the Ashby GW and the Concord GW probably have certificates from 1387 different CAs so the Tokyo GW generates a PSK and sends it to both the 1388 Ashby GW and the Concord GW. The Ashby GW and the Concord GW use this PSK 1389 to establish a shortcut SA, as shown in Figure 10. Because of the Traffic 1390 Selectors sent by the Tokyo GW in the SHORTCUT exchange, this shortcut SA 1391 may only be used for video traffic between the Ashby GW and the Concord 1392 GW. 1394 +----------+ +----------+ 1395 | Paris GW |-------| Tokyo GW | 1396 +----------+ +----------+ 1397 / --/ \ 1398 / --/ \ 1399 / --/ \ 1400 / --/ \ 1401 / --/ \ 1402 / --/ \ 1403 / / \ 1404 +----------+ +------------+ 1405 | Ashby GW |-------------------------------| Concord GW | 1406 +----------+ +------------+ 1408 Figure 10: SmithCo and JonesCo with Second Shortcut 1410 After some period, the Ashby GW or the Tokyo GW may realize that no 1411 traffic is flowing over the SA between them and therefore decide to 1412 terminate this SA. This will result in the SA configuration shown in 1413 Figure 11. 1415 Note that this optimal SA configuration has been reached without needing 1416 to have any special configuration or global knowledge and it involves 1417 multiple domains. The only requirement is a policy on the Paris GW and the 1418 Tokyo GW indicating that video traffic between SmithCo and JonesCo should 1419 be optimized by creating shortcut SAs. 1421 +----------+ +----------+ 1422 | Paris GW |-------| Tokyo GW | 1423 +----------+ +----------+ 1424 / \ 1425 / \ 1426 / \ 1427 / \ 1428 / \ 1429 / \ 1430 / \ 1431 +----------+ +------------+ 1432 | Ashby GW |-------------------------------| Concord GW | 1433 +----------+ +------------+ 1435 Figure 11: SmithCo and JonesCo in Final Configuration 1437 The shortcut between the Ashby GW and the Concord GW will remain up until 1438 its timeout is reached or traffic levels on this SA drop off because the 1439 videoconference has finished. 1441 A.3. Heterogeneous Wireless Networks Traffic 1443 As wireless networks increase their access capacities, denser deployments 1444 will become the norm. In addition, we observe an increasing number of 1445 cases where operators, for various reasons that are outside of the scope 1446 of this document, opt for network deployments that use a variety of 1447 coverage sites. In practice, this means that, for instance, macro cells 1448 are complemented by smaller cells (pico cells, femto cells, etc.) that 1449 boost capacity and improve end-user experience. Today's cellular networks 1450 can provide access rates in the order of tens of Mb/s with high quality of 1451 service guarantees, and can thus be used as connections where small and 1452 medium enterprises can base their VPNs. Within this context, the operator 1453 may use different gateways for securing subscriber VPN traffic. 1455 Consider, for example, the case illustrated in Figure 12 where two 1456 colleagues from different departments of the same company use multimedia 1457 conferencing to collaborate with some customers. Dotted lines in the 1458 Figure indicate IP connectivity, while dashed lines indicate an 1459 established SA. All gateways and endpoints in the Figure support the 1460 protocol described in this document, i.e., they have indicated so to each 1461 other as described in Section 3.4. One of them, Peer 1 has joined the 1462 teleconference while on the go, but will be arriving at the company office 1463 prior to the conclusion of the teleconference. As Peer 1 roams in the 1464 mobile network, changing cell sites as it travels towards the office, the 1465 multimedia traffic flows through the Macro GW. 1467 +----------+ +---------+ 1468 | Macro GW |-------| Pico GW | 1469 +----------+ +---------+ 1470 . . \ \ 1471 . . \ \ 1472 . . \ \ 1473 . . \ \ 1474 . +--------+ \ \ 1475 . | Cell 2 | \ \ 1476 . +--------+ \ \ 1477 +--------+ +--------+ +-----------+ 1478 | Cell 1 | | Cell 3 | | Office GW | 1479 +--------+ +--------+ +-----------+ 1480 \ \ 1481 \ \ 1482 +--------+ +--------+ 1483 Peer 1 movement >>> | Peer 1 | | Peer 2 | 1484 +--------+ +--------+ 1486 Figure 12: Initial IPsec SAs within the HetNet 1488 Note that both the Macro GW and the Pico GW are in the realm of the mobile 1489 operator, while the Office GW is in the realm of the company. 1491 The company and the mobile operator have an already established trust 1492 relationship. Moreover, for end-user experience reasons as well as traffic 1493 flow optimization both the company network administrators and the mobile 1494 operator have policies that favor traffic routes that are contained in the 1495 local company network. 1497 Once Peer 1 enters the area of the company campus the wireless network 1498 small-cell deployment covering the company buildings is the preferred 1499 means of connecting to the network, both from the perspective of the 1500 company and the mobile operator. At this stage in our scenario, the fact 1501 that Peer 1 is in the coverage area of the Pico GW is recognized by the 1502 Macro GW, which initiates (as a shortcut suggester) the procedure 1503 described in Section 3. As a result, the first step in the route 1504 optimization is performed and Peer 1 sets up the shortcut with the Pico 1505 GW, which becomes its shortcut partner. 1507 Figure 13 illustrates the newly established shortcut as well as the fact 1508 that Peer 1 continues to use the same radio interface as before, i.e. this 1509 scenario does not involve vertical handovers. 1511 +----------+ +---------+ 1512 | Macro GW |-------| Pico GW | 1513 +----------+ +---------+ 1514 . . . | \ 1515 . . . | \ 1516 . . . | \ 1517 . . . | \ 1518 . +--------+ . | \ 1519 . | Cell 2 | . | \ 1520 . +--------+ . | \ 1521 +--------+ +--------+ | +-----------+ 1522 | Cell 1 | | Cell 3 | | | Office GW | 1523 +--------+ +--------+ | +-----------+ 1524 | . \ 1525 | . \ 1526 +--------+ +--------+ 1527 | Peer 1 | | Peer 2 | 1528 +--------+ +--------+ 1530 Figure 13: First route optimization within the HetNet 1532 Once Peer 1 moves within the company premises and establishes the shortcut 1533 with the operator Pico GW more route optimization opportunities arise, and 1534 the ADVPN protocol can implement them without requiring any additional 1535 manual configuration neither by the operator nor by the company 1536 administrator. 1538 At this stage, we assume that the Pico GW can determine the fact that Peer 1539 1 could become a shortcut partner of the Office GW. Similarly to what was 1540 mentioned above, the Pico GW initiates the shortcut (i.e. acts as a 1541 shortcut suggester) indicating to Peer 1 and the Office GW that they 1542 should establish an SA with each other. The partners agree to these 1543 recommendations, as per their respective local policies, and proceed with 1544 the establishment. At the end of this process, the configuration is as 1545 illustrated in Figure 14. 1547 +----------+ +---------+ 1548 | Macro GW |-------| Pico GW | 1549 +----------+ +---------+ 1550 . . . \ 1551 . . . \ 1552 . . . \ 1553 . . . \ 1554 . +--------+ . \ 1555 . | Cell 2 | . \ 1556 . +--------+ . \ 1557 +--------+ +--------+ +-----------+ 1558 | Cell 1 | | Cell 3 | | Office GW | 1559 +--------+ +--------+ +-----------+ 1560 / \ 1561 / \ 1562 +--------+ +--------+ 1563 | Peer 1 | | Peer 2 | 1564 +--------+ +--------+ 1566 Figure 14: Second route optimization within the HetNet 1568 After this optimization all IPsec traffic is contained within the local 1569 small-cell wireless network. Note that the company network may include 1570 several pico cells, all of which can establish SAs with the Office GW. 1572 In principle, the protocol can be used to proceed with a further traffic 1573 optimization. Namely, Peer 1 and Peer 2 can establish a direct shortcut 1574 between each other, i.e. become shortcut partners and thus avoid routing 1575 through the Office GW. This is a decision that the Office GW may take 1576 based on local connectivity information. In this case, after following the 1577 same procedure described earlier, the two Peers will establish an SA, as 1578 illustrated in Figure 15. 1580 As Figure 15 shows, traffic may still flow through the Office routers but 1581 Peer 1 and Peer 2 do not need to maintain an SA with the Office GW (if 1582 there is no other traffic). 1584 Finally, note that, in principle, the Office GW could determine that since 1585 no traffic is flowing through its SA with the Pico GW, the respective SA 1586 could be temporarily terminated and initiated later on when the need 1587 arises. This final configuration is illustrated in Figure 16. 1589 +----------+ +---------+ 1590 | Macro GW |-------| Pico GW | 1591 +----------+ +---------+ 1592 . . . \ 1593 . . . \ 1594 . . . \ 1595 . . . \ 1596 . +--------+ . \ 1597 . | Cell 2 | . \ 1598 . +--------+ . \ 1599 +--------+ +--------+ +-----------+ 1600 | Cell 1 | | Cell 3 | | Office GW | 1601 +--------+ +--------+ +-----------+ 1602 . . 1603 . . 1604 +--------+ +--------+ 1605 | Peer 1 |------| Peer 2 | 1606 +--------+ +--------+ 1608 Figure 15: Third route optimization within the HetNet 1610 +----------+ +---------+ 1611 | Macro GW |-------| Pico GW | 1612 +----------+ +---------+ 1613 . . . . 1614 . . . . 1615 . . . . 1616 . . . . 1617 . +--------+ . . 1618 . | Cell 2 | . . 1619 . +--------+ . . 1620 +--------+ +--------+ +-----------+ 1621 | Cell 1 | | Cell 3 | | Office GW | 1622 +--------+ +--------+ +-----------+ 1623 . . 1624 . . 1625 +--------+ +--------+ 1626 | Peer 1 |------| Peer 2 | 1627 +--------+ +--------+ 1629 Figure 16: Final configuration 1631 Appendix B. Comparison Against ADVPN Requirements 1633 This section compares the ADVPN protocol specified in this document 1634 against requirements set by [ADVPNreq] (Section 4). 1636 Requirement #1 : 1638 This section details modifications when an endpoint, a gateway, a spoke 1639 and a hub is added or removed or changed. 1641 End points establish a tunnel with a gateway to communicate with another 1642 endpoint. The gateway may use the ADVPN protocol to optimize 1643 communication and either set up endpoint-to-endpoint communication if 1644 both endpoints are attached to the "initial gateway", or to point to a 1645 "closer alternative gateway". The ADVPN protocol described in this 1646 document, impacts either the two endpoints or the endpoint and the 1647 "closer alternative gateway". Hubs or gateways other than the "initial 1648 gateway" or the "closer alternative gateway" IPsec configuration are not 1649 impacted. 1651 An ADVPN is changed means that its IP address is modified. Updating the 1652 outer IP address is the purpose of MOBIKE and involves the two peers 1653 connected with their outer IP addresses. 1655 Similarly, removing an endpoint only impacts the IPsec configuration of 1656 the gateways or the other endpoint it is communicating with. It is up to 1657 local policy that the "initial gateway" decides to keep the IPsec 1658 configuration of the endpoint or to remove it once the endpoint has 1659 moved to the "alternative gateway that is closer". In the case the 1660 "initial gateway" does not remove the SAs associated to the endpoint, 1661 the endpoint is considered attached simultaneously to two gateways. 1663 The use of ADVPN with an endpoint that is added, removed or changed 1664 results in local IPsec configuration modifications. Only gateways that 1665 the endpoint is attached to are modified. Other gateways, spokes and hub 1666 are not impacted. 1668 Gateways may accept traffic from another gateway. The traffic may be the 1669 one associated to an endpoint or to a gateway. In the first case, the 1670 gateway is considered as the "closer alternative gateway" as discussed 1671 above. The second case occurs if the "initial gateway" tunnels traffic 1672 from an "alternative gateway" to a "closer alternative gateway". It may 1673 then use ADVPN so traffic directly goes from the "alternative gateway" 1674 to the "closer alternative gateway". The IPsec configuration is then 1675 updated on both the "alternative gateways" and the "closer alternative 1676 gateway". 1678 Similarly, when the "closer alternative gateway" is removed, only 1679 gateways and endpoints attached to these gateways are impacted. 1681 The use of ADVPN with a gateway that is added or removed results in 1682 local IPsec configuration modifications. Only gateways attached to are 1683 modified. Others gateways, spokes and hub are not impacted. 1685 Spokes are between endpoints and gateways. Unlike end points, they have 1686 a complete network, and they are attached to a hub. If a spoke-to-spoke 1687 communication is set with ADVPN, then IPsec policies of the two spokes 1688 are updated. The hub may not modify its IPsec policies. Similarly, when 1689 a spoke is removed, the IPsec policies of the other spokes are updated. 1691 The use of ADVPN with a spoke that is added or removed results in local 1692 IPsec configuration modifications. Only spokes attached to the one being 1693 removed are modified. Other gateways, spokes and hubs are not impacted. 1695 Anytime a shortcut is established, new security policies are created on 1696 the shortcut initiator and the shortcut responders. ADVPN avoids these 1697 security policies to be created manually. In addition, it uses PSK 1698 authentication, which is, reduces latency and round trip times over 1699 other authentication methods like EAP-SIM. 1701 Additionally, PROTECTED_DOMAIN capability can provide the initial 1702 protected domain subnet information to all its endpoints, from a trusted 1703 suggester. The trusted suggester provides periodic update on protected 1704 domain subnet information its endpoints. This periodic update, avoids 1705 requirement of any manual configuration change required, whenever new 1706 endpoint is added or existing endpoint is removed/updated, within given 1707 ADVPN protected domain. 1709 Requirement #2 : 1711 The solution specified in this document does not require any manual 1712 intervention for establishing a direct tunnel between endpoints. As 1713 described in Requirement #1 above and in Section 4. , SPD and SAD 1714 entries get automatically updated without any manual intervention. If an 1715 IP address of a shortcut partner has changed, MOBIKE can help in 1716 updating SPD entries automatically. If an IP address change happens 1717 after a reboot of a shortcut partner, then the peer shortcut partner 1718 will detect this condition using IKEv2 keep-alive and can divert the 1719 traffic back to the "initial-gateway". Once rebooted, the shortcut 1720 partner will establish IPsec tunnel with the "initial-gateway". At this 1721 stage, the "initial-gateway" will send SHORTCUT exchange to the shortcut 1722 partners, to establish shortcut tunnel with new IP address of shortcut 1723 partners. 1725 Requirement #3 : 1727 This draft enables shortcut partners to establish a secure channel 1728 between them automatically. This will allow other tunneling and routing 1729 protocols to establish direct tunnels or exchange route updates. 1730 However, how a routing protocol module is aware of this new shortcut 1731 tunnel (or how it exchanges route updates), with shortcut partners, 1732 using shortcut tunnel or how other tunneling protocols establish direct 1733 tunnel between shortcut partners, is specific to the vendor 1734 implementation. Thus it is out of scope of this specification. 1736 Requirement #4 : 1738 While this document describes the syntax of SHORTCUT messages, it makes 1739 no mandates about the policy for initiating shortcuts, nor about the 1740 policy for accepting or rejecting shortcuts. Some endpoints may agree to 1741 accept shortcuts from any peer, as long as the traffic selectors are a 1742 subset of those that the SPD says should go to that peer. Others may 1743 filter the shortcuts based on IKE ID, so that they do not open tunnels 1744 to endpoints outside their administrative domain. Future documents may 1745 profile such behavior. 1747 Requirement #5 : 1749 When a spoke becomes compromised it may compromise inbound/outbound 1750 communications associated with it. A compromised spoke may want to use 1751 ADVPN in order to corrupt additional traffic that go through other 1752 gateways and spokes. The ADVPN protocol provides facilities to create 1753 shortcuts, however the shortcuts for given traffic is always triggered 1754 by an endpoint dealing with that traffic. As a result, a compromised 1755 host does not affect the security of other unrelated peers. 1757 Requirement #6 : 1759 This document addresses seamless session handoffs when endpoints roam 1760 around different policy boundaries. A detailed explanation about this is 1761 given in Section A.3. 1763 Requirement #7 : 1765 When a shortcut between different gateways is created for a given 1766 endpoint-to-endpoint session, the endpoint-to-endpoint communication is 1767 not impacted by the shortcut. In other words, this is transparent to the 1768 endpoints. More precisely, a new shortcut partner is created on the two 1769 alternate gateways, spokes or hubs. This modifies the communication 1770 path, but not the session itself. 1772 Requirement #8 : 1774 This document does not explicitly detail all NAT scenarios, in this 1775 version at least, but does provide two mechanisms that address this. 1777 When the suggester proposes a shortcut to the shortcut peers, the 1778 suggester has performed IKE AUTH and can detect the shortcut peers are 1779 behind a NAT. This can be done with multiple ways including the 1780 NAT_DETECTION_SOURCE_IP / NAT_DETECTION_DESTINATION_IP Notify Payload 1781 exchange, the UDP encapsulation and use of port 4500. In most cases, 1782 when the shortcut peer is behind a NAT, inbound IKEv2 and IPsec traffic 1783 are sent through a specific port. 1785 The ADVPN protocol described in this document enables the suggester to 1786 specify each shortcut peer whether the other peer is behind a NAT or not 1787 by setting the NAT bit in the ADVPN_INFO Notification. When this bit is 1788 set, it indicates UDP encapsulation MUST be used fro IKEv2. In addition, 1789 the ADVPN_INFO Notification also specifies the UDP Port on which the 1790 shortcut peer is reachable. 1792 Another advantage of the ADVPN protocol is that the SHORTCUT exchange 1793 are sent to the shortcut peer by the suggester, and the suggester can 1794 determine whether a shortcut can be established or not. If the shortcut 1795 cannot be established, for example if the shortcut peers are both behind 1796 a NAT, then the suggester MAY forgo the establishment of the shortcut 1797 and thus avoid communication disruption due to NATs. 1799 To address scenario where both the shortcut partners are behind NAT 1800 device, SHORTCUT exchange includes each other's peer UDP port number, 1801 that the shortcut suggester is receiving IKE and IPSec traffic. This 1802 information should help the shortcut partner to reach each other in 1803 certain types of NAT deployments. 1805 Similarly the ADVPN protocol has designed optional exchanges that MAY in 1806 the future be designed to address specific NAT issues. For example, 1807 [MEDIATION] MAY be added for double NAT and hole punching. 1809 Note that ADVPN is essentially based on the use of tunnel mode which 1810 makes TS selectors independent from the IP addresses of the outer 1811 header. Thus, the use of the tunnel mode makes ADVPN more resilient to 1812 NAT compared to transport mode. 1814 Requirement #9 : 1816 This document does not create a MIB. However, it does define several 1817 events that can be reportable: 1819 * The gateway suggests a shortcut 1821 * The peer accepts or rejects a shortcut (the former involves a change 1822 in policy) 1824 * A shortcut times out (again involves a change in policy) 1826 Requirement #10 : 1828 The document is independent of administrative domains. One of the 1829 properties that may be associated with administrative domains is a set 1830 of one or more trust anchors used to issue certificates for VPN gateways 1831 and endpoints. To avoid the need for cross-trusting these anchors, this 1832 document offers the option of using dynamically-generated PSKs. 1834 Requirement #11 : 1836 While this document describes the syntax of SHORTCUT messages, it makes 1837 no mandates about the policy for initiating shortcuts, or the policy for 1838 accepting and rejecting shortcuts. Some endpoints may agree to accept 1839 shortcuts from any peer, as long as the Traffic Selectors are a subset 1840 of those that the SPD says should go to that peer. Others may filter the 1841 shortcuts based on IKE ID, so that they do not open tunnels to endpoints 1842 outside their administrative domain. Future documents may profile such 1843 behavior. 1845 Requirement #12 : 1847 The Traffic Selectors in the SHORTCUT message can be used to specify 1848 both multicast routing protocols, such as IGMP, and multicast traffic 1849 through the use of multicast addresses in selectors. With this, the 1850 SHORTCUT tunnels can be used to pass multicast and multicast routing 1851 traffic. 1853 Requirement #13 : 1855 This document defines several events that can be logged and monitored: 1857 * The gateway suggests a shortcut 1859 * The peer accepts or rejects a shortcut (the former involves a change 1860 in policy) 1862 * A shortcut times out (again involving a change in policy) 1864 A status report listing active shortcuts for a particular gateway is 1865 also possible and recommended for implementations. 1867 Requirement #14 : 1869 L3VPNs all use some kind of transport-layer protocol. GRE uses protocol 1870 number 43, IP-in-IP uses 4, and so on. Selectors for these protocols can 1871 easily be specified using the TS payloads included in SHORTCUTs. The 1872 additional information that may be needed to set up a tunnel for each of 1873 these protocols is outside the scope of this document. 1875 Requirement #15 : 1877 QoS policy is outside the scope of this document. However, the mandate 1878 of RFC 5996 to allow multiple parallel SAs for different classes of QoS 1879 applies to peers that a VPN box learns about through SHORTCUT messages. 1880 This means that QoS policy can still be enforced. If there are any 1881 additional requirements to be addressed with respect to QoS, the 1882 SHORTCUT message structure can be extended to support identified QoS 1883 attributes that should be exchanged. 1885 Requirements #16 1887 ADVPN does not make spokes, hubs or gateway single points of failure. By 1888 design, ADVPN provides two types of resiliency: Topological resiliency 1889 by creating shortcuts. These shortcuts provide alternate path, and make 1890 communications resilient in case a hub or spoke fails. In addition, the 1891 use of tunnel mode between gateways makes possible the use of MOBIKE 1892 that provides end point resiliency. 1894 Appendix C. PROTECTED_DOMAIN Example 1896 This appendix contains an example of how the PROTECTED_DOMAIN response is 1897 created. As this example requires multiple subnets, we will use the non- 1898 routable addresses from RFC 1918 in addition to the documentation subnets 1899 from RFC 5737. 1901 Assume that Company A has two major locations. First, at the company 1902 headquarters there are three non-routable subnets: 192.168.12.0/24, 1903 192.168.23.0/24, and 192.168.34.0/24. At this location, the VPN gateway 1904 has four interfaces: one towards each of the three internal subnets, and 1905 one external interface that connects to the Internet with IP address 1906 203.0.113.5, as illustrated below. 1908 203.0.113.5 1909 | 1910 | 1911 +---------+---------+ 1912 | Gateway HeadA | 1913 +----+----+----+----+ 1914 | | | 1915 192.168.12.1 | 192.168.34.1 1916 | 1917 192.168.23.1 1919 Traffic to the Internet and to partner sites gets NAT-ted, but non- 1920 routable addresses are allowed within the internal VPN. 1922 Company A has also a datacenter, at a location different from the 1923 headquarters, which is implemented as a non-routable subnet: 1924 192.168.45.0/24. In addition, there is also a routable subnet with some 1925 front-end servers: 198.51.100.0/24, known as the DMZ. The gateway has an 1926 external IP address 203.0.113.10. We would like access to the DMZ to go 1927 through the VPN for communications from within the company, but it can go 1928 either through the VPN or outside the VPN for traffic from partners. 1930 203.0.113.10 1931 | 1932 | +--198.51.100.7 - web server 1933 +---------+---------+ | 1934 | Gateway DataA +--------------+ 1935 +---------+---------+ 198.51.100.1 | 1936 | +--192.51.100.5 - SMTP server 1937 192.168.45.1 1939 In addition to the two main locations introduced above, Company A also has 1940 many smaller locations. Each of those has one /24 non-routable subnet. The 1941 initial configuration of each of those small gateways is such that the 1942 internal subnet is different from that in all the other small gateways. 1944 203.0.113.214 1945 | 1946 | 1947 +---------+---------+ 1948 | Gateway BranchA17 | 1949 +---------+---------+ 1950 | 1951 10.85.153.1/24 1953 Company A also has a supplier, Company B, that has their own gateway with 1954 some routable and some non-routable addresses. They have a VPN tunnel 1955 configured with Gateway DataA. Although there is some overlap in the 1956 protected domains, the only non-routable addresses that go through this 1957 VPN are the 192.168.23.0/24 subnet that is behind HeadA, and the 1958 192.168.99.0/24 that is behind HeadB. Others are either blocked, or NAT- 1959 ted behind the address of HeadB 1961 203.0.113.122 1962 | 1963 | 1964 +---------+---------+ 1965 | Gateway HeadB | 1966 +----+---------+----+ 1967 | | 1968 192.168.12.4 192.168.99.4 1970 Only the branch office gateways and Gateway HeadA need the 1971 PROTECTED_DOMAIN (see Section 3.9. ) configuration attribute. Gateway 1972 HeadB has a static policy, and Gateway DataA will not send to it a 1973 PROTECTED_DOMAIN according to the established policy. The field contains 1974 the union of all the sets of addresses for which the DataA server is 1975 willing to forward traffic. 1977 For the BranchA17 gateway, the initial configuration is very simple: 1979 . One peer is defined: Gateway DataA (203.0.113.10) 1980 . Either a CA certificate and a DN for DataA, or a PSK 1981 . An internal network: 10.85.153.0/24 1982 . Gateway DataA is a trusted suggester 1984 In total, there are nine other branch office gateways other than 1985 BranchA17, and of course there is Gateway HeadA and Gateway HeadB. Only 1986 Gateway DataA knows about all of them. So the PROTECTED_DOMAIN it sends to 1987 other gateways from the same administrative domain is as follows: 1989 . 192.168.12.0/24 (from behind HeadA) 1990 . 192.168.23.0/24 (from behind HeadA) 1991 . 192.168.34.0/24 (from behind HeadA) 1992 . 192.168.45.0/24 (from behind DataA itself) 1993 . 198.51.100.0/24 (DMZ behind DataA itself) 1994 . 192.168.99.0/24 (from behind HeadB) 1995 . 10.85.101.0/24 (from behind BranchA01) 1996 . 10.85.104.0/24 (from behind BranchA02) 1997 . 10.85.125.0/24 (from behind BranchA03) 1998 . 10.85.131.0/24 (from behind BranchA04) 1999 . 10.85.139.0/24 (from behind BranchA11) 2000 . 10.85.143.0/24 (from behind BranchA12) 2001 . 10.85.150.0/24 (from behind BranchA16) 2002 . 10.85.153.0/24 (from behind BranchA17) 2003 . 10.85.159.0/24 (from behind BranchA18) 2004 . 10.85.162.0/24 (from behind BranchA19) 2006 Every time a new branch gateway is added, its protected domain is added to 2007 the SPD of DataA, and this also updates the contents of the 2008 PROTECTED_DOMAIN that it sends. As described in Section 4.2. , the content 2009 expires in BranchA17 after a while, so the cache expiry time is also the 2010 time it takes for such a change to propagate to the other branch offices. 2012 When BranchA17 receives this PROTECTED_DOMAIN, it removes its own 2013 protected domain and anything else for which it has a static 2014 configuration, and adds the rest into the SPD as traffic that is protected 2015 and tunneled to the trusted suggester (Gateway DataA). 2017 A more complex scenario would send a different PROTECTED_DOMAIN also to 2018 the partner gateway HeadB. For example, it could send the following 2019 PROTECTED_DOMAIN: 2021 . 192.168.23.0/24 (This is a network behind Gateway HeadA) 2022 . 192.168.45.1/32 (This is a single address at Gateway DataA) 2024 The reason for having this configuration is that the IP addresses behind 2025 branch office gateways are not guaranteed to be unique outside of the 2026 administrative domain. So Gateway DataA NATs these addresses behind its 2027 own IP address, which then has to be part of the protected domain. Note 2028 that under this specification, such traffic cannot be "shortcutted", 2029 because we don't have a way to tell the BranchA17 gateway to NAT these 2030 packets when sending them through the shortcut tunnel (TBD) 2032 Authors' Addresses 2034 Praveen Sathyanarayan 2035 Juniper Networks, Inc. 2036 1194 N. Mathilda Ave. 2037 Sunnyvale, CA 94089 2038 USA 2040 Email: praveenys@juniper.net 2042 Steve Hanna 2043 Juniper Networks, Inc. 2044 1194 N. Mathilda Ave. 2045 Sunnyvale, CA 94089 2046 USA 2048 Email: shanna@juniper.net 2050 Suresh Nagavenkata Melam 2051 Juniper Networks, Inc. 2052 1194 N. Mathilda Ave. 2053 Sunnyvale, CA 94089 2054 USA 2056 Email: nmelam@juniper.net 2058 Yoav Nir 2059 Check Point Software Technologies Ltd. 2060 5 Hasolelim st. 2062 Tel Aviv 6789735 2063 Israel 2065 Email: ynir@checkpoint.com 2067 Daniel Migault 2068 Francetelecom - Orange 2069 38 rue du General Leclerc 2070 92794 Issy-les-Moulineaux Cedex 9 2071 France 2073 Email: mglt.ietf@gmail.com 2075 Kostas Pentikousis 2076 EICT GmbH 2077 Torgauer Strasse 12-15 2078 10829 Berlin 2079 Germany 2081 Email: k.pentikousis@eict.de