<?xml version="1.0" encoding="US-ASCII"?>
<?rfc linefile="1:/tmp/CGI11956.1"?>
<?rfc linefile="1:/tmp/CGI11956.1"?>
<?rfc toc="yes"?>
<!-- generate a table of contents -->
<?rfc symrefs="yes"?>
<!-- use anchors instead of numbers for references -->
<?rfc sortrefs="yes" ?>
<!-- alphabetize the references -->
<?rfc compact="yes" ?>
<!-- conserve vertical whitespace -->
<?rfc subcompact="no" ?>
<!-- but keep a blank line between list items -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc1876 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1876.xml">
<!ENTITY rfc4555 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4555.xml">
<!ENTITY rfc5996 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5996.xml">
<!ENTITY rfc4301 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml">
<!ENTITY I-D.vandergaast-edns-client-ip PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.vandergaast-edns-client-ip.xml">
]>
<rfc category="std"
     docName="draft-mglt-ipsecme-security-gateway-discovery-00.txt"
     ipr="trust200902">
  <front>
    <title abbrev="Security Gateway Discovery">IKEv2 Security Gateway Discovery</title>

    <author fullname="Daniel Migault" initials="D." surname="Migault (Ed)">
		<organization>Francetelecom - Orange</organization>
		<address>
			<postal>
				<street>38 rue du General Leclerc</street>
				<city>92794 Issy-les-Moulineaux Cedex 9</city>
				<country>France</country>
			</postal>
			<phone>+33 1 45 29 60 52</phone>
			<email>mglt.ietf@gmail.com</email>
		</address>
	</author>

	<author fullname="Kostas Pentikousis" initials="K." surname="Pentikousis">
		<organization>Huawei Technologies</organization>
		<address>
			<postal>
				<street>Carnotstrasse 4</street>
				<city>10587 Berlin</city>
				<country>Germany</country>
			</postal>
			<email>k.pentikousis@huawei.com</email>
		</address>
	</author>
	
    <date day="14" month="February" year="2013"/>

    <area>SECURITY</area>

    <workgroup>IPSECME</workgroup>

    <abstract>
     <t>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.</t> 
    <t>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.</t> 
   </abstract>
  </front>

  <middle>
    <section title="Requirements notation">
      <t>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 <xref target="RFC2119"/>.</t>
	</section>

	
    <section title="Introduction">
        <t>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.</t>

        <t>The remainder of this document is organized as follows.  <xref target="sec-terminology"/> defines the terms and acronyms used in this document. <xref target="sec-scenario-sg-selection"/> 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.  <xref target="sec-protocol-exchange"/> and <xref target="sec-payload-format"/> specify the Security Gateway Discovery Protocol introduced in this document, including defining the packet exchanges and the corresponding involved payloads, respectively.</t>

    </section>

	
    <section title="Terminology" anchor="sec-terminology">
		<t>This section defines the terms and acronyms used in this document.</t>
		<t>
        <list hangIndent="6" style="hanging">
			<t hangText="- 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.</t>
			<t hangText="- 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 entity.</t>
			<t hangText="- 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".</t>
		</list>
		</t>

		<t>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.</t>
    </section>
  
  
    <section title="Motivation" anchor="sec-scenario-sg-selection">

    <t>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.</t>
	
	
	<section title="Multiple Interfaces">
                <t>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.</t>

		<t>Distributed VPN infrastructures are composed of multiple, independent Security Gateways.  Currently, IPsec <xref target="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 <xref target="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 extension can perform interface management, and opt to be be attached to a Security Gateway with multiple interfaces.</t>
		
