idnits 2.17.00 (12 Aug 2021) /tmp/idnits34016/draft-mglt-ipsecme-security-gateway-discovery-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 14, 2013) is 3376 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) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPSECME D. Migault (Ed) 3 Internet-Draft Francetelecom - Orange 4 Intended status: Standards Track K. Pentikousis 5 Expires: August 18, 2013 Huawei Technologies 6 February 14, 2013 8 IKEv2 Security Gateway Discovery 9 draft-mglt-ipsecme-security-gateway-discovery-00.txt 11 Abstract 13 Modern Virtual Private Network (VPN) services are typically deployed 14 using several security gateways and are frequently accessed over a 15 wireless network. There are several reasons for such a deployment 16 ranging from enhancing system resilience to improving performance. 18 For example, in order to handle traffic efficiently and reduce the 19 burden in the core network, the VPN service may be implemented in a 20 distributed manner using multiple Security Gateways. A mobile VPN 21 End User is attached to one of them using a WLAN interface and over 22 time is likely to change its Security Gateway of attachment. In this 23 case, in order to optimize the overall user Quality of Experience 24 (QoE), a VPN End User should select the next most appropriate 25 Security Gateway based on the characteristics of the available 26 Security Gateways. This draft specifies how a VPN End User can 27 securely collect information about Security Gateways in its network 28 neighborhood in order to optimize its VPN experience. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on August 18, 2013. 47 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 64 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4.1. Multiple Interfaces . . . . . . . . . . . . . . . . . . . 5 68 4.2. Closest Next Neighbor . . . . . . . . . . . . . . . . . . 6 69 4.3. Intra-Security Gateway Services . . . . . . . . . . . . . 7 70 4.4. Why We Cannot Rely On DNS Only . . . . . . . . . . . . . . 7 71 5. Security Gateway Discovery Protocol . . . . . . . . . . . . . 8 72 5.1. Sending a NEIGHBOR_INFORMATION Query . . . . . . . . . . . 8 73 5.2. Receiving NEIGHBOR_INFORMATION . . . . . . . . . . . . . . 9 74 5.2.1. NEIGHBOR_INFORMATION Query Processing . . . . . . . . 10 75 5.2.2. NEIGHBOR_INFORMATION Response Processing . . . . . . . 10 76 5.2.3. Informative NEIGHBOR_INFORMATION . . . . . . . . . . . 11 77 6. Notify Payload Format . . . . . . . . . . . . . . . . . . . . 11 78 6.1. NEIGHBOR_INFORMATION Notify Payload . . . . . . . . . . . 11 79 6.2. Initiator Options: O-REQUEST . . . . . . . . . . . . . . . 12 80 6.3. Responder Options . . . . . . . . . . . . . . . . . . . . 13 81 6.3.1. Neighbor: NEIGHBOR . . . . . . . . . . . . . . . . . . 13 82 6.3.2. Interface Option: O_INTERFACE . . . . . . . . . . . . 13 83 6.3.3. Geo-localization Option: O_GEOLOC . . . . . . . . . . 14 84 6.3.4. Intra-Security Gateway Bandwidth Option: O_ISG-BW . . 14 85 6.3.5. Intra-Security Gateway Mobility Support Option: 86 O_ISG-MOB . . . . . . . . . . . . . . . . . . . . . . 15 87 6.4. General Options . . . . . . . . . . . . . . . . . . . . . 15 88 6.4.1. Padding Payload: PADDING . . . . . . . . . . . . . . . 16 89 6.4.2. Maximum Neighbors Payload: MAX-NEIGHBOR . . . . . . . 16 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 92 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 94 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 95 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 96 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 18 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 99 1. Requirements notation 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. 105 2. Introduction 107 When a Virtual Private Network (VPN) client establishes a VPN 108 connection with a distributed VPN infrastructure, care should be 109 taken to choose the most appropriate Security Gateway. DNS may be 110 considered as a selection mechanism to determine the first point of 111 attachment to the distributed VPN infrastructure. However, as we 112 explain later in this document, the information provided by DNS is 113 limited and insufficient for this purpose. In effect, the VPN End 114 User cannot rely on this information to optimize its point of 115 attachment. Moreover, for the case of mobile nodes, such information 116 cannot help in the case of multiple interface communication nor 117 properly handle VPN mobility from one Security Gateway to another. 118 This document addresses this problem by describing how a VPN End User 119 can request from its Security Gateway information about other 120 neighbor Security Gateways. Equipped with this knowledge the VPN End 121 User can select the most appropriate Security Gateway. 123 The remainder of this document is organized as follows. Section 3 124 defines the terms and acronyms used in this document. Section 4 125 introduces scenarios that relate to Security Gateway selection. For 126 each scenario, specific criteria are used by the VPN End User to 127 select the most appropriate Security Gateway. Section 5 and 128 Section 6 specify the Security Gateway Discovery Protocol introduced 129 in this document, including defining the packet exchanges and the 130 corresponding involved payloads, respectively. 132 3. Terminology 134 This section defines the terms and acronyms used in this document. 136 - VPN End User (EU): designates the entity that initiates a VPN 137 connection with a Security Gateway. A VPN End User may be 138 mobile and, as per this document, can change its VPN connection 139 from one Security Gateway to another. 141 - Security Gateway: designates the network point of attachment for 142 the VPN service. In this document, the VPN service can be 143 provided by multiple Security Gateways. Each Security Gateway 144 may be considered as a specific logical or physical network 145 entity. 147 - VPN service: designates the service provided to the End User. 148 From the end-user point of view, in colloquial terms, this is 149 what typical users consider as "establishing a VPN connection". 151 Throughout the document we assume that the user is not interested 152 and, therefore, is not informed about which Security Gateway is 153 chosen. We consider that mobility, both in terms of network point of 154 attachment and the Security Gateway used for the VPN service, is 155 handled inherently by the network and the user is not concerned about 156 the actual operational details. 158 4. Motivation 160 This section motivates the technical solution advocated in this 161 document by presenting three scenarios where the selection of the 162 Security Gateway can significantly improve the Quality of Experience 163 (QoE) of a VPN End User. For each scenario, we describe the 164 information that the VPN End User needs in order to select the 165 appropriate Security Gateway. 167 4.1. Multiple Interfaces 169 Multiple interfaces on the VPN End User or on the Security Gateway 170 make possible path selection. If the VPN End User is able to perform 171 path selection, it is likely to chose a Security Gateway that has 172 multiple interfaces. Between multiple Security Gateways with 173 multiple interfaces it may chose the one whose interfaces are 174 attached to its preferred networks. This Security Gateway selection 175 is particularly important since VPN End User can hardly split their 176 VPN on two distinct Security Gateways. 178 Distributed VPN infrastructures are composed of multiple, independent 179 Security Gateways. Currently, IPsec [RFC4301] does not have the 180 mechanisms that enable "moving" a VPN connection from one Security 181 Gateway to another Security Gateway. In practice, this means that 182 moving the endpoint of a VPN connection from one Security Gateway to 183 another requires a renegotiation establishment of a new VPN. This 184 may also include new authentication for the VPN End User, likely with 185 the need for user input in the process. On the other hand, MOBIKE 186 [RFC4555] enables moving a VPN connection from one interface to 187 another as long as they are attached to the same Security Gateway. 188 Thus, we have two ways with different impact on the corresponding end 189 user Quality of Experience (QoE), to move a VPN connection from one 190 interface to another depending on whether these interfaces belong to 191 the same node or not. As a result, a client implementing the MOBIKE 192 extension can perform interface management, and opt to be be attached 193 to a Security Gateway with multiple interfaces. 195 Note that with IPsec [RFC4301], the signaling channel is defined by 196 the IKE_SA while the user data is designated by the IPsec_SA. Unless 197 specifically designed otherwise, these two channels are highly 198 dependent on each other and MUST be hosted on the same host. More 199 specifically, it is not possible for a VPN End User to have its IKE 200 channel with one host and its IPsec_SA with a different, independent 201 host. 203 Note also that MOBIKE enables a Security Gateway to inform a VPN End 204 User about its available interfaces. However, these interfaces 205 belongs to the Security Gateway the VPN End User is attached to, not 206 another Security Gateway. 208 This document defines how a VPN End User can query a Security Gateway 209 in a distributed VPN infrastructure whether other, neighboring 210 Security Gateway have one or multiple interfaces. In this document 211 we are concerned about the other Security Gateways so that the VPN 212 End User can decide which Security Gateway it should be attached to 213 next. 215 4.2. Closest Next Neighbor 217 With a large distributed VPN infrastructure like those serving xDSL 218 broadband networks, a mobile VPN End User needs to define which 219 Security Gateway it will be attached to next. The current Security 220 Gateway can assist a VPN End User to avoid spending effort on 221 Security Gateway discovery by providing this localization 222 information. This is beneficial both in terms of network bandwidth 223 and system resources. 225 Localization may be based on geo-localization data. Nevertheless, in 226 many cases, the optimal Security Gateway for each particular VPN End 227 User may not be the one that is closer in geographical terms, but the 228 one with the best inter-Security Gateway bandwidth. In fact, in 229 recent distributed mobility architectures, DSL boxes in a typical 230 urban environment exchange information using their WLAN interface to 231 avoid congesting the core network. 233 We argue that if Security Gateways can exchange information they can 234 improve VPN client mobility and reduce traffic overhead. Such 235 information may include, for instance, VPN client authentication 236 credentials, IPsec counters, or packet redirection. Using this 237 information-exchange protocol, the VPN End User has, for example, the 238 advantage of moving to the DSL box with the best inter-Security- 239 Gateway bandwidth. 241 4.3. Intra-Security Gateway Services 243 Although currently IPsec does not enable a VPN client to move from 244 one Security Gateway to another one, proprietary protocols that 245 enable such mobility from one Security Gateway to another do exist. 246 This may, for example, involve exchange of IPsec counters. This 247 information may help the VPN End User to properly chose the next 248 Security Gateway it will be attached to. Standardizing the way this 249 information is exchanged can benefit end users and network operators 250 alike. 252 4.4. Why We Cannot Rely On DNS Only 254 DNS binds a FQDN to one or multiple IP addresses. In that sense, one 255 may consider that DNS could be leveraged upon to provide information 256 sufficient to determine the neighboring Security Gateways. 257 Unfortunately, this is not the case because FQDN is an abstraction, 258 and in our case, the FQDN most probably designates the name of the 259 VPN service as a whole. Thus, DNS is used to bind the VPN service 260 with specific interfaces, without specifying which Security Gateway 261 they belong to. Since this information is not available, the VPN End 262 User cannot select a specific Security Gateway, as two issues arise 263 as we explain next. 265 First, DNS can provide a list of multiple interfaces available for a 266 given service (i.e. FQDN), which enables a client to choose the most 267 appropriate interface at the moment in time that it initiates a VPN 268 service. Once connected to one of the Security Gateways, MOBIKE 269 makes possible to convey to the VPN End User the available interfaces 270 on the Security Gateway that the client is attached to. In 271 principle, the VPN End User could then use the list of interfaces 272 provided by DNS, correlate it with that received via MOBIKE and come 273 to some conclusion with respect to Security Gateway availability. 274 Besides the fact that this method is inexact science at best, it does 275 not add much value in large deployments. Since each Security Gateway 276 may have multiple interfaces, it has no clue if the remaining 277 interfaces belong to a single Security Gateway or to multiple 278 Security Gateways. This information cannot be provided by DNS. This 279 motivates us to provide this information at the service layer, that 280 is to say, for the VPN service, via IKEv2. 282 Second, DNS usually does not provide the complete list of all 283 Security Gateway interfaces, but often just a subset of those 284 available by the VPN service. For largely distributed applications, 285 DNS provides a subset of available interfaces that are "close" to the 286 resolving server. The problem with this is that DNS can hardly 287 provide the "closest" server to the VPN End User. Firstly, defining 288 the closest interface of the DNS query emitter remains difficult. 290 Secondly, it is impossible to consider the various interfaces of the 291 VPN End User. Thirdly, the DNS query is usually sent by a resolving 292 server, not by the VPN End User. Because of this indeterminacy, DNS 293 may be more concerned about avoiding the worst answer, rather than 294 looking for the best option. Thus, it may look for answers with a 295 large diversity instead of focusing their answers to a given 296 location. Among the proposed interfaces, the VPN End User may chose 297 the most convenient interface according to its policy or its 298 interfaces. 300 Note that [I-D.vandergaast-edns-client-ip] makes possible to avoid 301 considering the resolving server location instead of the VPN client. 303 5. Security Gateway Discovery Protocol 305 In this document we assume that the VPN End User is already attached 306 to a Security Gateway. The goal of this exchange is that the VPN End 307 User can obtain information about other Security Gateways which are 308 designated as neighbors. 310 The proposed Security Gateway Discovery Protocol (SGDP) employs a 311 query / response exchange mechanism. Usually, the exchange is 312 initiated by the VPN End User and the responder is the Security 313 Gateway that the VPN End User is connected to. However, the protocol 314 does not exclude that either of the peers initiates the exchange. 316 5.1. Sending a NEIGHBOR_INFORMATION Query 318 The initiator builds the NEIGHBOR_INFORMATION Notify Payload 319 (described in Section 6.1) by setting the Question bit to 1 and 320 providing the necessary Options. Notify Payloads have a Critical bit 321 set. 323 The Option request Option (described in Section 6.2)makes possible to 324 list the queried information about each neighboring Security Gateway. 325 In this document, the Options that can be queried are: 327 - Interface Option: lists the interfaces associated to the 328 neighboring Security Gateway. 330 - Geo-localization Option: provides geographic coordinates of the 331 neighboring Security Gateway. 333 - Intra-Security Gateway Bandwidth Option: indicates how much 334 bandwidth the current Security Gateway shares with the 335 neighboring Security Gateway. 337 - Intra-Security Gateway Mobility Support Option: indicates if the 338 current Security Gateway and the neighboring Security Gateway 339 share a specific mobility protocol to ease moving the VPN 340 connection from the current Security Gateway to the neighboring 341 Security Gateway. 343 The Maximum Neighbor Option is intended to limit the size of the 344 response and indicates how many neighboring Security Gateway SHOULD 345 be considered. Finally, the Padding Payload format pads the overall 346 Notify Payload to a length that is a multiple of 32 bits. Other 347 Options may be added for future use. 349 5.2. Receiving NEIGHBOR_INFORMATION 351 A received NEIGHBOR_INFORMATION Notify Payload may be originating 352 from a query by the initiator as described in Section 5.1. This case 353 is detailed in Section 5.2.1, below. Alternatively, the incoming 354 message may be a response to a query previously sent by the VPN 355 connection peer, which is detailed in Section 5.2.2. The protocol 356 also supports informative messages as detailed in Section 5.2.3. 357 Finally, the received NEIGHBOR_INFORMATION Notify Payload may be an 358 unwanted message. 360 Once a NEIGHBOR_INFORMATION Notify Payload is received, the responder 361 checks whether the Critical bit is set to 1. If the Critical Bit is 362 set and the Notify Payload is not supported by the responder then, 363 following [RFC5996] section 2.5, setting the Critical bit to one 364 forces the Responder to send back a UNSUPPORTED_CRITICAL_PAYLOAD 365 Notify Payload if it does not understand the received Notify Payload. 367 If the Critical bit is set, and the receiver supports the 368 NEIGHBOR_INFORMATION Notify Payload, the receiver checks the Question 369 Bit. A set Question Bit means that the Notify Payload is a query as 370 described in Section 5.1, and a response MUST formed and sent back to 371 the initiator. This is described in Section 5.2.1. If the Question 372 Bit is not set, then the Notify Payload corresponds to a response. 373 If no corresponding query has been sent previously an INVALID_SYNTAX 374 MUST be sent back and the rest of the Notify Payload MUST be ignored. 375 Conversely, if a query has been sent, the receiver will process the 376 response as per Section 5.2.2. 378 If the Critical bit is not set and the Notify Payload is not 379 supported by the receiver, the Notify Payload MUST be ignored. 380 However, this case is expected to only occur for informative 381 NEIGHBOR_INFORMATION Notify Payload as described in Section 5.2.3. 383 If the Critical Bit is not set and the receiver supports the 384 NEIGHBOR_INFORMATION Notify Payload, then the receiver examines the 385 Question Bit. If it is set, the message MUST be ignored. This is to 386 avoid ambiguity in cases where the initiator does not know if it 387 receives no response because there is no information or because the 388 Notify Payload is not supported by the responder. If the Question 389 Bit is not set, the Notify Payload corresponds to an informative 390 NEIGHBOR_INFORMATION Notify Payload. This case is detailed in 391 Section 5.2.3. 393 5.2.1. NEIGHBOR_INFORMATION Query Processing 395 For this section we assume that the Critical Bit and the Question Bit 396 are set, the Notify Payload is properly formed and the receiver 397 understands the NEIGHBOR_INFORMATION Notify Payload. 399 The responder checks if a Maximum Neighbor Option is in the query. 400 If not present, the responder is allowed to provide as much Neighbor 401 Payload information as deemed best. If the option is present, then 402 the responder SHOULD check its internal policy and determine how many 403 Neighbor Payload can be provided in the response. If the limit set 404 by the internal policy is lower that what is requested by the 405 initiator in the Maximum Neighbor Option, the responder MUST indicate 406 it by providing a Maximum Neighbor Option that corresponds to the 407 actual number of Neighbor Payloads. 409 The responder checks if a Option request Option is in the query. If 410 not, the responder MAY use its default policy about the default 411 Options to be returned. It MAY also return a void response. In any 412 other case, the responder lists the queried Options. For each 413 Neighbor, if the responder has the queried information, it MUST 414 indicate it in the Neighbor Payload. 416 The Padding Option is used to properly format the response, and the 417 response is sent to the initiator. 419 5.2.2. NEIGHBOR_INFORMATION Response Processing 421 This section assumes that the Critical Bit is set and the Question 422 Bit is not set, the Notify Payload is properly formed and the 423 receiver understands the NEIGHBOR_INFORMATION Notify Payload. 425 If a Maximum Neighbor Option is present, this means that only a 426 subset of the available information has been sent. If no Maximum 427 Neighbor Option has been sent in the query, the number received 428 indicates an internal policy of the responder. On the other hand, if 429 a Maximum Neighbor Option has been sent in the query, a number equal 430 to the one specified in the query is expected. Other values indicate 431 an internal policy of the responder. 433 5.2.3. Informative NEIGHBOR_INFORMATION 435 The VPN connection peer may provide informative NEIGHBOR_INFORMATION 436 without being queried. This is the case when the Critical Bit and 437 the Question Bit are not set, the Notify Payload is properly formed 438 and the receiver understands the NEIGHBOR_INFORMATION Notify Payload. 440 6. Notify Payload Format 442 This section introduces the Notify Payload for the Security Gateway 443 Discovery Protocol. 445 6.1. NEIGHBOR_INFORMATION Notify Payload 447 Fig. 1 illustrates the NEIGHBOR_INFORMATION Notify Payload packet 448 format. 450 1 2 3 451 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 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Next Payload |C| RESERVED | Payload Length | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Protocol ID | SPI Size | Notify Message Type | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 |Q| RESERVED | | 458 +-+-+-+-+-+-+-+-+ | 459 | | 460 ~ Notification Data ~ 461 | | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 Figure 1: NEIGHBOR_INFORMATION Notify Payload 466 - Next Payload (1 octet): Indicates the type of payload that follows 467 after the header. 469 - Critical Bit (1 bit): Indicates how the responder handles the 470 Notify Payload. In this document the Critical Bit is not set 471 only when an informative NEIGHBOR_INFORMATION is sent. 472 Otherwise, the Critical bit is set to 1. 474 - RESERVED (7 bits): MUST be sen as zero; MUST be ignored on 475 receipt. 477 - Payload Length (2 octet): Length in octets of the current payload, 478 including the generic payload header. 480 - Protocol ID (1 octet): set to zero. 482 - SPI Size (1 octet): set to zero. 484 - Notify Message Type (2 octets): Specifies the type of notification 485 message NEIGHBOR_INFORMATION_QUERY 487 - Question Bit (1 bit): set to one by the initiator and set to zero 488 by the responder. 490 - RESERVED (7 bits): set to zero. 492 - Notification Data (variable length): When the Notify Payload is 493 sent by the initiator, the Notification data is composed of 494 Parameters. 496 6.2. Initiator Options: O-REQUEST 498 This section provides the parameters that comprise the Notification 499 Data of the initiator. 501 The Option Request Payload defines the Options requested for each 502 neighbor. In other words, it is expected in the response that each 503 Neighbor Payload (NEIGHBOR) Section 6.3.1 is filled with these 504 Options. 506 1 2 3 507 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 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | O-REQUEST | Payload Length | | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 511 | | 512 ~ List of Option ID ~ 513 | | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 Figure 2: Option Request Option: O-REQUEST 518 - Option-ID (1 octet): O-REQUEST 520 - Payload Length (2 octet): Payload Length expressed in octet and 521 includes the Option-ID and Payload Length fields' length. The 522 Payload may not be a multiple of 32 bytes. 524 - List of Option ID (variable length): List of the Option that are 525 expected for each NEIGHBOR Payload. 527 6.3. Responder Options 529 6.3.1. Neighbor: NEIGHBOR 531 The Neighbor Payload contains information about a neighbor Security 532 Gateway. The number of Neighbor Payloads is defined by the Maximum 533 Neighbors Payload, or if not specified by the responder. If the 534 number of Neighbor Payloads is defined by the responder, the 535 responder MUST add the Maximum Neighbors Payload. 537 1 2 3 538 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 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | NEIGHBOR | Payload Length | | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 542 | | 543 ~ List of Option Payload ~ 544 | | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 Figure 3: Neighbor: NEIGHBOR 549 - Option-ID (1 octet): NEIGHBOR 551 - Payload Length (2 octet): Payload Length expressed in octets, 552 including the Option-ID and Payload Length fields' length. The 553 Payload may not be a multiple of 32 bytes. 555 - List of Option Payload (variable length): List of the Option 556 Payload requested by the initiator. 558 6.3.2. Interface Option: O_INTERFACE 560 The Interface Option provides the IP addresses of the Neighbor. 562 1 2 3 563 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 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | O_INTERFACE |V| RESERVED | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | | 568 ~ IP Address Value ~ 569 | | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 Figure 4: Interface Option: O_INTERFACE 573 - Option-ID (1 octet): O_INTERFACE 575 - Version Bit (1 bit): The Version Bit indicates if the IP address 576 is an IPv4 or an IPv6 IP address. The Version Bit is set to 1 577 for an IPv4 address. 579 - RESERVED (23 bits): Set to Zero. 581 - IP Address Value (4 or 16 octets): The IP address value. An IPv4 582 address is 4 octet long and an IPv6 address is 16 octets long. 584 6.3.3. Geo-localization Option: O_GEOLOC 586 The Geo-localization Option provides Geographic coordinates of the 587 Neighbor. 589 1 2 3 590 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 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | O_GEOLOC | Payload Length | | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 594 | | 595 ~ GEOLOC Data ~ 596 | | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 Figure 5: Geo-localization Option: O_GEOLOC 601 - Option-ID (1 octet): O_GEOLOC 603 - Payload Length (2 octet): Payload Length expressed in octets 604 including the Option-ID and Payload Length fields' length. The 605 Payload may not be a multiple of 32 bytes. 607 - GEOLOC Data (variable length): GEOLOC Data as defined in 608 [RFC1876]. 610 6.3.4. Intra-Security Gateway Bandwidth Option: O_ISG-BW 612 The Intra-Security Gateway Bandwidth Option characterizes the link 613 between the responder and the Neighbor. 615 1 2 3 616 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 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | O_ISG-BW | RESERVED | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Band Width Value | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 Figure 6: Intra-Security Gateway Bandwidth Option: O_ISG-BW 625 - Option-ID (1 octet): O_ISG-BW 627 - RESERVED (3 octets): Set to Zero. 629 - Band Width Value (4 octets): Specifies the bandwidth in octets per 630 second. 632 6.3.5. Intra-Security Gateway Mobility Support Option: O_ISG-MOB 634 The Intra-Security Gateway Mobility Option defines if there are any 635 mechanisms that support VPN mobility from the responder to the 636 Neighbor. 638 1 2 3 639 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 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | O_ISG-MOB | Mob. Support | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 Figure 7: Intra-Security Gateway Mobility Support Option: O_ISG-MOB 646 - Option-ID (1 octet): O_ISG-MOB 648 - Mobility Support (1 octet): Specifies how VPN mobility is 649 supported from the responder to the Neighbor. 651 Currently the following values are provided for Mobility Support: 653 - UNSUPPORTED_MOBILITY: 0 655 - IPSEC_CONTEXT_TRANSFERED: 1 657 6.4. General Options 659 This section describes two options that can be used by both the 660 initiator and the responder. 662 6.4.1. Padding Payload: PADDING 664 The Padding Payload is used to make the NEIGHBOR_INFORMATION Notify 665 Payload length a multiple of 32 bits. 667 1 2 3 668 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 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 | PADDING | Payload Length | | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 672 | | 673 ~ Padding Octets ~ 674 | | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 Figure 8: Padding Payload: PADDING 679 - Option-ID (1 octet): PADDING 681 - Payload Length (1 octet): Payload Length expressed in octet and 682 includes the Option-ID and Payload Length fields' length. In 683 case one need 2 octet padding, the Payload Length is set to 2. 684 If there is only a need for a 1 octet padding, then 4 685 additional padding octets must be added and the Payload Length 686 is set to 5. 688 - Padding Octets (variable length): These Octets are for padding and 689 MUST NOT be interpreted. 691 6.4.2. Maximum Neighbors Payload: MAX-NEIGHBOR 693 The Maximum Neighbors Payload sets the maximum number of Neighbor the 694 VPN End User wants information about. This Option is of fixed size. 696 1 2 3 697 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 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | MAX-NEIGHBOR | Maximum Number | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 Figure 9: Maximum Neighbors Payload: MAX-NEIGHBOR 704 - Option-ID (1 octet): MAX-NEIGHBOR 706 - Maximum Number (1 octet): Specifies the maximum number of NEIGHBOR 707 Payload the response carries. 709 7. IANA Considerations 711 The new fields and number are the following: 713 IKEv2 Notify Message Types - Status Types 714 ----------------------------------------- 715 NEIGHBOR_INFORMATION 717 Security Gateway Discovery Attributes 718 ------------------------------------- 719 O-REQUEST 720 PADDING 721 MAX-NEIGHBOR 722 NEIGHBOR 724 Neighbor Options 725 ---------------- 726 O_INTERFACE 727 O_GEOLOC 728 O_ISG-BW 729 O_ISG-MOB 731 O_ISG-MOB Attributes 732 -------------------- 733 UNSUPPORTED_MOBILITY 734 IPSEC_CONTEXT_TRANSFERED 736 8. Security Considerations 738 The exchange described in this document is protected by the IKEv2 739 channel. Then, the only concern may be the information that a 740 Security Gateway provides to the VPN End User. We do not see how the 741 provided information can be used against the Security Gateway. 742 Furthermore, the VPN End User has already been authenticated by IKEv2 743 prior to being able to obtain such information. 745 9. Acknowledgments 747 TBD 749 10. References 750 10.1. Normative References 752 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 753 Requirement Levels", BCP 14, RFC 2119, March 1997. 755 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 756 Internet Protocol", RFC 4301, December 2005. 758 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 759 (MOBIKE)", RFC 4555, June 2006. 761 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 762 "Internet Key Exchange Protocol Version 2 (IKEv2)", 763 RFC 5996, September 2010. 765 10.2. Informative References 767 [I-D.vandergaast-edns-client-ip] 768 Contavalli, C., Gaast, W., Leach, S., and D. Rodden, 769 "Client IP information in DNS requests", 770 draft-vandergaast-edns-client-ip-01 (work in progress), 771 May 2010. 773 [RFC1876] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A 774 Means for Expressing Location Information in the Domain 775 Name System", RFC 1876, January 1996. 777 Appendix A. Document Change Log 779 [RFC Editor: This section is to be removed before publication] 781 -00: First version published. 783 Authors' Addresses 785 Daniel Migault 786 Francetelecom - Orange 787 38 rue du General Leclerc 788 92794 Issy-les-Moulineaux Cedex 9 789 France 791 Phone: +33 1 45 29 60 52 792 Email: mglt.ietf@gmail.com 793 Kostas Pentikousis 794 Huawei Technologies 795 Carnotstrasse 4 796 10587 Berlin 797 Germany 799 Email: k.pentikousis@huawei.com