IPsecME Working Group Y. Mao INTERNET-DRAFT Z. Wang Intended Status: Proposed Standard Hangzhou H3C Tech. Co., Ltd. Expires: January 13, 2014 V. Manral HP July 14, 2013 Auto Discovery VPN Protocol draft-mao-ipsecme-ad-vpn-protocol-01 Abstract This document describes the Auto Discovery VPN (ADVPN) protocol, the use case and problem statement for which is described in [ADVPN_Problem]. The ADVPN protocol is used for enabling a large of number of entities to communicate directly among the peers, with minimal configuration and operator intervention. The solution uses IPsec[RFC4301] to protect communication between the peers. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Y. Mao Expires January 13, 2014 [Page 1] INTERNET DRAFT Auto Discovery VPN Protocol July 14, 2013 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. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 ADVPN Protocol Overview . . . . . . . . . . . . . . . . . . 3 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3 Conventions Used in This Document . . . . . . . . . . . . . 5 2. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 5 3. How ADVPN Works . . . . . . . . . . . . . . . . . . . . . . . 7 4. ADVPN protocol . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1 Client Information Registration . . . . . . . . . . . . . . 8 4.2 Client Information Resolution . . . . . . . . . . . . . . . 9 4.3 Private Network Information Management . . . . . . . . . . 10 4.4 Shortcut Decision . . . . . . . . . . . . . . . . . . . . . 11 4.5 Redirect protocol . . . . . . . . . . . . . . . . . . . . . 11 4.6 Keepalive protocol . . . . . . . . . . . . . . . . . . . . 12 4.7 Session Protocol . . . . . . . . . . . . . . . . . . . . . 12 5 ADVPN Message Formats . . . . . . . . . . . . . . . . . . . . . 13 5.1 ADVPN Fixed Header . . . . . . . . . . . . . . . . . . . . 13 5.2 Mandatory Part . . . . . . . . . . . . . . . . . . . . . . 15 5.2.1 Client Identification Header . . . . . . . . . . . . . 15 5.2.2 Session Header . . . . . . . . . . . . . . . . . . . . 16 5.3 Payload Part . . . . . . . . . . . . . . . . . . . . . . . 17 5.3.1 Client Information Payload . . . . . . . . . . . . . . 17 5.3.2 Destination Client Payload . . . . . . . . . . . . . . 19 5.3.3 Network Information Payload . . . . . . . . . . . . . . 20 5.3.4 Traffic Flow Payload . . . . . . . . . . . . . . . . . 21 5.3.5 Keepalive Parameter Payload . . . . . . . . . . . . . . 23 5.3.6 Redirect Payload . . . . . . . . . . . . . . . . . . . 23 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 25 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 25 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 25 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.1 Normative References . . . . . . . . . . . . . . . . . . . 25 8.2 Informative References . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Y. Mao Expires January 13, 2014 [Page 2] INTERNET DRAFT Auto Discovery VPN Protocol July 14, 2013 1 Introduction The large scale deployment of IPsec[RFC4301] leads to lots of difficulties, such as configuration for each tunnel, adding or removing IPsec peer, etc. all need a lot of configuration/ reconfiguration. Therefore, a protocol to establish IPsec tunnel dynamically without having the large overhead of configuration is needed. Auto Discovery VPN Problem Statement and Requirement [ADVPN_Problem] defines all requirements for the large scale IPsec deployment problem. This document defines the Auto Discovery VPN (ADVPN) protocol to satisfy these requirements. 1.1 ADVPN Protocol Overview The overall ADVPN solution has control plane and data plane elements. The ADVPN protocol operates in the control plane and uses the standard IPsec [RFC4301] for the data plane. The IPsec data plane establishes and protects all the traffic in the ADVPN network. The ADVPN protocol is a client and server protocol. The ADVPN Client(ADC) registers its information to the ADVPN Server(ADS). When the ADC wants to establish an IPsec tunnel with another ADC, the ADC requests and queries another ADC's information on the ADS. The ADVPN Client(ADC) is the forwarding device in the data plane. ADC implements IPsec to protect its own traffic or the traffic flowing through ADC. The ADVPN Server(ADS) is ADVPN information controller, which is responsible for collection, maintenance and distribution of ADVPN Client(ADC) information and the control policy. The client information is registered by the ADVPN client. The client information includes private IP address, public IP address and private network information etc. The control policy is used to decide the topology should be star topology or full mesh topology, and the control policy is pushed to hub ADC from ADS. Y. Mao Expires January 13, 2014 [Page 3] INTERNET DRAFT Auto Discovery VPN Protocol July 14, 2013 +------------------------------------------------------------------+ | | | | | +-----------+ | | +-------------- | ADS |--------------------+ | | | +-----------+ | | | | | | | | | | | | | | REG/RESO/SHORTCUT FLOW | | | | PROTOCOL | | | REG/RESO | REG/RESO | | PROTOCOL v PROTOCOL | | | +------------+ | | | | +---------- | ADC(Hub) | -----------+ | | | | | +------------+ | | | | | | | | | | | SESSION/REDIRECT SESSION/REDIRECT | | | | PROTOCOL PROTOCOL | | | | | | | | | | | | | | | v v v v | | +--------------+ SESSION PROTOCOL +--------------+ | | | ADC(Spoke) | <------------------------> | ADC(Spoke) | | | +--------------+ +--------------+ | | | | | +------------------------------------------------------------------+ Figure 1. ADVPN Protocol Model In this diagram, ADVPN protocol is implemented between ADC and ADS. All the ADCs register information on the ADS. When the ADC tries to build a direct IPsec tunnel with another ADC, it sends the Resolution message to ADS to query the information. In addition, to allow the shortcut path establishment between the ADCs, the ADS sends the Shortcut Traffic Flow message to the hub ADCs. Which ADC is hub ADC SHOULD be specified in the ADS by administrator. ADVPN protocol can also be implemented between ADC and ADC. The ADC sends the Session message to another ADC to transfer ADC information; otherwise the other ADC has to query the ADS if there is a reverse traffic, which may not be practical in some cases. The hub ADC sends Redirect message to spoke ADC to trigger the spoke ADC send Resolution message to ADS. With ADVPN protocol, the IPsec gateways and endpoints can obtain the IPsec peer's remote address from ADS. Therefore, establishing IPsec tunnel between them can scale well. Y. Mao Expires January 13, 2014 [Page 4] INTERNET DRAFT Auto Discovery VPN Protocol July 14, 2013 1.2 Terminology Most terminology has been specified in the [ADVPN_Problem]. However, there are also some additional terminology in this document needs to be clarified. ADVPN Server - This is an entity as ADVPN network controller. It maintains ADVPN client information database. It also can decide whether the spoke can directly communicate with the other spoke. ADVPN Client - This is an entity as ADVPN peer. It registers its information to ADVPN server. Hub ADC - This ADC is hub in the forwarding path. Spoke ADC - This ADC is spoke in the forwarding path. Private IP Address - Each ADVPN client has a logical private IP address. This address is static and as identity of ADVPN client. Through the private IP address, the Public IP address is discovered. Public IP Address - This is IPsec peer address. This address can be dynamic and attached with Private IP Address. There is private IP address to public IP address mapping. Private Network Information - This information includes the network behind the spoke and the next hop which is private IP address. Shortcut Path - This is direct connectivity between spoke and spoke. ADVPN Network - This is network composed of ADVPN peers Source ADVPN Peer - This ADVPN peer is the initiator to establish IPsec tunnel. Destination ADVPN Peer - This ADVPN peer is the responder to establish IPsec tunnel. 1.3 Conventions Used in This Document 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 RFC 2119 [RFC2119]. 2. Design Overview In the ADVPN network, there are thousands of ADVPN peers. It is difficult to pre-configure the SPD and PAD for each ADVPN peer Y. Mao Expires January 13, 2014 [Page 5] INTERNET DRAFT Auto Discovery VPN Protocol July 14, 2013 manually. In the use cases in the [ADVPN_Problem], the endpoints and gateways can use a dynamic IP address, it is impossible to specify the IP address towards this ADVPN peer in the remote ADVPN peer. Therefore, the design goal of ADVPN protocol described in this document is each ADVPN peer only configures its own SPD and PAD. If the ADVPN peer tries to setup an IPsec tunnel with another ADVPN peer, it queries the ADS and obtains the client information of another peer. To discover the remote ADVPN peer, a private IP address is used as the search key. The search key is private IP address. The private IP address is logical Virtual Private Network (VPN) IP address. Although IPsec peer address is dynamic, the private IP address is static. The private IP address is also next hop towards the network behind the ADVPN peer. When the traffic flows through the source ADVPN peer, routing table is looked up, the next hop is the private IP address of destination ADVPN peer. The source ADVPN peer looks up session table to find the public IP address of destination ADVPN peer. Session table is the ADC information cache in the forwarding path, and it has the private IP address to public IP address mapping. The private IP address with the private network information SHOULD be transferred via routing protocol (e.g. OSPF, BGP or RIP) or another means in the ADVPN network. A routing protocol can run over the IPsec tunnel between the ADCs and ADS. The routing protocol helps distribute routing information to all ADC's towards about the destination network behind the ADCs. After a spoke ADC finishes the registration on ADS, this ADC also obtains the information of hub ADC from ADS. An IPsec tunnel is then established automatically between the spoke ADC and hub ADC. The routing protocol messages are protected and transferred in this IPsec tunnel and exchanged between the spoke ADC and hub ADC. In the full mesh ADVPN network, there are tens of thousands of ADVPN peers. The spokes cannot be populated with a full routing table due to constraints on the device capabilities; therefore the network is left as a hub-and-spoke network initially. After routing information exchanges between the hub and spokes, routing table in the source ADVPN peer has the private IP address of hub ADVPN peer as the next hop to networks behind the destination ADVPN peer. Therefore, the traffic from source ADVPN peer to destination ADVPN peer is forwarded to hub first. In order to have direct connectivity between the ADVPN peers, the ADVPN peer queries the direct route information on ADS. The spoke ADC SHOULD register its private IP address and network behind the ADC to the ADS. The private IP address is the next hop to network behind the Y. Mao Expires January 13, 2014 [Page 6] INTERNET DRAFT Auto Discovery VPN Protocol July 14, 2013 ADC. When the traffic is transferred through hub, the hub sends a redirect message to source ADVPN peer. When the source ADVPN peer receiving Redirect message, it send a Resolution message to ADS to query the direct route information and ADC information for the destination ADVPN peer. Receiving the resolution reply message, the source ADVPN peer adds a direct route in the route table and setup a direct IPsec tunnel with the destination ADVPN peer. The hub decides whether the spoke can be allowed to have a direct communication with other spoke. The decision depends on the control policy pushed by the ADS after the hub ADC finishes registration in the ADS. The control policy is flow information. If the traffic matches the flow information, the hub sends a redirect message to source ADVPN peer to find a shortcut path to destination ADVPN peer. 3. How ADVPN Works In the ADVPN solution, ADVPN protocol uses the IPsec protocol [RFC4301] data plane, as well as routing protocols to fulfill the ADVPN function. This section describes the process to establish a shortcut spoke-to-spoke IPsec tunnel in a mesh topology. 1. When the ADC device comes up, it registers its information to ADS. The information includes the private IP address, the public IP address and the network behind the ADC. 2. The ADS sends the registration reply message to the ADC. The spoke ADC obtains the information of hub ADC. The ADC creates the hub session in the session table. After that, the spoke ADC establishes an IPsec tunnel with hub ADC. 3. The ADS sends Shortcut Flow message to hub ADC in order to determine whether sending redirect message or not. 4. The spoke ADC send a Session Setup message to hub ADC protected by IPsec tunnel, the hub ADC has the spoke ADC's information. 5. All the route protocol packets run over IPsec tunnel between the spoke ADC and hub ADC. The route protocol packet is copied and sent to hub ADC. The ADVPN network has spoke-hub topology. 6. When the traffic towards destination ADVPN peer arrives in the source ADVPN peer device, from the routing table, the next hop is the private IP address of hub ADVPN peer. Match the private IP address in the session table to obtain the public IP address of hub ADVPN peer. By the public IP address, the spoke-to-hub IPsec SA is chosen to encapsulate the traffic. Y. Mao Expires January 13, 2014 [Page 7] INTERNET DRAFT Auto Discovery VPN Protocol July 14, 2013 7. The traffic arrives in the hub, after processing IPsec packet, the hub looks up routing table to determine if incoming and outgoing interface is in the same ADVPN network. If it is, this traffic is transferred through hub towards the destination spoke and there is shortcut path between them. If the traffic matches the Shortcut Flow table, the hub send a redirect message to source ADVPN peer. 8. The source ADVPN peer receives the redirect message, it sends Resolution Request message with destination IP address to ADS. ADS lookes in the ADC information database to find out the next hop to the destination IP address and related network information. The ADS sends a Resolution Response message to the source ADVPN peer. 9. The source ADVPN peer receives the Resolution Response message. Firstly, a route towards destination network is added into the route table. Secondly, the source ADVPN peer establishes an IPsec tunnel with the destination ADVPN peer. Lastly, the source ADVPN peer send a session message to destination ADVPN peer. The destination ADVPN peer can add the reverse route in its route table and the ADC information in session table. 4. ADVPN protocol ADVPN protocol listens and sends on UDP port 2013(pending assignment by IANA). Since the UDP is a datagram(unreliable) protocol, all messages in ADVPN exist in pairs: a request and a response. In the following descriptions, the payloads contained in the message are indicated by names as listed below. Notation Description ----------------------------------------- HDR ADVPN header CIDHdr Client Identification Header SessHdr Session Header CI Client Information payload DC Destination Client Payload NI Network Information Payload TF Traffic Flow Payload KP Keepalive Parameter Payload Red Redirect Payload The details of the contents of each header and payload are described in section 5. Payloads that may optionally appear will be shown in brackets, such as [CI]; this indicates that a Client Information payload can optionally be included. 4.1 Client Information Registration Y. Mao Expires January 13, 2014 [Page 8] INTERNET DRAFT Auto Discovery VPN Protocol July 14, 2013 The ADC sends a Registration Request message to ADS to register its ADVPN information. The ADVPN information is contained in the message using CI payload and NI payload. When receiving the Registration Request message, ADS adds this ADVPN client information to ADC information database and sends a Registration Request Response message to the ADC. The Registration Request Response message includes KP payload, which make ADC send a keepalive message to ADS periodically after registration. If the hub ADC has been registered in the ADS, CI payload SHOULD be also contained with hub's ADC information. The registration messages with payloads are as follows: Client Server ------------------------------------------------------ HDR, CIDHdr, CI, [NI] --> <-- HDR, CIDHdr, KP, [CI] When the hub ADC is registered, a Hub Information message with CI payload should be sent to all the ADCs in the registration status. The hub Information Acknowledgement message has no payload, only contains ADVPN header and Client Identification Header. The hub messages with payloads are as follows: Client Server ------------------------------------------------------ <-- HDR, CIDHdr, CI HDR, CIDHdr --> 4.2 Client Information Resolution There are two scenarios that the ADC needs to send Resolution Request message to ADS to query the client information. 1. During the packet processing in the forwarding path, the session table is consulted with private IP address, If there is no session, the spoke ADC sends a Resolution Request message to ADS to get the remote ADC's information related with the private IP address. Before a Resolution Request Response comes, the data packets are forwarded to hub. Note that a Resolution Request message for the private IP address MUST NOT be triggered by every packet. 2. The spoke ADC received a Redirect message from the hub ADC, the spoke ADC sends a Resolution Request to ADS to get the remote ADC's information with the destination address. The Resolution Request message includes DC payload. If the next hop address and destination address both are contained in the payload, the ADS should loop up ADC information database with destination address firstly. Y. Mao Expires January 13, 2014 [Page 9] INTERNET DRAFT Auto Discovery VPN Protocol July 14, 2013 When the ADS receives a Resolution Request packet, it searches the ADC information database by private IP address or destination address. If an ADC is found, a Resolution Response message containing CI payload and NI payload is send to the spoke ADC. If there is no match, the error code is set in the header and no payload is included in the response message. The resolution messages with payloads are as follows: Client Server ------------------------------------------------------ HDR, CIDHdr, DC --> <-- HDR, CIDHdr, [CI], [NI] After receiving the remote ADC's information, the ADC create session cache based on the information in the CI payload. If there is NI payload, the route towards the destination address is added in the route table. 4.3 Private Network Information Management To help the ADC find a shortcut path, the private network information database is collected and distributed by the ADS. The private network information is like a private network route table. The ADC can query the next hop towards the private network. In the Registration Request message, the private network information can include in the NI payload and registered to ADS. After registration on the ADS, if the ADC's network information is changed(e.g. add, delete or modify), a Network Information Registration packet including the NI payload is send to the ADS to update the private network information database. After updating, a Network Information Registration Response is send back to the ADC, the response message has no payload, only contains ADVPN header and Client Identification Header. If the private network information is updated on ADS, a Network Information Update message containing the NI payload MUST be send to all ADCs in order to these ADCs have the correct route in their route table. All the ADC MUST send back a Network Information Update Response message to ADS, the response message has no payload, only contains ADVPN header and Client Identification Header. The private network information can also be transferred in the Session Setup message. In the session establish process, the private network route can be added in the remote ADC's route table in order to avoid ADS query for reverse traffic. Y. Mao Expires January 13, 2014 [Page 10] INTERNET DRAFT Auto Discovery VPN Protocol July 14, 2013 If receiving a Session Delete message from remote ADC, the ADC MUST tear down the session and clear the route added by the Session Setup message. 4.4 Shortcut Decision Whether the shortcut path can be established depends on the control policy in the ADS. The ADS defines the flow information to allow the direct connectivity. After the hub ADC finishes the registration, the ADS send the Shortcut Flow message contains TF payload to hub ADC. After receiving the message and add the flow information to shortcut flow table, the hub ADC send back Shortcut Flow Acknowledgement message to ADS. The hub ADC has a shortcut flow table to match the traffic through hub in the ADVPN network. If there is a match, the hub ADC send a Redirect message to source ADVPN peer. If the control policy is changed(e.g. add, delete or modify) on the ADS, the ADS MUST send a Shortcut Flow message to the hub ADC to update the shortcut flow table. If the shortcut flow item is deleted, the hub ADC send a Redirect message to source ADVPN peer to tear down the direct IPsec Tunnel. 4.5 Redirect protocol The hub ADC sends a Redirect message to spoke ADC means there is another path for traffic forwarding. In the hub ADC, when the traffic matches the shortcut flow table, a Redirect message containing the Red payload is sent to spoke ADC. The spoke ADC receives the Redirect message, sends a Redirect Response message to hub ADC and subsequently sends a Resolution message to ADS to query the shortcut information. The Redirect Response message has no payload, only contains ADVPN header and Session Header. The redirect messages with payloads are as follows: Hub Client Spoke Client ------------------------------------------------------ HDR, SessHdr, Red --> <-- HDR, SessHdr If a shortcut flow is deleted in the hub ADC, the hub ADC send a Redirect message to the ADCs which has received the Redirect message to trigger the shortcut resolution before. When receiving this Redirect message, the spoke ADC deletes the route related with the flow information. The shortcut IPsec tunnel is cleared up and the Y. Mao Expires January 13, 2014 [Page 11] INTERNET DRAFT Auto Discovery VPN Protocol July 14, 2013 traffic goes through the hub to transfer. 4.6 Keepalive protocol After the ADC finishes registration on the ADS, the ADC SHOULD send a Keepalive Request message to ADS to prove its liveness. The Keepalive Request message contains the ADVPN header and Client Identification Header. The number of retries and length of timeouts depend on the keepalive parameter pushed from ADS by the Registration Response message. If the number of retry attempts is reached but the ADC does not receive Keepalive Response message, the connection between ADC and ADS is considered broken. The ADC clears up all the resources and registered to ADS again. On ADS, receipt of any ADVPN message from ADC can prove the ADC's liveness. If the timeout is reached while the ADS does not receive Registration Response message, the ADS will clear all ADC information from ADC information database. If the ADC is hub, the ADS sends the Hub Information message to all the ADCs to notify the hub removing. 4.7 Session Protocol Session table is an remote ADC information cache in the forwarding path. It is composed of private IP address, public IP address, and the index of IPsec SA. In the forwarding process, the session table MUST be consulted with private IP address. Each session matches to only one IPsec SA. The function of session protocol is to facilitate the forwarding process, the session information transported to the remote peer avoids to query the ADS when reverse traffic flows. There are two type sessions: permanent session established with hub, and dynamic session established between spokes. The permanent session is static and established after the spoke ADC and hub ADC finish registration. The dynamic session will be deleted if there is no traffic between spokes, The permanent session is established between the spoke and hub or between the hubs. After receiving the Hub's ADC information from ADS by Registration Response message or Hub Information message, the spoke establishes an IPsec Tunnel with Hub firstly and then sends a Session Setup message to the hub, which is protected via IPsec tunnel. When receiving the Session Setup message, the hub ADC create a session for spoke ADC with the spoke's ADC information, and a Session Setup Response message will be send back to the spoke ADC. When the spoke ADC receives the Resolution Response message for Y. Mao Expires January 13, 2014 [Page 12] INTERNET DRAFT Auto Discovery VPN Protocol July 14, 2013 shortcut path and obtains the remote spoke ADC's information, the spoke creates a IPsec tunnel with the remote spoke. After that, the spoke sends a Session Setup message to the remote spoke. The remote spoke creates a session information towards the spoke and sends back a Session Setup Response message. If there is private network information in the source spoke, a NI payload SHOULD be contained in the Session Setup message. The Session Setup Response message has no payload, only contains ADVPN header and Session Header. The session messages with payloads are as follows: Client Client ------------------------------------------------------ HDR, SessHdr, [NI] --> <-- HDR, SessHdr If there is no traffic in the spoke-to-spoke session, the spoke will send a Session Delete message to the remote spoke to remove the session item. After the session is removed, the IPsec tunnel is also cleared up. 5 ADVPN Message Formats This section describes the format of ADVPN message. ADVPN messages begin immediately following the UDP header. An ADVPN message is composed of a Fixed Part, a Mandatory Part and a Payload Part. The Fixed Part is common to all ADVPN message types. The Mandatory Part MUST be present, but varies depending on message type. The Payload Part also varies depending on message type. The length of the Fixed Part is fixed at 12 octets. The length of the Mandatory Part is determined on message type. The Payload Part length depends on the payload type. 5.1 ADVPN Fixed Header The Fixed Part of the ADVPN message contains those elements of the ADVPN message which are always present and do not vary in size with the type of message. Y. Mao Expires January 13, 2014 [Page 13] INTERNET DRAFT Auto Discovery VPN Protocol July 14, 2013 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ErrCode | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. ADVPN Header Format o Version (1 octet) -- Indicates the version of the ADVPN protocol in use. Implementations based on this version of ADVPN MUST set the version to 0. o Type (1 octet) -- Indicates the type of ADVPN message being used. Message Type Value ------------------------------------------------------------ Registration Request 1 Registration Response 2 Resolution Request 3 Resolution Response 4 Delete Request 5 Delete Response 6 Keepalive Request 7 Keepalive Response 8 Network Information Registration 9 Network Information Response 10 Shortcut Flow 11 Shortcut Flow Acknowledgement 12 Hub Information 13 Hub Information Acknowledgement 14 Redirect 15 Redirect Acknowledgements 16 Session Setup Request 17 Session Setup Response 18 Session Keepalive Request 19 Session Keepalive Response 20 Session Delete Request 21 Session Delete Response 22 Session Network Information Request 23 Session Network Information Response 24 o Length (2 octet) -- Length of total message beginning with the Version element in octets. Y. Mao Expires January 13, 2014 [Page 14] INTERNET DRAFT Auto Discovery VPN Protocol July 14, 2013 o Message ID (4 octet) -- Used to provide a unique identifier for the information contained in a Request message. This value is copied directly from a Request message into the Response message. When a sender receives the Response packet, it will match the Message ID with the Request packet of local sent. When a match is found then the Request is considered to be acknowledged. The value is incremented each time a new Request message is sent. The same value MUST be used when resending a Request message. It is RECOMMENDED that the initial value for this number be 0. o ErrCode (2 octet) -- An error code indicating the type of error detected, chosen from the follow list: Error description Code ------------------------------- ------- No ADC Found 1 Management Reject 2 Insufficient Resources 3 o Reserved (2 octet) -- MUST be zero. 5.2 Mandatory Part Different Mandatory Part of the ADVPN message exists in different message types, and is behind the ADVPN Header. 5.2.1 Client Identification Header The Client Identification Header, denoted CIhdr in this document, is contained in the messages that are sent and received between ADC an ADS. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Type | Flags | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client Private Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. Client Identification Header Format o Address Type (1 octet) -- Identifies the address type of the client private Address. Y. Mao Expires January 13, 2014 [Page 15] INTERNET DRAFT Auto Discovery VPN Protocol July 14, 2013 Address Type Value --------------------------- ------- IPv4 Address 1 IPv6 Address 2 o Flags (1 octet) -- The flags field is coded as follows: 0 1 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Unused |H| +-+-+-+-+-+-+-+-+ H-bit - The Hub bit. When set to 1, the Client is Hub, otherwise it is spoke. o Length (2 octet) -- Length in octets of the current mandatory part. o Client Private Address (variable length) -- The ADC's logical private IP address. The value for this field is specified by the IP version field. If the message is sent from ADC to ADS, this address is private IP address of ADC. If the message is sent from ADS to ADC, this address is private IP address of destination ADC. 5.2.2 Session Header The Session Header, denoted Sesshdr in this document, is contained in the messages that are sent and received between ADCs. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Role ID | Address Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4. Session Header Format o Role ID (1 octet) -- Identifies the forwarding role of the ADC. 1 - Hub. 2 - Spoke. o Address Type (2 octet) -- Identifies the type of Source and Y. Mao Expires January 13, 2014 [Page 16] INTERNET DRAFT Auto Discovery VPN Protocol July 14, 2013 Destination IP Address type. o Length (2 octet) -- Length in octets of the current mandatory part. o Source IP Address (variable length) -- Identifies the sender's logical private IP address. The address type is specified by the Address Type field. o Destination IP Address (variable length) -- Identifies the receiver's logical private IP address. The address type is specified by the Address Type field. 5.3 Payload Part Each payload defined in the section 5.3.1 through 5.3.6 has the general payload TLV(Type, Length, Value) format. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5. Payload TLV Format The TLV fields are defined as follows: o Type (2 octet) -- The type of this payload. Payload Type Value ------------------------------- ------- Client Information payload (CI) 1 Destination Client Payload (DC) 2 Network Information Payload (NI) 3 Traffic Flow Payload (TF) 4 Keepalive Parameter Payload (KP) 5 Redirect Payload (Red) 6 o Length (2 octet) -- Length in octets of the current payload, including the type and length. o Value (variable octet) -- The value of this payload. Each payload has different content. 5.3.1 Client Information Payload Y. Mao Expires January 13, 2014 [Page 17] INTERNET DRAFT Auto Discovery VPN Protocol July 14, 2013 The Client Information Payload, denoted CI in this document, is used to be as part of Registration message to notify the ADS of ADC's information, or as part of Resolution Response message to notify the ADC of the remote ADC's information. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Holding Time | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preference | Node Flags | Pub Addr Type | Pri Addr Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Public Address(variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Private Address(variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6. Client Information Payload Format o Holding Time (2 octet) -- Identifies the expire time(seconds) of the ADC's information obtained from ADS. The ADS SHOULD ignores this field when receiving the Registration Request message. o Reserved (2 octet) -- MUST be sent as zero; MUST be ignored on receipt. o Preference (1 octet) -- Identifies the ADC's preference. Higher values in the range 1 to 255 indicates higher preference. A zero value indicates no preference. o Node Flags (1 octet) -- The flags field is coded as follows: 0 1 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Unused |N|H| +-+-+-+-+-+-+-+-+ H-bit - The hub bit. When set to 1, this current ADC is a hub, otherwise a spoke. N-bit - The NAT bit. When set to 1, it indicates the ADC is behind the NAT. o Pub Addr Type (1 octet) -- Identifies the ADC's Public Address type. 1 -- IPv4 Y. Mao Expires January 13, 2014 [Page 18] INTERNET DRAFT Auto Discovery VPN Protocol July 14, 2013 2 -- IPv6 o Pri Addr Type (1 octet) -- Identifies the ADC's Private Address type. 1 -- IPv4 2 -- IPv6 o Public Address (variable length) -- Identifies the ADC's IPsec peer address. The type of address for this field is specified by the Pub Addr Type field. o Private Address (variable length) -- Identifies the ADC's logical private IP address. The values for this field is specified by the Pri Addr Type field. 5.3.2 Destination Client Payload The Destination Client Payload, denoted DC in this document, is used to be search key to discover the remote ADC's information. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Address Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address(variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Private Address(variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7. Destination Client Payload Format o Address Type (1 octet) -- Identifies the type of destination address and next hop address. 1 -- IPv4 2 -- IPv6 o Reserved (3 octet) -- MUST be zero. o Destination IP Address (variable length) -- Identifies the destination IP address of communication. The value for this field is specified by the Address Type field. Y. Mao Expires January 13, 2014 [Page 19] INTERNET DRAFT Auto Discovery VPN Protocol July 14, 2013 o Private Address (variable length) -- Identifies the next hop address to the destination network. The value for this field is specified by the Address Type field. 5.3.3 Network Information Payload The Network Information Payload, denoted NI in this document, is used to carry private network information. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network # | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8. Network Information Payload Format o Network # (2 octet) -- Identifies the number of network this message contains. o Reserved (2 octet) -- MUST be zero. Each network has the following formats: 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Operation | Preference | Address Type | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Hop Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9. Network Format o Operation (1 octet) -- Indicates the operation for the current network. 0 - Reserved. 1 - Add. 2 - Delete. Y. Mao Expires January 13, 2014 [Page 20] INTERNET DRAFT Auto Discovery VPN Protocol July 14, 2013 3 - Update. o Preference (1 octet) -- Indicates the priority of network. o Address Type (1 octet) -- Indicates the Address type of network address and next hop address. 1 - IPv4 Address. 2 - IPv6 Address. o Prefix Length (1 octet) -- Is the octet length of the routing prefix. o Network Address (variable length) -- Identifies the address of the ADC's private network. The value for this field is specified by the Address Type field. o Next Hop Address(variable length) -- Identifies the next hop to the Network Address in the routing path. The Next Hop is also the ADC's private IP address. The value for this field is specified by the Address Type field. 5.3.4 Traffic Flow Payload The Traffic Flow Payload is denoted TF in this document. This payload contains the data flow information. Y. Mao Expires January 13, 2014 [Page 21] INTERNET DRAFT Auto Discovery VPN Protocol July 14, 2013 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flow Sequence Number | Flow Type | Flow Action | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Protocol | IP Protocol | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Starting Source Port | Ending Source Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Starting Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ending Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Starting Destination Port | Ending Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Starting Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ending Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10. Shortcut Flow Payload Format o Flow Sequence Number (2 octet) -- Identifies the preference of the data flow. Lower values (in the range 0 to 65534) indicates higher preference. o Flow Type (1 octet) -- Identifies the traffic flow type. 1 - Shortcut Data Flow. o Flow Action (1 octet) -- Identifies which action will to do when matching this flow. 1 - Permit. The packet which matching the flow will trigger the specified function, such as redirection. 2 - Deny. The packet which matching the flow will not trigger any function. 3 - Discard. The packet which matching the flow will be discarded. o Addr Type (1 octet) -- Identifies which the data flow address type is, IPv4 or IPv6. 1 - IPv4 Address. 2 - IPv6 Address. Y. Mao Expires January 13, 2014 [Page 22] INTERNET DRAFT Auto Discovery VPN Protocol July 14, 2013 o IP Protocol (1 octet) -- Identifies IP protocol of this data flow, such as UDP, TCP or ICMP etc. o Reserved (2 octet) -- MUST be zero. o Starting Source Port (2 octet) -- Value specifying the smallest source port number allowed. o Ending Source Port (2 octet) -- Value specifying the largest source port number allowed. o Starting Source Address (2 octet) -- The smallest source address. o Ending Source Address (2 octet) -- The largest source address. o Starting Destination Port (2 octet) -- Value specifying the smallest destination port number allowed. o Ending Destination Port (2 octet) -- Value specifying the largest destination port number allowed. o Starting Destination Address (2 octet) -- The smallest destination address. o Ending Destination Address (2 octet) -- The largest destination address. 5.3.5 Keepalive Parameter Payload The Keepalive Parameter Payload is denoted KP in this document. This payload contains the parameter to sending keepalive message. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interval | Retries | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11. Keepalive Parameter Payload Format o Interval (2 octet) -- Identifies the timeout(seconds) of sending a Keepalive Request again. o Retries (2 octet) -- Identifies the number of retry attempts. 5.3.6 Redirect Payload Y. Mao Expires January 13, 2014 [Page 23] INTERNET DRAFT Auto Discovery VPN Protocol July 14, 2013 The Redirect Payload is denoted Red in this document. This payload contains the original packet information. The original packet is used for the spoke to send a Resolution Request packet to the ADS to get the peer's ADVPN information. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | As much of invoking packet as possible | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12. Redirect Payload Format Y. Mao Expires January 13, 2014 [Page 24] INTERNET DRAFT Auto Discovery VPN Protocol July 14, 2013 5 Security Considerations The ADVPN protocol has no protocol-internal security mechanism, it relies on other security protocol to protect the ADVPN messages. The messages between the ADC and ADS can be protected by the IPsec or SSL/TLS. The messages between ADCs is protected by IPsec. It is highly recommended that the wildcard pre-shared-key in IKEv1 or IKEv2 is not used in the ADVPN, the attacker can access the ADVPN network if one ADVPN peer is compromised. 6 IANA Considerations IANA may need to allocate additional values for the options presented in this document. The values of the protocol field needed to be assigned from the numbering space. 7 Acknowledgments 8 References 8.1 Normative References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC1776] Crocker, S., "The Address is the Message", RFC 1776, April 1 1995. [TRUTHS] Callon, R., "The Twelve Networking Truths", RFC 1925, April 1 1996. [ADVPN_Problem] Hanna, S., "Auto Discovery VPN Problem Statement and Requirements", draft-ietf-ipsecme-p2p-vpn-problem-07.txt, June 2013. [IPSECARCH] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. 8.2 Informative References [NHRP] J. Luciani, "NBMA Next Hop Resolution Protocol (NHRP)", RFC2332, April 1998. [RFC5513] Farrel, A., "IANA Considerations for Three Letter Y. Mao Expires January 13, 2014 [Page 25] INTERNET DRAFT Auto Discovery VPN Protocol July 14, 2013 Acronyms", RFC 5513, April 1 2009. [RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April 1 2009. Authors' Addresses Yu Mao Hangzhou H3C Tech. Co., Ltd. Oriental Electronic Bld., No. 2 Chuangye Road Shang-Di Information Industry Hai-Dian District Beijing 100085 China EMail: yumao9@gmail.com ZhanQun Wang Hangzhou H3C Tech. Co., Ltd. Oriental Electronic Bld., No. 2 Chuangye Road Shang-Di Information Industry Hai-Dian District Beijing 100085 China EMail: wangzhanqun@h3c.com Vishwas Manral Hewlett-Packard Co. 19111 Pruneridge Ave. Cupertino, CA 95113 USA Email: vishwas.manral@hp.com Y. Mao Expires January 13, 2014 [Page 26]