<!--		<t>With respect to Security Gateway selection, MOBIKE enables a multihomed or mobile node to change its point of attachment while retaining the same Security Gateway.  Similarly, a Security Gateway can change the interface that is using to provide the VPN Service to a VPN End User.  Either way, the end-hosts at both sides of the VPN connection remain the same; only the network interface changes. In short, MOBIKE does not "allow simultaneous movement of both parties or discovery of the addresses when the IKE_SA is first established" <xref target="RFC4555"/>.</t> 
-->		
		<t>Note that with IPsec <xref target="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.</t>

                <t>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.</t>
		
		<t>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.</t>
        </section>

		
    <section title="Closest Next Neighbor">
            
        <t>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.</t>

        <t>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.</t> 

        <t>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.</t>
        </section>

		
    <section title="Intra-Security Gateway Services">

		<t>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.</t>
	</section>
   
	
	<section title="Why We Cannot Rely On DNS Only">

	<t>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.</t>

    <t>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.</t>

	<t>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.  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.</t>
	
	<t>Note that <xref target="I-D.vandergaast-edns-client-ip"/> makes possible to avoid considering the resolving server location instead of the VPN client.</t>
    </section>
	</section>
	
    <section title="Security Gateway Discovery Protocol" anchor="sec-protocol-exchange">
    
	<t>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.</t>

    <t>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.</t>
	
	<section title="Sending a NEIGHBOR_INFORMATION Query" anchor="sec-sending-query-ni">

    <t>The initiator builds the NEIGHBOR_INFORMATION Notify Payload (described in <xref target="sec-notify-payload"/>) by setting the Question bit to 1 and providing the necessary Options.  Notify Payloads have a Critical bit set.</t> 
    
    <t>The Option request Option (described in <xref target="sec-options-format"/>)makes possible to list the queried information about each neighboring Security Gateway.  In this document, the Options that can be queried are: 

	<list style="hanging" hangIndent="6">
		<t hangText="- Interface Option:"> lists the interfaces associated to the neighboring Security Gateway.</t>
		
		<t hangText="- Geo-localization Option:">  provides geographic coordinates of the neighboring Security Gateway.</t>
        
		<t hangText="- Intra-Security Gateway Bandwidth Option:"> indicates how much bandwidth the current Security Gateway shares with the neighboring Security Gateway.</t> 
        
		<t hangText="- 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.</t>
    </list>
     </t>

    <t>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.</t> 
    </section>

    
	<section title="Receiving NEIGHBOR_INFORMATION">

    <t>A received NEIGHBOR_INFORMATION Notify Payload may be originating from a query  by the initiator as described in <xref target="sec-sending-query-ni"/>.  This case is detailed in <xref target="sec-query-ni"/>, below.  Alternatively, the incoming message may be a response to a query previously sent by the VPN connection peer, which is detailed in <xref target ="sec-response-ni"/>.  The protocol also supports informative messages as detailed in <xref target="sec-informative-ni"/>.  Finally, the received NEIGHBOR_INFORMATION Notify Payload may be an unwanted message.</t>

    <t>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 <xref target="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.</t>
	
    <t>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 <xref target="sec-sending-query-ni"/>, and a response MUST formed and sent back to the initiator.  This is described in <xref target="sec-query-ni"/>.  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 <xref target ="sec-response-ni"/>.</t>

    <t>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 <xref target="sec-informative-ni"/>.</t>

    <t>If the Critical Bit is not set and the receiver supports the NEIGHBOR_INFORMATION Notify Payload, then the receiver examines the 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 <xref target="sec-informative-ni"/>.</t>

       
		<section title="NEIGHBOR_INFORMATION Query Processing" anchor="sec-query-ni">
		<t>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.</t>  
          
		<t>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.</t>

		<t>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.</t>

		<t>The Padding Option is used to properly format the response, and the response is sent to the initiator.</t>
		</section>


		<section title="NEIGHBOR_INFORMATION Response Processing" anchor="sec-response-ni">
        
		<t>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.</t>  

		<t>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.</t>
		</section>

	
		<section title="Informative NEIGHBOR_INFORMATION" anchor="sec-informative-ni">

		<t>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.</t> 
		</section>
	</section>
    </section>

	
    <section title="Notify Payload Format" anchor="sec-payload-format">

	<t>This section introduces the Notify Payload for the Security Gateway Discovery Protocol.</t>

	<section anchor="sec-notify-payload" title="NEIGHBOR_INFORMATION Notify Payload">

	<t>Fig. 1 illustrates the NEIGHBOR_INFORMATION Notify Payload packet format.</t>
	
	<figure>
	<artwork>
                        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
	</artwork>
	</figure>

	<t>
	<list style="hanging" hangIndent="6">

		<t hangText="- Next Payload (1 octet):">Indicates the type of payload that follows after the header.</t>
		<t hangText="- 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. </t>
		<t hangText="- RESERVED (7 bits):"> MUST be sen as zero; MUST be ignored on receipt.</t>
		<t hangText="- Payload Length (2 octet):"> Length in octets of the current payload, including the generic payload header.</t>
		<t hangText="- Protocol ID (1 octet):"> set to zero.</t>
		<t hangText="- SPI Size (1 octet):"> set to zero.</t>
		<t hangText="- Notify Message Type (2 octets):"> Specifies the type of notification message NEIGHBOR_INFORMATION_QUERY</t>
		<t hangText="- Question Bit (1 bit):"> set to one by the initiator and set to zero by the responder.</t>
		<t hangText="- RESERVED (7 bits):"> set to zero.</t>
		<t hangText="- Notification Data (variable length):">When the Notify Payload is sent by the initiator, the Notification data is composed of Parameters.</t>
	</list>
	</t>
	
	</section>


	<section anchor="sec-options-format" title="Initiator Options: O-REQUEST">

	<t>This section provides the parameters that comprise the Notification Data of the initiator.</t>
	
	<t>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) <xref target = "sec-neighbor"/> is filled with these Options.</t>

	<figure>
	<artwork>
                        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
	</artwork>
	</figure>

	<t>
	<list style="hanging" hangIndent="6">
			<t hangText="- Option-ID (1 octet):">O-REQUEST</t>
			<t hangText="- 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.</t>
			<t hangText="- List of Option ID (variable length):">List of the Option that are expected for each NEIGHBOR Payload.</t>
		</list>
		</t>
	</section>


	<section title="Responder Options">

	
		<section title="Neighbor: NEIGHBOR" anchor="sec-neighbor">

		<t>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. </t>

		<figure>
		<artwork>
                        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
		</artwork>
		</figure>

		<t>
		<list style="hanging" hangIndent="6">
			<t hangText="- Option-ID (1 octet):">NEIGHBOR</t>
			<t hangText="- 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.</t>
			<t hangText="- List of Option Payload (variable length):">List of the Option Payload requested by the initiator.</t>
		</list>
		</t>
		</section>

			 
		<section title="Interface Option: O_INTERFACE">
	
		<t>The Interface Option provides the IP addresses of the Neighbor.</t>
		
		<figure>
		<artwork>
                        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                         ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 4: Interface Option: O_INTERFACE
		</artwork>
		</figure>

		<t>
		<list style="hanging" hangIndent="6">
			<t hangText="- Option-ID (1 octet):">O_INTERFACE</t>
			<t hangText="- 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.</t>
			<t hangText="- RESERVED (23 bits):">Set to Zero.</t>
			<t hangText="- 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.</t>
		</list>
		</t>
		</section>


		<section title="Geo-localization Option: O_GEOLOC">
		<t>The Geo-localization Option provides Geographic coordinates of the Neighbor.</t>

		<figure>
		<artwork>
                        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
		</artwork>
		</figure>

		<t>
		<list style="hanging" hangIndent="6">
			<t hangText="- Option-ID (1 octet):">O_GEOLOC</t>
			<t hangText="- 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.</t>
			<t hangText="- GEOLOC Data (variable length):">GEOLOC Data as defined in <xref target="RFC1876"/>.</t>
		</list>
		</t>
        </section>


		<section title="Intra-Security Gateway Bandwidth Option: O_ISG-BW">

		<t>The Intra-Security Gateway Bandwidth Option characterizes the link between the responder and the Neighbor.</t>

		<figure>
		<artwork>
                        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 
		</artwork>
		</figure>

		<t>
		<list style="hanging" hangIndent="6">
			<t hangText="- Option-ID (1 octet):">O_ISG-BW</t>
			<t hangText="- RESERVED (3 octets):">Set to Zero.</t>
			<t hangText="- Band Width Value (4 octets):">Specifies the bandwidth in octets per second.</t>
		</list>
		</t>
		</section>


		<section title="Intra-Security Gateway Mobility Support Option: O_ISG-MOB">

		<t>The Intra-Security Gateway Mobility Option defines if there are any mechanisms that support  VPN mobility from the responder to the Neighbor.</t>

		<figure>
		<artwork>
                        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
		</artwork>
		</figure>

		<t>
		<list style="hanging" hangIndent="6">
			<t hangText="- Option-ID (1 octet):">O_ISG-MOB</t>
			<t hangText="- Mobility Support (1 octet):">Specifies how VPN mobility is supported from the responder to the Neighbor.</t>
		</list>
		</t>

		<t>Currently the following values are provided for Mobility Support:
		<list style="hanging" hangIndent="6">
			<t hangText="- UNSUPPORTED_MOBILITY:">0</t>
			<t hangText="- IPSEC_CONTEXT_TRANSFERED:">1</t>
		</list>
		</t>
		</section>
	</section>

	<section title="General Options">

	<t>This section describes two options that can be used by both the initiator and the responder.</t>
	
		<section title="Padding Payload: PADDING" anchor="sec-o-padding">

		<t>The Padding Payload is used to make the NEIGHBOR_INFORMATION Notify Payload length  a multiple of 32 bits.</t>

		<figure>
		<artwork>
                        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
		</artwork>
		</figure>

		<t>
		<list style="hanging" hangIndent="6">
			<t hangText="- Option-ID (1 octet):">PADDING</t>
			<t hangText="- 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.</t>
			<t hangText="- Padding Octets (variable length):">These Octets are for padding and MUST NOT be interpreted.</t>
		</list>
		</t>
		</section>


		<section title="Maximum Neighbors Payload: MAX-NEIGHBOR" anchor="sec-o-max-neigh">

		<t>The Maximum Neighbors Payload sets the maximum number of Neighbor the VPN End User wants information about. This Option is of fixed size.</t>

		<figure>
		<artwork>
                        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
		</artwork>
		</figure>

		<t>
		<list style="hanging" hangIndent="6">
			<t hangText="- Option-ID (1 octet):">MAX-NEIGHBOR</t>
			<t hangText="- Maximum Number (1 octet):">Specifies the maximum number of NEIGHBOR Payload the response carries.</t>
		</list>
		</t>
		</section>
	</section>
    </section>

	
    <section title="IANA Considerations">
	
	<t>The new fields and number are the following:</t>

	<figure>
	<artwork>
    IKEv2 Notify Message Types - Status Types
    -----------------------------------------
    NEIGHBOR_INFORMATION
	</artwork>
	</figure>

	<figure>
	<artwork>
    Security Gateway Discovery Attributes
    -------------------------------------
    O-REQUEST 
    PADDING
    MAX-NEIGHBOR
    NEIGHBOR
	</artwork>
	</figure>

	<figure>
	<artwork>
    Neighbor Options
    ----------------
    O_INTERFACE
    O_GEOLOC
    O_ISG-BW
    O_ISG-MOB 
	</artwork>
	</figure>

	<figure>
	<artwork>
    O_ISG-MOB Attributes
    --------------------
    UNSUPPORTED_MOBILITY
    IPSEC_CONTEXT_TRANSFERED
	</artwork>
	</figure>
     
    </section>

	
    <section title="Security Considerations">

	<t>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.</t>
    </section>

	
    <section title="Acknowledgments">
    <t>TBD</t>
    </section>
	
  </middle>

  <back>
	<references title="Normative References">
        &rfc2119;
        &rfc4301;
        &rfc4555;
        &rfc5996;
    </references>
	
	
    <references title="Informative References">
        &rfc1876;
        &I-D.vandergaast-edns-client-ip;
    </references>
	
	
    <section title="Document Change Log">
      <t>[RFC Editor: This section is to be removed before publication]</t>

      <t>-00: First version published.</t>
    </section>
  </back>
</rfc>
