IPSECME D. Migault (Ed)
Internet-Draft Francetelecom - Orange
Intended status: Standards Track K. Pentikousis
Expires: August 18, 2013 Huawei Technologies
February 14, 2013
IKEv2 Security Gateway Discovery
draft-mglt-ipsecme-security-gateway-discovery-00.txt
Abstract
Modern Virtual Private Network (VPN) services are typically deployed
using several security gateways and are frequently accessed over a
wireless network. There are several reasons for such a deployment
ranging from enhancing system resilience to improving performance.
For example, in order to handle traffic efficiently and reduce the
burden in the core network, the VPN service may be implemented in a
distributed manner using multiple Security Gateways. A mobile VPN
End User is attached to one of them using a WLAN interface and over
time is likely to change its Security Gateway of attachment. In this
case, in order to optimize the overall user Quality of Experience
(QoE), a VPN End User should select the next most appropriate
Security Gateway based on the characteristics of the available
Security Gateways. This draft specifies how a VPN End User can
securely collect information about Security Gateways in its network
neighborhood in order to optimize its VPN experience.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 18, 2013.
Copyright Notice
Migault (Ed) & Pentikousis Expires August 18, 2013 [Page 1]
Internet-Draft Security Gateway Discovery February 2013
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Migault (Ed) & Pentikousis Expires August 18, 2013 [Page 2]
Internet-Draft Security Gateway Discovery February 2013
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Multiple Interfaces . . . . . . . . . . . . . . . . . . . 5
4.2. Closest Next Neighbor . . . . . . . . . . . . . . . . . . 6
4.3. Intra-Security Gateway Services . . . . . . . . . . . . . 7
4.4. Why We Cannot Rely On DNS Only . . . . . . . . . . . . . . 7
5. Security Gateway Discovery Protocol . . . . . . . . . . . . . 8
5.1. Sending a NEIGHBOR_INFORMATION Query . . . . . . . . . . . 8
5.2. Receiving NEIGHBOR_INFORMATION . . . . . . . . . . . . . . 9
5.2.1. NEIGHBOR_INFORMATION Query Processing . . . . . . . . 10
5.2.2. NEIGHBOR_INFORMATION Response Processing . . . . . . . 10
5.2.3. Informative NEIGHBOR_INFORMATION . . . . . . . . . . . 11
6. Notify Payload Format . . . . . . . . . . . . . . . . . . . . 11
6.1. NEIGHBOR_INFORMATION Notify Payload . . . . . . . . . . . 11
6.2. Initiator Options: O-REQUEST . . . . . . . . . . . . . . . 12
6.3. Responder Options . . . . . . . . . . . . . . . . . . . . 13
6.3.1. Neighbor: NEIGHBOR . . . . . . . . . . . . . . . . . . 13
6.3.2. Interface Option: O_INTERFACE . . . . . . . . . . . . 13
6.3.3. Geo-localization Option: O_GEOLOC . . . . . . . . . . 14
6.3.4. Intra-Security Gateway Bandwidth Option: O_ISG-BW . . 14
6.3.5. Intra-Security Gateway Mobility Support Option:
O_ISG-MOB . . . . . . . . . . . . . . . . . . . . . . 15
6.4. General Options . . . . . . . . . . . . . . . . . . . . . 15
6.4.1. Padding Payload: PADDING . . . . . . . . . . . . . . . 16
6.4.2. Maximum Neighbors Payload: MAX-NEIGHBOR . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Migault (Ed) & Pentikousis Expires August 18, 2013 [Page 3]
Internet-Draft Security Gateway Discovery February 2013
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Introduction
When a Virtual Private Network (VPN) client establishes a VPN
connection with a distributed VPN infrastructure, care should be
taken to choose the most appropriate Security Gateway. DNS may be
considered as a selection mechanism to determine the first point of
attachment to the distributed VPN infrastructure. However, as we
explain later in this document, the information provided by DNS is
limited and insufficient for this purpose. In effect, the VPN End
User cannot rely on this information to optimize its point of
attachment. Moreover, for the case of mobile nodes, such information
cannot help in the case of multiple interface communication nor
properly handle VPN mobility from one Security Gateway to another.
This document addresses this problem by describing how a VPN End User
can request from its Security Gateway information about other
neighbor Security Gateways. Equipped with this knowledge the VPN End
User can select the most appropriate Security Gateway.
The remainder of this document is organized as follows. Section 3
defines the terms and acronyms used in this document. Section 4
introduces scenarios that relate to Security Gateway selection. For
each scenario, specific criteria are used by the VPN End User to
select the most appropriate Security Gateway. Section 5 and
Section 6 specify the Security Gateway Discovery Protocol introduced
in this document, including defining the packet exchanges and the
corresponding involved payloads, respectively.
3. Terminology
This section defines the terms and acronyms used in this document.
- VPN End User (EU): designates the entity that initiates a VPN
connection with a Security Gateway. A VPN End User may be
mobile and, as per this document, can change its VPN connection
from one Security Gateway to another.
- Security Gateway: designates the network point of attachment for
the VPN service. In this document, the VPN service can be
provided by multiple Security Gateways. Each Security Gateway
may be considered as a specific logical or physical network
Migault (Ed) & Pentikousis Expires August 18, 2013 [Page 4]
Internet-Draft Security Gateway Discovery February 2013
entity.
- VPN service: designates the service provided to the End User.
From the end-user point of view, in colloquial terms, this is
what typical users consider as "establishing a VPN connection".
Throughout the document we assume that the user is not interested
and, therefore, is not informed about which Security Gateway is
chosen. We consider that mobility, both in terms of network point of
attachment and the Security Gateway used for the VPN service, is
handled inherently by the network and the user is not concerned about
the actual operational details.
4. Motivation
This section motivates the technical solution advocated in this
document by presenting three scenarios where the selection of the
Security Gateway can significantly improve the Quality of Experience
(QoE) of a VPN End User. For each scenario, we describe the
information that the VPN End User needs in order to select the
appropriate Security Gateway.
4.1. Multiple Interfaces
Multiple interfaces on the VPN End User or on the Security Gateway
make possible path selection. If the VPN End User is able to perform
path selection, it is likely to chose a Security Gateway that has
multiple interfaces. Between multiple Security Gateways with
multiple interfaces it may chose the one whose interfaces are
attached to its preferred networks. This Security Gateway selection
is particularly important since VPN End User can hardly split their
VPN on two distinct Security Gateways.
Distributed VPN infrastructures are composed of multiple, independent
Security Gateways. Currently, IPsec [RFC4301] does not have the
mechanisms that enable "moving" a VPN connection from one Security
Gateway to another Security Gateway. In practice, this means that
moving the endpoint of a VPN connection from one Security Gateway to
another requires a renegotiation establishment of a new VPN. This
may also include new authentication for the VPN End User, likely with
the need for user input in the process. On the other hand, MOBIKE
[RFC4555] enables moving a VPN connection from one interface to
another as long as they are attached to the same Security Gateway.
Thus, we have two ways with different impact on the corresponding end
user Quality of Experience (QoE), to move a VPN connection from one
interface to another depending on whether these interfaces belong to
the same node or not. As a result, a client implementing the MOBIKE
Migault (Ed) & Pentikousis Expires August 18, 2013 [Page 5]
Internet-Draft Security Gateway Discovery February 2013
extension can perform interface management, and opt to be be attached
to a Security Gateway with multiple interfaces.
Note that with IPsec [RFC4301], the signaling channel is defined by
the IKE_SA while the user data is designated by the IPsec_SA. Unless
specifically designed otherwise, these two channels are highly
dependent on each other and MUST be hosted on the same host. More
specifically, it is not possible for a VPN End User to have its IKE
channel with one host and its IPsec_SA with a different, independent
host.
Note also that MOBIKE enables a Security Gateway to inform a VPN End
User about its available interfaces. However, these interfaces
belongs to the Security Gateway the VPN End User is attached to, not
another Security Gateway.
This document defines how a VPN End User can query a Security Gateway
in a distributed VPN infrastructure whether other, neighboring
Security Gateway have one or multiple interfaces. In this document
we are concerned about the other Security Gateways so that the VPN
End User can decide which Security Gateway it should be attached to
next.
4.2. Closest Next Neighbor
With a large distributed VPN infrastructure like those serving xDSL
broadband networks, a mobile VPN End User needs to define which
Security Gateway it will be attached to next. The current Security
Gateway can assist a VPN End User to avoid spending effort on
Security Gateway discovery by providing this localization
information. This is beneficial both in terms of network bandwidth
and system resources.
Localization may be based on geo-localization data. Nevertheless, in
many cases, the optimal Security Gateway for each particular VPN End
User may not be the one that is closer in geographical terms, but the
one with the best inter-Security Gateway bandwidth. In fact, in
recent distributed mobility architectures, DSL boxes in a typical
urban environment exchange information using their WLAN interface to
avoid congesting the core network.
We argue that if Security Gateways can exchange information they can
improve VPN client mobility and reduce traffic overhead. Such
information may include, for instance, VPN client authentication
credentials, IPsec counters, or packet redirection. Using this
information-exchange protocol, the VPN End User has, for example, the
advantage of moving to the DSL box with the best inter-Security-
Gateway bandwidth.
Migault (Ed) & Pentikousis Expires August 18, 2013 [Page 6]
Internet-Draft Security Gateway Discovery February 2013
4.3. Intra-Security Gateway Services
Although currently IPsec does not enable a VPN client to move from
one Security Gateway to another one, proprietary protocols that
enable such mobility from one Security Gateway to another do exist.
This may, for example, involve exchange of IPsec counters. This
information may help the VPN End User to properly chose the next
Security Gateway it will be attached to. Standardizing the way this
information is exchanged can benefit end users and network operators
alike.
4.4. Why We Cannot Rely On DNS Only
DNS binds a FQDN to one or multiple IP addresses. In that sense, one
may consider that DNS could be leveraged upon to provide information
sufficient to determine the neighboring Security Gateways.
Unfortunately, this is not the case because FQDN is an abstraction,
and in our case, the FQDN most probably designates the name of the
VPN service as a whole. Thus, DNS is used to bind the VPN service
with specific interfaces, without specifying which Security Gateway
they belong to. Since this information is not available, the VPN End
User cannot select a specific Security Gateway, as two issues arise
as we explain next.
First, DNS can provide a list of multiple interfaces available for a
given service (i.e. FQDN), which enables a client to choose the most
appropriate interface at the moment in time that it initiates a VPN
service. Once connected to one of the Security Gateways, MOBIKE
makes possible to convey to the VPN End User the available interfaces
on the Security Gateway that the client is attached to. In
principle, the VPN End User could then use the list of interfaces
provided by DNS, correlate it with that received via MOBIKE and come
to some conclusion with respect to Security Gateway availability.
Besides the fact that this method is inexact science at best, it does
not add much value in large deployments. Since each Security Gateway
may have multiple interfaces, it has no clue if the remaining
interfaces belong to a single Security Gateway or to multiple
Security Gateways. This information cannot be provided by DNS. This
motivates us to provide this information at the service layer, that
is to say, for the VPN service, via IKEv2.
Second, DNS usually does not provide the complete list of all
Security Gateway interfaces, but often just a subset of those
available by the VPN service. For largely distributed applications,
DNS provides a subset of available interfaces that are "close" to the
resolving server. The problem with this is that DNS can hardly
provide the "closest" server to the VPN End User. Firstly, defining
the closest interface of the DNS query emitter remains difficult.
Migault (Ed) & Pentikousis Expires August 18, 2013 [Page 7]
Internet-Draft Security Gateway Discovery February 2013
Secondly, it is impossible to consider the various interfaces of the
VPN End User. Thirdly, the DNS query is usually sent by a resolving
server, not by the VPN End User. Because of this indeterminacy, DNS
may be more concerned about avoiding the worst answer, rather than
looking for the best option. Thus, it may look for answers with a
large diversity instead of focusing their answers to a given
location. Among the proposed interfaces, the VPN End User may chose
the most convenient interface according to its policy or its
interfaces.
Note that [I-D.vandergaast-edns-client-ip] makes possible to avoid
considering the resolving server location instead of the VPN client.
5. Security Gateway Discovery Protocol
In this document we assume that the VPN End User is already attached
to a Security Gateway. The goal of this exchange is that the VPN End
User can obtain information about other Security Gateways which are
designated as neighbors.
The proposed Security Gateway Discovery Protocol (SGDP) employs a
query / response exchange mechanism. Usually, the exchange is
initiated by the VPN End User and the responder is the Security
Gateway that the VPN End User is connected to. However, the protocol
does not exclude that either of the peers initiates the exchange.
5.1. Sending a NEIGHBOR_INFORMATION Query
The initiator builds the NEIGHBOR_INFORMATION Notify Payload
(described in Section 6.1) by setting the Question bit to 1 and
providing the necessary Options. Notify Payloads have a Critical bit
set.
The Option request Option (described in Section 6.2)makes possible to
list the queried information about each neighboring Security Gateway.
In this document, the Options that can be queried are:
- Interface Option: lists the interfaces associated to the
neighboring Security Gateway.
- Geo-localization Option: provides geographic coordinates of the
neighboring Security Gateway.
- Intra-Security Gateway Bandwidth Option: indicates how much
bandwidth the current Security Gateway shares with the
neighboring Security Gateway.
Migault (Ed) & Pentikousis Expires August 18, 2013 [Page 8]
Internet-Draft Security Gateway Discovery February 2013
- Intra-Security Gateway Mobility Support Option: indicates if the
current Security Gateway and the neighboring Security Gateway
share a specific mobility protocol to ease moving the VPN
connection from the current Security Gateway to the neighboring
Security Gateway.
The Maximum Neighbor Option is intended to limit the size of the
response and indicates how many neighboring Security Gateway SHOULD
be considered. Finally, the Padding Payload format pads the overall
Notify Payload to a length that is a multiple of 32 bits. Other
Options may be added for future use.
5.2. Receiving NEIGHBOR_INFORMATION
A received NEIGHBOR_INFORMATION Notify Payload may be originating
from a query by the initiator as described in Section 5.1. This case
is detailed in Section 5.2.1, below. Alternatively, the incoming
message may be a response to a query previously sent by the VPN
connection peer, which is detailed in Section 5.2.2. The protocol
also supports informative messages as detailed in Section 5.2.3.
Finally, the received NEIGHBOR_INFORMATION Notify Payload may be an
unwanted message.
Once a NEIGHBOR_INFORMATION Notify Payload is received, the responder
checks whether the Critical bit is set to 1. If the Critical Bit is
set and the Notify Payload is not supported by the responder then,
following [RFC5996] section 2.5, setting the Critical bit to one
forces the Responder to send back a UNSUPPORTED_CRITICAL_PAYLOAD
Notify Payload if it does not understand the received Notify Payload.
If the Critical bit is set, and the receiver supports the
NEIGHBOR_INFORMATION Notify Payload, the receiver checks the Question
Bit. A set Question Bit means that the Notify Payload is a query as
described in Section 5.1, and a response MUST formed and sent back to
the initiator. This is described in Section 5.2.1. If the Question
Bit is not set, then the Notify Payload corresponds to a response.
If no corresponding query has been sent previously an INVALID_SYNTAX
MUST be sent back and the rest of the Notify Payload MUST be ignored.
Conversely, if a query has been sent, the receiver will process the
response as per Section 5.2.2.
If the Critical bit is not set and the Notify Payload is not
supported by the receiver, the Notify Payload MUST be ignored.
However, this case is expected to only occur for informative
NEIGHBOR_INFORMATION Notify Payload as described in Section 5.2.3.
If the Critical Bit is not set and the receiver supports the
NEIGHBOR_INFORMATION Notify Payload, then the receiver examines the
Migault (Ed) & Pentikousis Expires August 18, 2013 [Page 9]
Internet-Draft Security Gateway Discovery February 2013
Question Bit. If it is set, the message MUST be ignored. This is to
avoid ambiguity in cases where the initiator does not know if it
receives no response because there is no information or because the
Notify Payload is not supported by the responder. If the Question
Bit is not set, the Notify Payload corresponds to an informative
NEIGHBOR_INFORMATION Notify Payload. This case is detailed in
Section 5.2.3.
5.2.1. NEIGHBOR_INFORMATION Query Processing
For this section we assume that the Critical Bit and the Question Bit
are set, the Notify Payload is properly formed and the receiver
understands the NEIGHBOR_INFORMATION Notify Payload.
The responder checks if a Maximum Neighbor Option is in the query.
If not present, the responder is allowed to provide as much Neighbor
Payload information as deemed best. If the option is present, then
the responder SHOULD check its internal policy and determine how many
Neighbor Payload can be provided in the response. If the limit set
by the internal policy is lower that what is requested by the
initiator in the Maximum Neighbor Option, the responder MUST indicate
it by providing a Maximum Neighbor Option that corresponds to the
actual number of Neighbor Payloads.
The responder checks if a Option request Option is in the query. If
not, the responder MAY use its default policy about the default
Options to be returned. It MAY also return a void response. In any
other case, the responder lists the queried Options. For each
Neighbor, if the responder has the queried information, it MUST
indicate it in the Neighbor Payload.
The Padding Option is used to properly format the response, and the
response is sent to the initiator.
5.2.2. NEIGHBOR_INFORMATION Response Processing
This section assumes that the Critical Bit is set and the Question
Bit is not set, the Notify Payload is properly formed and the
receiver understands the NEIGHBOR_INFORMATION Notify Payload.
If a Maximum Neighbor Option is present, this means that only a
subset of the available information has been sent. If no Maximum
Neighbor Option has been sent in the query, the number received
indicates an internal policy of the responder. On the other hand, if
a Maximum Neighbor Option has been sent in the query, a number equal
to the one specified in the query is expected. Other values indicate
an internal policy of the responder.
Migault (Ed) & Pentikousis Expires August 18, 2013 [Page 10]
Internet-Draft Security Gateway Discovery February 2013
5.2.3. Informative NEIGHBOR_INFORMATION
The VPN connection peer may provide informative NEIGHBOR_INFORMATION
without being queried. This is the case when the Critical Bit and
the Question Bit are not set, the Notify Payload is properly formed
and the receiver understands the NEIGHBOR_INFORMATION Notify Payload.
6. Notify Payload Format
This section introduces the Notify Payload for the Security Gateway
Discovery Protocol.
6.1. NEIGHBOR_INFORMATION Notify Payload
Fig. 1 illustrates the NEIGHBOR_INFORMATION Notify Payload packet
format.
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q| RESERVED | |
+-+-+-+-+-+-+-+-+ |
| |
~ Notification Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: NEIGHBOR_INFORMATION Notify Payload
- Next Payload (1 octet): Indicates the type of payload that follows
after the header.
- Critical Bit (1 bit): Indicates how the responder handles the
Notify Payload. In this document the Critical Bit is not set
only when an informative NEIGHBOR_INFORMATION is sent.
Otherwise, the Critical bit is set to 1.
- RESERVED (7 bits): MUST be sen as zero; MUST be ignored on
receipt.
Migault (Ed) & Pentikousis Expires August 18, 2013 [Page 11]
Internet-Draft Security Gateway Discovery February 2013
- Payload Length (2 octet): Length in octets of the current payload,
including the generic payload header.
- Protocol ID (1 octet): set to zero.
- SPI Size (1 octet): set to zero.
- Notify Message Type (2 octets): Specifies the type of notification
message NEIGHBOR_INFORMATION_QUERY
- Question Bit (1 bit): set to one by the initiator and set to zero
by the responder.
- RESERVED (7 bits): set to zero.
- Notification Data (variable length): When the Notify Payload is
sent by the initiator, the Notification data is composed of
Parameters.
6.2. Initiator Options: O-REQUEST
This section provides the parameters that comprise the Notification
Data of the initiator.
The Option Request Payload defines the Options requested for each
neighbor. In other words, it is expected in the response that each
Neighbor Payload (NEIGHBOR) Section 6.3.1 is filled with these
Options.
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| O-REQUEST | Payload Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
~ List of Option ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Option Request Option: O-REQUEST
- Option-ID (1 octet): O-REQUEST
- Payload Length (2 octet): Payload Length expressed in octet and
includes the Option-ID and Payload Length fields' length. The
Payload may not be a multiple of 32 bytes.
Migault (Ed) & Pentikousis Expires August 18, 2013 [Page 12]
Internet-Draft Security Gateway Discovery February 2013
- List of Option ID (variable length): List of the Option that are
expected for each NEIGHBOR Payload.
6.3. Responder Options
6.3.1. Neighbor: NEIGHBOR
The Neighbor Payload contains information about a neighbor Security
Gateway. The number of Neighbor Payloads is defined by the Maximum
Neighbors Payload, or if not specified by the responder. If the
number of Neighbor Payloads is defined by the responder, the
responder MUST add the Maximum Neighbors Payload.
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NEIGHBOR | Payload Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
~ List of Option Payload ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Neighbor: NEIGHBOR
- Option-ID (1 octet): NEIGHBOR
- Payload Length (2 octet): Payload Length expressed in octets,
including the Option-ID and Payload Length fields' length. The
Payload may not be a multiple of 32 bytes.
- List of Option Payload (variable length): List of the Option
Payload requested by the initiator.
6.3.2. Interface Option: O_INTERFACE
The Interface Option provides the IP addresses of the Neighbor.
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| O_INTERFACE |V| RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ IP Address Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Migault (Ed) & Pentikousis Expires August 18, 2013 [Page 13]
Internet-Draft Security Gateway Discovery February 2013
Figure 4: Interface Option: O_INTERFACE
- Option-ID (1 octet): O_INTERFACE
- Version Bit (1 bit): The Version Bit indicates if the IP address
is an IPv4 or an IPv6 IP address. The Version Bit is set to 1
for an IPv4 address.
- RESERVED (23 bits): Set to Zero.
- IP Address Value (4 or 16 octets): The IP address value. An IPv4
address is 4 octet long and an IPv6 address is 16 octets long.
6.3.3. Geo-localization Option: O_GEOLOC
The Geo-localization Option provides Geographic coordinates of the
Neighbor.
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| O_GEOLOC | Payload Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
~ GEOLOC Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Geo-localization Option: O_GEOLOC
- Option-ID (1 octet): O_GEOLOC
- Payload Length (2 octet): Payload Length expressed in octets
including the Option-ID and Payload Length fields' length. The
Payload may not be a multiple of 32 bytes.
- GEOLOC Data (variable length): GEOLOC Data as defined in
[RFC1876].
6.3.4. Intra-Security Gateway Bandwidth Option: O_ISG-BW
The Intra-Security Gateway Bandwidth Option characterizes the link
between the responder and the Neighbor.
Migault (Ed) & Pentikousis Expires August 18, 2013 [Page 14]
Internet-Draft Security Gateway Discovery February 2013
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| O_ISG-BW | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Band Width Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Intra-Security Gateway Bandwidth Option: O_ISG-BW
- Option-ID (1 octet): O_ISG-BW
- RESERVED (3 octets): Set to Zero.
- Band Width Value (4 octets): Specifies the bandwidth in octets per
second.
6.3.5. Intra-Security Gateway Mobility Support Option: O_ISG-MOB
The Intra-Security Gateway Mobility Option defines if there are any
mechanisms that support VPN mobility from the responder to the
Neighbor.
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| O_ISG-MOB | Mob. Support |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Intra-Security Gateway Mobility Support Option: O_ISG-MOB
- Option-ID (1 octet): O_ISG-MOB
- Mobility Support (1 octet): Specifies how VPN mobility is
supported from the responder to the Neighbor.
Currently the following values are provided for Mobility Support:
- UNSUPPORTED_MOBILITY: 0
- IPSEC_CONTEXT_TRANSFERED: 1
6.4. General Options
This section describes two options that can be used by both the
initiator and the responder.
Migault (Ed) & Pentikousis Expires August 18, 2013 [Page 15]
Internet-Draft Security Gateway Discovery February 2013
6.4.1. Padding Payload: PADDING
The Padding Payload is used to make the NEIGHBOR_INFORMATION Notify
Payload length a multiple of 32 bits.
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PADDING | Payload Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
~ Padding Octets ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Padding Payload: PADDING
- Option-ID (1 octet): PADDING
- Payload Length (1 octet): Payload Length expressed in octet and
includes the Option-ID and Payload Length fields' length. In
case one need 2 octet padding, the Payload Length is set to 2.
If there is only a need for a 1 octet padding, then 4
additional padding octets must be added and the Payload Length
is set to 5.
- Padding Octets (variable length): These Octets are for padding and
MUST NOT be interpreted.
6.4.2. Maximum Neighbors Payload: MAX-NEIGHBOR
The Maximum Neighbors Payload sets the maximum number of Neighbor the
VPN End User wants information about. This Option is of fixed size.
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX-NEIGHBOR | Maximum Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Maximum Neighbors Payload: MAX-NEIGHBOR
- Option-ID (1 octet): MAX-NEIGHBOR
- Maximum Number (1 octet): Specifies the maximum number of NEIGHBOR
Payload the response carries.
Migault (Ed) & Pentikousis Expires August 18, 2013 [Page 16]
Internet-Draft Security Gateway Discovery February 2013
7. IANA Considerations
The new fields and number are the following:
IKEv2 Notify Message Types - Status Types
-----------------------------------------
NEIGHBOR_INFORMATION
Security Gateway Discovery Attributes
-------------------------------------
O-REQUEST
PADDING
MAX-NEIGHBOR
NEIGHBOR
Neighbor Options
----------------
O_INTERFACE
O_GEOLOC
O_ISG-BW
O_ISG-MOB
O_ISG-MOB Attributes
--------------------
UNSUPPORTED_MOBILITY
IPSEC_CONTEXT_TRANSFERED
8. Security Considerations
The exchange described in this document is protected by the IKEv2
channel. Then, the only concern may be the information that a
Security Gateway provides to the VPN End User. We do not see how the
provided information can be used against the Security Gateway.
Furthermore, the VPN End User has already been authenticated by IKEv2
prior to being able to obtain such information.
9. Acknowledgments
TBD
10. References
Migault (Ed) & Pentikousis Expires August 18, 2013 [Page 17]
Internet-Draft Security Gateway Discovery February 2013
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
10.2. Informative References
[I-D.vandergaast-edns-client-ip]
Contavalli, C., Gaast, W., Leach, S., and D. Rodden,
"Client IP information in DNS requests",
draft-vandergaast-edns-client-ip-01 (work in progress),
May 2010.
[RFC1876] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A
Means for Expressing Location Information in the Domain
Name System", RFC 1876, January 1996.
Appendix A. Document Change Log
[RFC Editor: This section is to be removed before publication]
-00: First version published.
Authors' Addresses
Daniel Migault
Francetelecom - Orange
38 rue du General Leclerc
92794 Issy-les-Moulineaux Cedex 9
France
Phone: +33 1 45 29 60 52
Email: mglt.ietf@gmail.com
Migault (Ed) & Pentikousis Expires August 18, 2013 [Page 18]
Internet-Draft Security Gateway Discovery February 2013
Kostas Pentikousis
Huawei Technologies
Carnotstrasse 4
10587 Berlin
Germany
Email: k.pentikousis@huawei.com
Migault (Ed) & Pentikousis Expires August 18, 2013 [Page 19]