IPSECME Working Group P. Sathyanarayan(Ed.)
Internet Draft S. Hanna
Intended status: Proposed Standard S. Melam
Expires: January 2014 Juniper Networks
Y. Nir
Check Point
D. Migault
Francetelecom - Orange
K. Pentikousis
Huawei Technologies
July 5, 2013
Auto Discovery VPN Protocol
draft-sathyanarayan-ipsecme-advpn-00
Abstract
This document defines a protocol for dynamically establishing and
tearing down IPsec tunnels as needed without requiring non-scalable
configuration.
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), 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/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 6, 2014.
Sathyanarayan Expires January 6, 2014 [Page 1]
Internet-Draft Auto Discovery VPNs July 2013
Copyright Notice
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.
Table of Contents
1. Introduction...................................................3
1.1. Conventions Used In This Document.........................4
1.2. Terminology...............................................4
2. Design Considerations..........................................5
3. Auto Discovery VPN Protocol....................................6
3.1. Prerequisites.............................................7
3.2. Shortcut Initiation.......................................7
3.3. Shortcut Termination......................................9
3.4. The SHORTCUT Notification................................10
3.4.1. IPv4 SHORTCUT Type..................................11
3.4.2. IPv6 SHORTCUT Type..................................14
3.4.3. DNS Name Shortcut Type..............................16
3.4.4. Response Shortcut Type..............................19
3.5. SHORTCUT Response Codes (RCODE)..........................21
3.5.1. SHORTCUT_SUCCEED....................................22
3.5.2. SHORTCUT_PARTNER_UNREACHABLE........................22
3.5.3. TEMPORARILY_DISABLING_SHORTCUT......................22
3.5.4. IKEv2_NEGOTIATION_FAILED............................23
3.5.5. UNMATCHED_SHORTCUT_SPD..............................23
3.5.6. UNMATCHED_SHORTCUT_PAD..............................24
4. IPsec Policy..................................................24
4.1. Security Policy Database (SPD)...........................24
4.2. Security Policy Database Cache (SPD Cache)...............25
4.3. Peer Authentication Database (PAD).......................26
5. Security Considerations.......................................26
6. IANA Considerations...........................................27
7. References....................................................28
7.1. Normative References.....................................28
7.2. Informative References...................................28
8. Acknowledgments...............................................29
Appendix A. ADVPN Example Use Cases..............................30
A.1. Branch Office Videoconference............................30
Sathyanarayan Expires January 6, 2014 [Page 2]
Internet-Draft Auto Discovery VPNs July 2013
A.2. Optimization for Videoconference with Partner............32
A.3. Heterogeneous Wireless Networks Traffic..................35
Appendix B. Comparison Against ADVPN Requirements................40
1. Introduction
IPsec [IPSECARCH] is currently being deployed in more diverse
network environments, which exhibit significantly larger numbers of
hosts than we have seen before. For example, IPsec is not only used
in remote office VPN scenarios but also to secure telecommunications
infrastructure is cellular networks as well as mobile device access
to corporate and other sensitive network resources. Large
deployments of IPsec may involve thousands of gateways and endpoints
with constantly changing traffic patterns. As a result, static IPsec
configuration based on presets is no longer deemed adequate. Users
expect to be able to connect remotely and securely without
compromising their communications quality of experience. To enable
efficient and secure traffic flow in such environments, we need to
be able to establish tunnels dynamically, as needed. In other words,
a more dynamic method of establishing and tearing down Security
Associations (SAs) [IPSECARCH] than what is currently possible with
current standards is desired. This is discussed in [ADVPNreq], where
it is shown that, for a variety of use cases, static configuration
does not scale for such a large system and that a standardized
solution is needed where equipment from different vendors may be
involved.
Motivated by the problem defined in [ADVPNreq], this document
proposes a protocol that can demonstratively scale in large IPsec
deployments while ensuring that routing stretch is minimized and
network resources are used more optimally. The proposed protocol
extends [IKEV2] to meet the requirements spelled out in [ADVPNreq],
providing a standard way to dynamically establish and tear down
IPsec tunnels as needed without requiring non-scalable
configuration. The protocol introduces the concept of a "shortcut"
which can be used by compliant IPsec gateways to optimize the
traffic path between two peers. The protocol has provisions for
adhering to established policies and is applicable to single- and
multi-domain environments. Shortcuts can be established and torn
dynamically and, as we show in the Appendix, the proposed solution
is applicable to a variety of use cases and scenarios, pertaining to
both wired and wireless networks.
The remainder of this document is organized as follows. Section 2
presents our design considerations and discusses the salient
Sathyanarayan Expires January 6, 2014 [Page 3]
Internet-Draft Auto Discovery VPNs July 2013
protocol characteristics we are after. Sections 3 and 4 specify the
Auto Discover VPN Protocol (ADVPN), while Section 5 examines the
implications of ADVPN on IPsec policy. Security considerations are
discussed in Section 6. This document includes two appendices:
Appendix A details several ADVPN use cases while Appendix B explains
how the proposed protocol meets the requirements set in [ADVPNreq].
1.1. 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
[MUSTSHOULD].
1.2. Terminology
This section defines the terms used throughout this document. The
terms introduced in [ADVPNreq] apply here as well. For reader
convenience, we repeat in particular the following terms:
Endpoint - A device that implements IPsec for its own traffic but
does not act as a gateway.
Gateway - A network device that implements IPsec to protect traffic
flowing through the device.
In addition this document defines the following terms:
Peer - A host (gateway or endpoint) with an IPsec Security
Association.
Shortcut - An IPsec Security Association established dynamically (at
the suggestion of a shortcut suggester).
SHORTCUT notification - An IKEv2 Notify payload that carries either
all data needed to establish the shortcut IPsec security
association or an informational payload.
Shortcut suggester - A peer that sends a SHORTCUT notification.
Shortcut partners - The pair of peers that received a SHORTCUT
notification suggesting that they should establish a shortcut.
Shortcut initiator - A peer directed by a SHORTCUT notification to
act as the IKEv2 initiator while establishing a shortcut.
Sathyanarayan Expires January 6, 2014 [Page 4]
Internet-Draft Auto Discovery VPNs July 2013
Shortcut responder - A peer directed by a SHORTCUT notification to
act as the IKEv2 responder while establishing a shortcut.
2. Design Considerations
The protocol described in this document aims at operational
environments with possibly tens of thousands or more peers. Peers
may belong to the same administrative domain, or to different
administrative domains with already established trust relationships.
In this kind of network environment one wants to minimize
configuration effort overall and, to the degree possible, eliminate
manual labor in administering route optimization. This may not only
result in better network resource utilization, but also in increased
network resilience as reliance on a few centrally-located gateways
is reduced. In addition, the automation introduced by the protocol
described herein enables administrators to optimize IPsec traffic
flows at time scales that are simply not possible with today's
tools. In general, the protocol should allow for self-optimization
as permitted by established domain policies.
Since IPsec traffic may originate or terminate behind NATs and other
policy-enforcing gateways, we aim for a protocol that can work well
in this environment. In addition, peers are not expected to be
stationary. Given the widespread deployment of wireless networks and
the proliferation of user devices with multiple interfaces it is
reasonable to anticipate that some can join the ADVPN from a range
of different access points and this is taken into account in our
protocol design.
A central aim of the protocol is to enable peers to setup IPsec
tunnels without the need for continuous manual configuration. In
addition, the establishment of new tunnels should not inadvertently
affect other peers, i.e. it should not call for manual configuration
elsewhere in the VPN. Moreover, the establishment of new IPsec
tunnels should be easily controlled and managed by the
administrator. When new tunnels are operational as well as when they
are terminated the administrator should be fully aware of it.
With these considerations in mind, we design a system that can
function purely on the basis of local optimizations and policies.
This foundation bestows the scaling properties to the Auto Discovery
VPN protocol, which is described in the following sections. In
short, each individual gateway is permitted to act as a shortcut
suggester, i.e. to recommend a "shortcut" to appropriate peers with
which it has previously established IPsec security associations.
Sathyanarayan Expires January 6, 2014 [Page 5]
Internet-Draft Auto Discovery VPNs July 2013
These peers, which we refer to as the shortcut partners, can accept,
reject or ignore this recommendation, according to their own
policies. If the partner(s) reject the recommendation, the partner
response indicates the reasons for the rejection, so the shortcut
suggester can properly optimize its VPN topology. In addition
responses may also carry informational data that may be handled by
the shortcut suggester in various ways.
It is important to highlight that the protocol introduced in this
document does not require peers to have a comprehensive
understanding of the global network topology. Each peer can act in
accordance with its own policy. Taken as a whole, this system will
eventually optimize the graph of IPsec Security Associations to
match the current traffic flow (subject to policy constraints) and
then continually reoptimize the IPsec tunnel graph as traffic flows
and policies change over time. Appendix A provides illustrative
examples of such a reoptimization.
3. Auto Discovery VPN Protocol
The Auto Discovery VPN protocol (ADVPN) enables an IPsec gateway to
suggest the establishment of a shortcut, i.e. an IPsec tunnel
between two of its peers. For example, the shortcut could be used to
establish a more optimal path for data delivery.
Whenever an IPsec gateway decides that a shortcut between two of its
peers would be beneficial, it sends a SHORTCUT notification to both
peers, including all information needed to establish the shortcut in
the notification. The peers MAY ignore or reject the notification
but they can also use the information contained in the notification
to attempt to establish a direct SA between them. We refer to these
peers as the shortcut partners and suggesting gateway as shortcut
suggester.
A shortcut MAY be torn down when it is no longer receiving adequate
traffic (as determined by the shortcut partners) or when the timeout
for the shortcut expires. Of course, the shortcut partners MAY
decide to explicitly terminate the shortcut at any time.
Note that this protocol works in an exemplary manner in typical hub-
and-spoke topologies but is also well-suited for other arbitrary
topologies. For example, consider the case of two endpoints
exchanging an adequate amount of traffic (as determined by the
shortcut suggester) and connected through a series of gateways, all
of which support the Auto Discovery VPN protocol. As detailed in
Sathyanarayan Expires January 6, 2014 [Page 6]
Internet-Draft Auto Discovery VPNs July 2013
Appendix A (Sections A.2. and A.3. , the protocol enables the step-
by-step optimization of the traffic flow between two endpoints
through the use of shortcut tunnels. The protocol effectively
enables direct and secure communication between the two endpoints
without any manual configuration involved in setting up the
respective tunnels.
3.1. Prerequisites
The Auto Discovery VPN protocol MUST only be used with IKEv2.
Before the Auto Discovery VPN protocol can be used, all participants
(i.e. the shortcut suggester and the shortcut partners) must
indicate support for this protocol by sending a Vendor ID payload
with a Vendor ID field containing exactly and only the 32-octet
ASCII string "e7abc8bb1b07c89640dccf2ee94b9cf6" (no NULL
termination, no quote characters). This value is the MD5 hash of the
string "draft-sathyanarayan-ipsecme-advpn-00.txt" (no NULL
termination, no quote characters). Any IKEv2 peer that sends this
Vendor ID payload is indicating that it supports the protocol
defined in this draft.
Shortcut partners and shortcut suggesters MUST NOT send any of the
messages defined in this draft unless the intended recipient of the
message has sent such a Vendor ID payload during the IKEv2 exchange.
Any party that supports this protocol will send this Vendor ID
payload in the first IKE_AUTH request sent in the IKE exchange.
However, it may delay sending this payload until later, for example,
if it has a policy that restricts the set of peers with which it is
willing to establish a shortcut.
EDITOR'S NOTE: The adopted Vendor ID approach to advertise
SHORTCUT capability is considered in this draft instead of
Notification payload, as this provides a way for ADVPN
protocol implementation, on how to interpret SHORTCUT
notification, based on version of this draft.
3.2. Shortcut Initiation
Once the use of the Auto Discovery VPN protocol is enabled, an IPsec
gateway can decide that two of its peers (which have indicated
support for the ADVPN protocol) should establish a direct IPsec
Security Association. The decision-making process for selecting the
Sathyanarayan Expires January 6, 2014 [Page 7]
Internet-Draft Auto Discovery VPNs July 2013
two peers is outside the scope of this document. As an illustrative
example, however, one could consider the observation of excessive
transit traffic load between said peers. Another reason could be the
realization that certain quality of service (QoS) requirements would
be better served through a shortcut. For instance, some of the
traffic between the two peers may be delay-sensitive and would
benefit from a more direct route. Alternatively, gateway-, policy-
and operation-related reasons, such as overload, scheduled
maintenance, energy-saving and so on, could also trigger the
initiation of a shortcut recommendation. The reasoning behind the
trigger that initiates a shortcut notification to selected peers is
beyond the scope of this document.
Once an IPsec gateway has decided that two peers should establish a
direct SA, it acts as a shortcut suggester and uses its IKEv2 SAs
with these peers to send a SHORTCUT notification to each of the
shortcut partners. Each SHORTCUT notification includes most or all
of the information needed to allow the shortcut partners to
establish their own SA, such as, the IP address and identity of the
other partner, an indication of which partner should be the IKEv2
initiator and which should be the responder, and even an optional
Pre-Shared Key, which makes it easy for the partners to authenticate
with each other.
The shortcut suggester MAY also include Traffic Selectors to
indicate which traffic should be sent over the shortcut. This allows
traffic for certain destinations to use the ADVPN shortcut while
traffic for other destinations continues to flow through the gateway
(i.e. the shortcut suggester). Further, it allows traffic destined
for certain port numbers (e.g. high-volume, delay-sensitive traffic
such as video conference) to use the shortcut, while other types of
traffic carrying, for example, sensitive information that ought to
be logged or analyzed will continue to go through the gateway.
The shortcut partners MAY decline to act on the SHORTCUT
notification. Although the decision to do so is outside the scope of
this document, one could consider, for example, that there may be
implementation-specific reasons for rejecting the shortcut
suggestion. For instance, the shortcut partners may be low on
resources or they may have recently tried to establish this shortcut
and failed. Another reason for not accepting the shortcut
recommendation could be that doing so violates local policy (e.g. if
the shortcut partner only accepts shortcuts within its
organization).
The shortcut partner(s) MAY ignore the SHORTCUT notification, but it
is RECOMMENDED that the shortcut partner provide a reason for such
Sathyanarayan Expires January 6, 2014 [Page 8]
Internet-Draft Auto Discovery VPNs July 2013
refusal to the shortcut suggester. A shortcut suggester SHOULD NOT
resend a SHORTCUT notification just because the shortcut partners
have not set up the requested shortcut tunnel. A SHORTCUT response
may carry a timeout value to indicate to the shortcut suggester that
it should not resend SHORTCUT notifications for a specified amount
of time. If the shortcut suggester does not become aware of the
reason for declining a SHORTCUT recommendation, it MAY resend the
SHORTCUT notification in regular intervals as per the local policy
configuration. If the shortcut suggester, resends the SHORTCUT
notification, and if this notification carries Pre-Shared-Key
payload, then the shortcut suggester SHOULD ensure that the Pre-
Shared-Key is not regenerated.
If the shortcut partner identified as the initiator in the SHORTCUT
notification decides to establish the shortcut suggested by the
notification, it will attempt to establish an IKEv2 exchange with
its designated shortcut partner (the "shortcut responder") and then
to establish an IPsec security association between the two. Once
this is established, the shortcut partners SHOULD send to the
shortcut suggester a SHORTCUT response, indicating that the shortcut
tunnel has been established. Details of how this is done are
specified in the descriptions of specific Shortcut Types in Section
3.4.
If the shortcut partners are able to establish an IPsec security
association, they use the Traffic Selectors for this SA to determine
which traffic should be sent through this tunnel. Shortcut partners
MUST ensure that the Traffic Selectors negotiated for the shortcut
tunnel are a subset of the Traffic Selectors they have in place for
their SA with the shortcut suggester. Since there may be an overlap
between the Traffic Selectors for the shortcut SA and for the SA
with the shortcut suggester, preference SHOULD be given in this case
to sending traffic over the shortcut SA.
3.3. Shortcut Termination
After establishing an IPsec Security Association triggered by a
SHORTCUT notification (described in the following subsection),
either of the shortcut partners may decide to terminate the
shortcut. This may occur at any point of time and for a variety of
reasons (outside the scope of this document), such as, for example,
due to lack of traffic using the shortcut, local policy, shortage of
resources, or other reasons. However, the shortcut SA SHOULD NOT be
terminated simply because the SA with the shortcut suggester was
terminated due to inactivity. On the contrary, dropping the SA with
Sathyanarayan Expires January 6, 2014 [Page 9]
Internet-Draft Auto Discovery VPNs July 2013
the shortcut suggester while maintaining the shortcut SA may be
quite a normal occurrence if the only traffic flowing through the
shortcut suggester has now been diverted into the shortcut.
Either shortcut partner may terminate a shortcut by closing the
corresponding IKE SA (and therefore all child IPsec SAs) by sending
an IKEv2 Delete payload to the other shortcut partner, thus
indicating that the IKE SA should be deleted.
3.4. The SHORTCUT Notification
The Notify Message Type for the SHORTCUT Notify Payload is 47832.
This is a Private Use value of Status type. Therefore, any IKEv2
peer that receives a SHORTCUT notification but does not recognize or
support this message type will simply ignore this notification
(Critical bit is not set).
EDITOR'S NOTE: At this stage, the SHORTCUT notification is a
Private Use value. Therefore, it should be used only for
experimental purposes within private networks. Eventually, the
intent is to use a Notify Message Type of Status type from the
range that requires Expert Review. However, it is best to
stick with a Private Use value for now because this
specification is still actively developed.
Depending on the shortcut type, each SHORTCUT notification carries
either all data needed to establish the shortcut IPsec security
association or an informational payload. To ensure extensibility and
flexibility, the first two octets of the notification data form a
Shortcut Type. The format and meaning of the rest of the
notification data (marked as Shortcut Data in Figure 1 below) is
determined by the value in the Shortcut Type field.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Shortcut Type ! Shortcut Notify Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++++++++++++++++++++++++++++!
~ Shortcut Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: SHORTCUT Notification Data
The Shortcut Type field identifies which type of shortcut type this
notification relates to. As noted above, several different types of
Sathyanarayan Expires January 6, 2014 [Page 10]
Internet-Draft Auto Discovery VPNs July 2013
shortcuts are permitted. An IANA Registry for Shortcut Types will be
created; see also Section 6. The initial set of Shortcut Types is as
follows:
Value Description
----- -----------
0 IPv4 Shortcut
1 IPv6 Shortcut
2 DNS Name Shortcut
3 Response Shortcut
4-39999 Unassigned
40000-65535 Private Use
The Shortcut Notify Length indicates the length of the SHORTCUT
notification payload.
The Shortcut Data (i.e. the rest of the notification data after the
Shortcut Type) includes the content necessary to establish the
shortcut or indicate a response. The format, meaning, and length of
the data in the Shortcut Data field may vary, depending on the
Shortcut Type value.
If a peer receives a SHORTCUT notification with a Shortcut Type
value that is not recognized or not supported by that peer, the peer
MUST ignore the SHORTCUT notification.
3.4.1. IPv4 SHORTCUT Type
When the IPv4 Shortcut Type is sent, the Shortcut Data field has the
format illustrated in Figure 2.
Sathyanarayan Expires January 6, 2014 [Page 11]
Internet-Draft Auto Discovery VPNs July 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| RESERVED | PSK Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IDi Payload Length | IDr Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSi Payload Length | TSr Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! IPv4 Address !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Timeout !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Pre-Shared Key ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IDi Identification Payload ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IDr Identification Payload ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TSi Traffic Selector Payload ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TSr Traffic Selector Payload ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: IPv4 Shortcut Data
The I field is a (single bit) flag indicating whether a shortcut
partner should act as an initiator. When the I flag is set, the
recipient of this SHORTCUT notification is designated (by the
shortcut suggester) as the shortcut initiator. When the I flag is
cleared, the recipient of this notification is designated as the
shortcut responder.
The RESERVED field MUST be set to all zeros by the sender of this
notification (i.e. the shortcut suggester) and MUST be ignored by
the recipient.
The PSK Length field contains the length of the Pre-Shared Key field
in octets. This field MUST be 0 if the Pre-Shared Key field is
omitted. If it not set to zero, this value SHOULD NOT be less than
32.
The IDi Payload Length field contains the octet length of the IDi
Identification Payload field, which MUST be greater than 0.
The IDr Payload Length field contains the octet length of the IDr
Identification Payload field, which MUST be greater than 0.
Sathyanarayan Expires January 6, 2014 [Page 12]
Internet-Draft Auto Discovery VPNs July 2013
The TSi Payload Length field contains the octet length of the TSi
Traffic Selector Payload field. This field MUST be 0 if the TSi
Traffic Selector Payload field is omitted.
The TSr Payload Length field contains the octet length of the TSr
Traffic Selector Payload field. This field MUST be 0 if the TSr
Traffic Selector Payload field is omitted.
The IPv4 Address field contains the IPv4 address of the peer
shortcut partner.
The Timeout field contains the maximum number of seconds that this
shortcut recommendation should last. After this period of time
lapses, the shortcut partners SHOULD tear down the shortcut SA. If
this field is 0, the shortcut suggestion MAY last indefinitely. The
shortcut partners MAY use a smaller timeout value than given here
based on their policies.
The Pre-Shared Key field (if present) contains a Pre-Shared Key
(PSK) to be used for authentication during the shortcut handshake.
When this field is present, the shortcut suggester MUST send the
same PSK value to both shortcut partners. The shortcut partners MUST
use this value for IKE authentication. When the Pre-Shared Key field
is absent (as indicated by a value of 0 in the PSK Length field),
the shortcut partners MUST perform IKE authentication using
certificates or any other authentication method they would normally
use to authenticate for the identities specified by the IDi and IDr
Identification Payload fields.
The IDi Identification Payload field contains the identity of the
shortcut initiator. This identity is sent in the format specified in
Section 3.5 of RFC 5996 [IKEV2], omitting the IKE generic payload
header fields and starting with the ID Type field. The shortcut
initiator MUST use this identifier when establishing the shortcut
and the shortcut responder MUST verify that this identifier was
used. If the shortcut initiator does not have the specified
identifier, it MUST NOT attempt to establish the shortcut.
The IDr Identification Payload field contains the identity of the
shortcut responder. This identity is sent in the format specified in
Section 3.5 of RFC 5996 [IKEV2], omitting the IKE generic payload
header fields and starting with the ID Type field. The shortcut
responder MUST use this identifier when establishing the shortcut
and the shortcut initiator MUST verify that this identifier was
used. If the shortcut responder does not have the specified
identifier, it MUST NOT attempt to establish the shortcut.
Sathyanarayan Expires January 6, 2014 [Page 13]
Internet-Draft Auto Discovery VPNs July 2013
The TSi and TSr Traffic Selector Payload fields (when present)
contain, respectively, a Traffic Selector Payload as specified in
section 3.13 of RFC 5996 [IKEV2], omitting the IKE generic payload
header fields and starting with the Number of TSs field.
3.4.2. IPv6 SHORTCUT Type
When the IPv6 Shortcut Type is sent, the Shortcut Data field has the
format illustrated in Figure 3.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| RESERVED | PSK Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IDi Payload Length | IDr Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSi Payload Length | TSr Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! IPv6 Address (octets 1-4) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! IPv6 Address (octets 5-8) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! IPv6 Address (octets 9-12) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! IPv6 Address (octets 13-16) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Timeout !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Pre-Shared Key ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IDi Identification Payload ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IDr Identification Payload ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TSi Traffic Selector Payload ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TSr Traffic Selector Payload ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IPv6 Shortcut Data
The I field is a (single bit) flag. If the I flag is set, the
recipient of this shortcut notification will be the shortcut
Sathyanarayan Expires January 6, 2014 [Page 14]
Internet-Draft Auto Discovery VPNs July 2013
initiator. If the I flag is cleared, the recipient of this
notification is designated as the shortcut responder.
The RESERVED field MUST be set to all zeros by the sender of this
notification (i.e. the shortcut suggester) and MUST be ignored by
the recipient.
The PSK Length field contains the octet length of the Pre-Shared Key
field. This field MUST be 0 is the Pre-Shared Key field is omitted.
If it not set to zero, this value SHOULD NOT be less than 32.
The IDi Payload Length field contains the octet length of the IDi
Identification Payload field, which MUST be greater than 0.
The IDr Payload Length field contains the octet length of the IDr
Identification Payload field, which MUST be greater than 0.
The TSi Payload Length field contains the octet length of the TSi
Traffic Selector Payload field. This field MUST be 0 if the TSi
Traffic Selector Payload field is omitted.
The TSr Payload Length field contains the octet length of the TSr
Traffic Selector Payload field. This field MUST be 0 if the TSr
Traffic Selector Payload field is omitted.
The IPv6 Address field contains the IPv6 address of the other
shortcut partner.
The Timeout field contains the maximum number of seconds that this
shortcut suggestion should last. After this period of time lapses,
the shortcut partners SHOULD tear down the shortcut SA. If this
field is 0, this suggestion MAY last indefinitely. The shortcut
partners MAY use smaller timeout value than given here, based on
their policies.
The Pre-Shared Key field (when present) contains a Pre-Shared Key
(PSK) to be used for authentication during the shortcut handshake.
When this field is present, the shortcut suggester MUST send the
same PSK value to both shortcut partners. The shortcut partners MUST
use this value for IKE authentication. When the Pre-Shared Key field
is absent (as indicated by a value of 0 in the PSK Length field),
the shortcut partners MUST perform IKE authentication using
certificates or any other authentication method they would normally
use to authenticate for the identities specified by the IDi and IDr
Identification Payload fields.
Sathyanarayan Expires January 6, 2014 [Page 15]
Internet-Draft Auto Discovery VPNs July 2013
The IDi Identification Payload field contains the identity of the
shortcut initiator. This identity is sent in the format specified in
section 3.5 of RFC 5996 [IKEV2], omitting the IKE generic payload
header fields and starting with the ID Type field. The shortcut
initiator MUST use this identifier when establishing the shortcut
and the shortcut responder MUST verify that this identifier was
used. If the shortcut initiator does not have the specified
identifier, it MUST NOT attempt to establish the shortcut.
The IDr Identification Payload field contains the identity of the
shortcut responder. This identity is sent in the format specified in
section 3.5 of RFC 5996 [IKEV2], omitting the IKE generic payload
header fields and starting with the ID Type field. The shortcut
responder MUST use this identifier when establishing the shortcut
and the shortcut initiator MUST verify that this identifier was
used. If the shortcut responder does not have the specified
identifier, it MUST NOT attempt to establish the shortcut.
The TSi and TSr Traffic Selector Payload fields (when present)
contain, respectively, a Traffic Selector Payload as specified in
section 3.13 of RFC 5996 [IKEV2], omitting the IKE generic payload
header fields and starting with the Number of TSs field.
3.4.3. DNS Name Shortcut Type
When the DNS Name Shortcut Type is sent, the Shortcut Data field has
this format:
Sathyanarayan Expires January 6, 2014 [Page 16]
Internet-Draft Auto Discovery VPNs July 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| RESERVED | FQDN Length | PSK Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IDi Payload Length | IDr Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSi Payload Length | TSr Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
! Fully Qualified Domain Name !
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Timeout !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Pre-Shared Key ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IDi Identification Payload ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IDr Identification Payload ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TSi Traffic Selector Payload ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TSr Traffic Selector Payload ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: DNS Name Shortcut Data
The I field is a (single bit) flag. When the I flag is set, the
recipient of this shortcut notification will be the shortcut
initiator. When the I flag is cleared, the recipient of this
notification is designated as the shortcut responder.
The RESERVED field MUST be set to all zeros by the sender of this
notification (i.e. the shortcut suggester) and MUST be ignored by
the recipient.
The FQDN Length field contains the octet length of the DNS name of
the FQDN field. This field MUST be non-zero. 12 octets are used,
because [RFC1034] allows DNS names of up to 252 characters and IDNA
([RFC5890]) specifies the encoding of internationalized domain names
using Punycode ([RFC3492]) which can take up to 4 octets per
character.
The PSK Length field contains the octet length of the Pre-Shared Key
field. This field MUST be 0 if the Pre-Shared Key field is omitted.
Sathyanarayan Expires January 6, 2014 [Page 17]
Internet-Draft Auto Discovery VPNs July 2013
If the field value is non-zero, this value SHOULD NOT be less than
32.
The IDi Payload Length field contains the octet length of the IDi
Identification Payload field, which MUST be greater than 0.
The IDr Payload Length field contains the octet length of the IDr
Identification Payload field, which MUST be greater than 0.
The TSi Payload Length field contains the octet length of the TSi
Traffic Selector Payload field. This field MUST be 0 if the TSi
Traffic Selector Payload field is omitted.
The TSr Payload Length field contains the octet length of the TSr
Traffic Selector Payload field. This field MUST be 0 if the TSr
Traffic Selector Payload field is omitted.
The Fully Qualified Domain Name field contains the Fully Qualified
Domain Name of the peer shortcut partner, encoded as in RFC 1034 and
5890.
The Timeout field contains the maximum number of seconds that this
shortcut suggestion should last. After this period of time lapses,
the shortcut partners SHOULD tear down the shortcut SA. If this
field is 0, this suggestion MAY last indefinitely. The shortcut
partners MAY use a smaller timeout value than given here, based on
their policies.
The Pre-Shared Key field (when present) contains a Pre-Shared Key
(PSK) to be used for authentication during the shortcut handshake.
When this field is present, the shortcut suggester MUST send the
same PSK value to both shortcut partners. The shortcut partners MUST
use this value for IKE authentication. When the Pre-Shared Key field
is absent (as indicated by a value of 0 in the PSK Length field),
the shortcut partners MUST perform IKE authentication using
certificates or any other authentication method they would normally
use to authenticate for the identities specified by the IDi and IDr
Identification Payload fields.
The IDi Identification Payload field contains the identity of the
shortcut initiator. This identity is sent in the format specified in
section 3.5 of RFC 5996 [IKEV2], omitting the IKE generic payload
header fields and starting with the ID Type field. The shortcut
initiator MUST use this identifier when establishing the shortcut
and the shortcut responder MUST verify that this identifier was
used. If the shortcut initiator does not have the specified
Sathyanarayan Expires January 6, 2014 [Page 18]
Internet-Draft Auto Discovery VPNs July 2013
identifier, it MUST NOT attempt to establish the shortcut but simply
ignore the SHORTCUT notification.
The IDr Identification Payload field contains the identity of the
shortcut responder. This identity is sent in the format specified in
section 3.5 of RFC 5996 [IKEV2], omitting the IKE generic payload
header fields and starting with the ID Type field. The shortcut
responder MUST use this identifier when establishing the shortcut
and the shortcut initiator MUST verify that this identifier was
used. If the shortcut responder does not have the specified
identifier, it MUST NOT attempt to establish the shortcut but simply
ignore the SHORTCUT notification.
The TSi and TSr Traffic Selector Payload fields (when present)
contain, respectively, a Traffic Selector Payload as specified in
section 3.13 of RFC 5996 [IKEV2], omitting the IKE generic payload
header fields and starting with the Number of TSs field.
It is RECOMMENDED that when using certificates, the ID payload
matching the peer (the IDi payload if the I bit is unset, or the IDr
payload if it is set) should be of the FQDN type, and contain the
same FQDN as the SHORTCUT notification.
3.4.4. Response Shortcut Type
The Response Shortcut Type is sent by the shortcut partner to the
shortcut suggester to indicate the status of the shortcut
recommendation. The Shortcut Data field for this shortcut type has
the format illustrated in Figure 5.
Sathyanarayan Expires January 6, 2014 [Page 19]
Internet-Draft Auto Discovery VPNs July 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response Code | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IDi Payload Length | IDr Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSi Payload Length | TSr Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IDi Identification Payload ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IDr Identification Payload ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TSi Traffic Selector Payload ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TSr Traffic Selector Payload ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Response Shortcut Data
The Response Code (RCODE) is a 16-bit field, used by the shortcut
peers to indicate the status on the SHORTCUT notification received.
The RCODEs we consider in this document are the following:
Value Description
---------------------
0 undefined
1 SHORTCUT_SUCCEED
2 TEMPORARILY_DISABLING_SHORTCUT
3 SHORTCUT_PARTNER_UNREACHABLE
4 IKEv2_NEGOTIATION_FAILED
5 UNMATCHED_SHORTCUT_SPD
6 UNMATCHED_SHORTCUT_PAD
More information about RCODE is provided in Section 3.5.
The RESERVED field MUST be set to all zeros by the sender of this
notification (the shortcut partner) and MUST be ignored by the
recipient (shortcut suggester).
The IDi Payload Length field contains the octet length of the IDi
Identification Payload field, which MUST be greater than 0.
Sathyanarayan Expires January 6, 2014 [Page 20]
Internet-Draft Auto Discovery VPNs July 2013
The IDr Payload Length field contains the octet length of the IDr
Identification Payload field, which MUST be greater than 0.
The Timeout field (32 bits) contains the maximum number of seconds
that suggests how long the shortcut service is not available. If
this field is 0, this suggestion has no specific timeout and it is
left at the discretion of the shortcut suggester to decide when to
re-send the SHORTCUT Notify Payload.
The IDi Identification Payload field contains the identity of the
shortcut initiator as originally sent the by shortcut suggester.
This identity is sent in the format specified in section 3.5 of RFC
5996, omitting the IKE generic payload header fields and starting
with the ID Type field.
The IDr Identification Payload field contains the identity of the
shortcut responder as sent originally by the shortcut suggester.
This identity is sent in the format specified in section 3.5 of RFC
5996, omitting the IKE generic payload header fields and starting
with the ID Type field
The TSi Payload Length field contains the octet length of the TSi
Traffic Selector Payload field that was sent by the shortcut
suggester. This field MUST be 0 if the TSi Traffic Selector Payload
field is omitted.
The TSr Payload Length field contains the octet length of the TSr
Traffic Selector Payload field that was sent by the shortcut
suggester. This field MUST be 0 if the TSr Traffic Selector Payload
field is omitted.
The IDi, IDr, TSi and TSr fields are included in the Shortcut
Response type in order to enable the shortcut suggester to identify
the SHORTCUT notification for which, response received. This is
useful if the shortcut suggester has sent multiple SHORTCUT
notification to a shortcut partner.
3.5. SHORTCUT Response Codes (RCODE)
This section provides more information on the use of the response
code (RCODE)
Sathyanarayan Expires January 6, 2014 [Page 21]
Internet-Draft Auto Discovery VPNs July 2013
3.5.1. SHORTCUT_SUCCEED
The RCODE value for SHORTCUT_SUCCEED is: 1
This RCODE indicates that the shortcut has been established between
the shortcut partners.
3.5.2. SHORTCUT_PARTNER_UNREACHABLE
The RCODE value for SHORTCUT_PARTNER_UNREACHABLE is: 3
This RCODE indicates that the attempt to establish the recommended
shortcut has failed because the partner peer was unreachable. This
may happen, for example, if the partner peers are behind separate
NATs, or a firewall drops packets between the shortcut partners. It
may also be that the partner peer is only available through a
specific interface. In addition, the partner peer may have been
temporarily disconnected or its shortcut service has been
temporarily disabled as explained in subsection 3.5.3. .
It is the responsibility of the shortcut suggester to determine the
reason of the observed unreachability as well as what policy to
apply. However, the shortcut suggester SHOULD NOT send a SHORTCUT
notification to the shortcut partner to the timeout set in the
response message.
3.5.3. TEMPORARILY_DISABLING_SHORTCUT
The RCODE for TEMPORARILY_DISABLING_SHORTCUT is: 2
This RCODE indicates that the shortcut recommendation is refused by
the shortcut peer because it has deactivated the shortcut service.
In other words, this RCODE indicates that any attempt to establish
shortcut is refused independently of the SHORTCUT notification sent.
For example, the shortcut service could be disabled when the
shortcut peer is overloaded.
If the shortcut initiator generates this response code, then it
SHOULD NOT initiate the shortcut negotiation. If this response code
is generated by the shortcut responder, then it SHOULD discard IKEv2
packets from the shortcut initiator establishing the shortcut. The
initiator will then consider the shortcut responder as unreachable
and send a SHORTCUT_PARTNER_UNREACHABLE to the shortcut suggester.
Sathyanarayan Expires January 6, 2014 [Page 22]
Internet-Draft Auto Discovery VPNs July 2013
When receiving this Shortcut Type with this response code, the
shortcut suggester SHOULD NOT send any other SHORTCUT notification
before the Timeout indicated in the shortcut Data. If the Shortcut
Type is not present, then it is up to the shortcut suggester to
decide when a new SHORTCUT notification SHOULD be sent.
3.5.4. IKEv2_NEGOTIATION_FAILED
The Shortcut Type for IKEv2_NEGOTIATION_FAILED is: 4
This RCODE indicates that the IKEv2 negotiation between the two
partner peers did not complete successfully. That is, the shortcut
recommendation was accepted and acted upon, but the IKEv2
negotiation failed. This RCODE does not provide information on the
reasons the shortcut establishment failed, and thus other more
specific RCODEs (see below) SHOULD be preferred by implementations
when this is possible.
3.5.5. UNMATCHED_SHORTCUT_SPD
The RCODE for UNMATCHED_SHORTCUT_SPD is: 5
This RCODE indicates an error resulting from the analysis of the
SHORTCUT notification. Before establishing a shortcut, the shortcut
initiator MUST check that the shortcut partner's IP address matches
its Security Policy Database (SPD). If a mismatch occurs with
shortcut initiator's SPD, the shortcut initiator MUST NOT initiate
the shortcut. In this case, the initiator MUST use the
UNMATCHED_SHORTCUT_SPD RCODE in its SHORTCUT Response type.
If the mismatch occurs with the shortcut responder, it MUST send to
the shortcut suggester the UNMATCHED_SHORTCUT)_SPD RCODE in its
SHORTCUT Response Notify Payload. Eventually the shortcut initiator
will start an IKEv2 negotiation. The shortcut responder SHOULD
terminate the IKEV2 negotiation with a TS_UNACCEPTABLE. The shortcut
cannot be established and the shortcut initiator MUST return the
shortcut suggester the IKEv2_NEGOTIATION_FAILED Shortcut Type in its
SHORTCUT Response Notify Payload.
When receiving this Shortcut Response Type with this RCODE, the
shortcut suggester MUST NOT resend to the shortcut peer a SHORTCUT
notification with the same IP(s).
Sathyanarayan Expires January 6, 2014 [Page 23]
Internet-Draft Auto Discovery VPNs July 2013
3.5.6. UNMATCHED_SHORTCUT_PAD
The Shortcut Type for UNMATCHED_SHORTCUT_PAD is: 6
This RCODE indicates an error resulting from the analysis of the
SHORTCUT notification. Before establishing a shortcut, the shortcut
initiator MUST check the shortcut partner's IP address and
Identities IDi/IDr matches its Peer Authentication Database (PAD).
If a mismatch occurs with the shortcut initiator's PAD, the shortcut
initiator MUST NOT initiate the establishment of the recommended
shortcut. The initiator then sends the UNMATCHED_SHORTCUT_PAD RCODE
in its SHORTCUT Response Notify Payload.
If the mismatch occurs with the shortcut responder, it MUST send to
the shortcut suggester the UNMATCHED_SHORTCUT_PAD RCODE in its
SHORTCUT Response. Eventually the shortcut initiator will start an
IKEv2 negotiation. The shortcut responder SHOULD terminate the IKEV2
negotiation with a TS_UNACCEPTABLE. Thus, the shortcut cannot be
established and the shortcut initiator MUST return the shortcut
suggester the IKEv2_NEGOTIATION_FAILED Shortcut Type in its SHORTCUT
Response Notify Payload.
When receiving Shortcut Response Type with this RCODE, the shortcut
suggester MUST NOT resend to the shortcut partners a SHORTCUT
notification with the same IP(s).
4. IPsec Policy
This section discusses the implications of the use of the ADVPN
Protocol on IPsec policy.
4.1. Security Policy Database (SPD)
The Notification described in Section 3.2. conveys policy in the
sense of section 4.4.1 of RFC 4301 ([IPSECARCH]). In the terms of
that document, these are SPD elements. Assuming these elements are
accepted, they update the existing security policy of the receiver.
The entries specified in a SHORTCUT are inserted into the SPD
immediately before the entry that they are updating, so that these
new entries take precedence over existing ones.
Sathyanarayan Expires January 6, 2014 [Page 24]
Internet-Draft Auto Discovery VPNs July 2013
RFC 4301 does not specify time limits for SPD entries. In that
sense, this document updates RFC 4301. SPD entries now come in two
flavors: static entries, which never expire and are defined by an
administrator, and dynamic entries which have an expiration time
specified in the SHORTCUT notification.
For example, suppose a static entry exists for 192.0.2.0/23, and the
local subnet is 192.0.1.0/24. Initially, the entry looks like this:
Local=192.0.1.0/24,Remote=192.0.2.0/23,PROT,Peer=vpngw.example.com
Assume now that a SHORTCUT notification is received which describes
gateway foo.example.com, and remote network 192.0.2.0/24. The
database will look as follows:
Local=192.0.1.0/24,Remote=192.0.2.0/24,PROT,Peer=foo.example.com
Local=192.0.1.0/24,Remote=192.0.2.0/23,PROT,Peer=vpngw.example.com
Because of the rules of processing as specified in Section 5.1 of
RFC 4301, the earlier entry takes precedence, and overrides the
second entry for subnet 192.0.2.0/24. The second entry still applies
to 192.0.3.0/24.
4.2. Security Policy Database Cache (SPD Cache)
The SPD Cache also needs to be updated. With the above entry, a
cache entry was created reflecting the matching SA. If no change to
the cache is made, the IPsec stack will continue to use the existing
SA despite the change in policy. Since implementations of the SPD
cache vary widely, we do not specify the exact way to handle this
change, but discuss below some implementation suggestions.
One way to handle this would be to narrow the existing SPD Cache
entry so as to cover only the selectors which are not affected by
the SHORTCUT. This has the property of causing the SPD cache entry
to not match the negotiated SA. Whether this is a problem depends on
the implementation of these databases. It is likely not a good idea
to also narrow the existing SAs. While it should be fine for
outbound SAs, it will cause the IPsec stack to drop validly
encrypted packets on inbound processing.
Sathyanarayan Expires January 6, 2014 [Page 25]
Internet-Draft Auto Discovery VPNs July 2013
Another way to handle this would be to simply delete the SPD cache
entry, forcing a re-evaluation of the SPD for the next packets. This
causes an even more serious discrepancy between the Security
Association Database (SAD) and SPD Cache. This should only be done
if it is possible to match existing SAs to new SPD cache entries,
which, again, depends on the implementation details.
The one foolproof way is to erase both SPD cache entries and SAs,
sending the appropriate DELETE payloads to the peer. This is
perfectly compliant and perfectly functional, but will create more
work for the IKE daemon.
4.3. Peer Authentication Database (PAD)
This database will also be updated with a temporary entry when a
SHORTCUT notification is received. The entry includes the name, IP
address and a specification of either PSK or certificate
authentication. This entry MUST also expire when the SHORTCUT
expires.
It is conceivable that peers will appear in both static and dynamic
entries. It is also possible that the same peer will be mentioned in
multiple SHORTCUT notifications, each with a different expiration
time. An implementation of this specification MUST track all such
entries. Two entries will be considered to represent the same entity
if either they share both ID and certificate, or if they share ID
and IP address.
If all entries matching a particular entity expire, then the
implementation MUST delete all IKE and child SAs associated with
that entity.
5. Security Considerations
No lifetime is specified for the Pre-Shared Key (PSK) so the
shortcut suggester SHOULD generate the PSK value with plenty of
entropy. See [RANDOMNESS] for advice on generating random numbers
for cryptographic purposes. The shortcut partners may rekey as
needed and may even use the PSK value for reauthentication, although
it is not clear that there is much value in doing so. If one of the
shortcut partners decides that the PSK is too old (recognizing that
it is only used for authentication), it may simply tear down the
Sathyanarayan Expires January 6, 2014 [Page 26]
Internet-Draft Auto Discovery VPNs July 2013
shortcut SA. Eventually, the shortcut suggester will set up the
shortcut again, if it is needed.
To head off this situation, the shortcut suggester may periodically
send a new SHORTCUT notification to each of the two shortcut
partners. If a shortcut partner receives a SHORTCUT notification
suggesting a shortcut that already exists with new parameters, the
shortcut partner SHOULD establish a new shortcut SA with the peer
partner using the new parameters and then tear down the old shortcut
SA.
6. IANA Considerations
IANA is requested to assign a notify message type from the status
types range (16418-40959) of the "IKEv2 Notify Message Types"
registry with name "SHORTCUT".
IANA is also requested to allocate a new registry within the IKEv2
parameters page called "SHORTCUT Notify types" and "SHORTCUT
response codes" with initial content as follows. The policy for this
registry shall be "specification required"
SHORTCUT types initial values:
Value Description
----- -----------
0 IPv4 Shortcut
1 IPv6 Shortcut
2 DNS Name Shortcut
3 Response Shortcut
4-39999 Unassigned
40000-65535 Private Use
SHORTCUT Response codes initial values:
Sathyanarayan Expires January 6, 2014 [Page 27]
Internet-Draft Auto Discovery VPNs July 2013
Value Description
---------------------
0 undefined
1 SHORTCUT_SUCCEED
2 TEMPORARILY_DISABLING_SHORTCUT
3 SHORTCUT_PARTNER_UNREACHABLE
4 IKEv2_NEGOTIATION_FAILED
5 UNMATCHED_SHORTCUT_SPD
6 UNMATCHED_SHORTCUT_PAD
7. References
7.1. Normative References
[IKEV2] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
5996, September 2010.
[IPSECARCH] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC1034] Mockapetris, P., "Domain Names - Concepts and
Facilities", RFC 1034, November 1987.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document
Framework", RFC 5890, August 2010.
7.2. Informative References
[ADVPNreq] Hanna, S., "Auto Discovery VPN Problem Statement and
Requirements", draft-ietf-ipsecme-p2p-vpn-problem-
07.txt, June 2013.
[RANDOMNESS] Eastlake, 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC
4086, June 2005.
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of
Unicode for Internationalized Domain Names in
Applications (IDNA)", RFC 3492, March 2003.
Sathyanarayan Expires January 6, 2014 [Page 28]
Internet-Draft Auto Discovery VPNs July 2013
8. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
The authors of this draft would like to acknowledge the following
people who have contributed to or provided substantial input on the
preparation of this document or predecessors to it: Scott McKinnon
and Vishwas Manral.
Sathyanarayan Expires January 6, 2014 [Page 29]
Internet-Draft Auto Discovery VPNs July 2013
Appendix A. ADVPN Example Use Cases
This appendix presents a few example situations where the ADVPN
protocol may be useful and illustrates how it works.
A.1. Branch Office Videoconference
In this example, users have initiated a videoconference between two
branch offices of SmithCo located in Ashby and Bedford. Each branch
office has an IPsec gateway that is configured to send all traffic
to the IPsec gateway at the main SmithCo office in Paris. Figure 6
illustrates this initial situation, showing these three IPsec
gateways and the IPsec SAs in place when the videoconference starts.
+----------+
| Paris GW |
+----------+
/ \
/ \
/ \
/ \
/ \
/ \
/ \
+----------+ +------------+
| Ashby GW | | Bedford GW |
+----------+ +------------+
Figure 6: Initial SmithCo IPsec SAs
All of these gateways support SHORTCUT notifications and have been
configured to use them within SmithCo. Therefore, they all sent the
Vendor ID payload described in Section Error! Reference source not
found.to each other in their initial IKE exchanges. This means that
they are all aware that SHORTCUT notifications may be used on the
IPsec SAs illustrated in Figure 6.
Once the videoconference begins, the Paris GW notices a large amount
of videoconference traffic between the Ashby GW and the Bedford GW.
The Paris GW has been configured to permit videoconference traffic
to trigger a shortcut between two branch gateways so it sends a
SHORTCUT notification to the Ashby and Bedford GWs, suggesting that
they establish a shortcut. In this instance, it identifies the Ashby
GW as the shortcut initiator by setting the I bit in the
Sathyanarayan Expires January 6, 2014 [Page 30]
Internet-Draft Auto Discovery VPNs July 2013
notification sent to that gateway and leaving that bit cleared in
the notification sent to Bedford GW.
Because all gateways in SmithCo have certificates from the same CA
and have been configured to trust that CA to issue certificates,
there is no need to use a PSK. The Paris GW simply sets the IDi
Identification Payload field of the SHORTCUT notifications to the
subject DN of the Ashby GW and the IDr Identification Payload field
of the SHORTCUT notifications to the subject DN of the Bedford GW.
The Paris GW sets the TSi Traffic Selector Payload and TSr Traffic
Selector Payload fields in the SHORTCUT notifications to indicate
that the Ashby GW should only use this shortcut for
videoconferencing traffic destined for the network behind the
Bedford GW and vice versa.
After receiving the SHORTCUT notification, the Ashby GW establishes
an IKEv2 exchange with the Bedford GW and then establishes an IPsec
security association between the two. Figure 7 shows the SAs in use
after the shortcut has been established.
+----------+
| Paris GW |
+----------+
/ \
/ \
/ \
/ \
/ \
/ \
/ \
+----------+ +------------+
| Ashby GW |----------------| Bedford GW |
+----------+ +------------+
Figure 7: SmithCo IPsec SAs with the shortcut established
After the timeout period specified by the Paris GW, the shortcut
between Ashby GW and Bedford GW will be terminated. If the
videoconference is finished before that time, the shortcut may also
be terminated due to inadequate traffic, at the discretion of the
Ashby GW and Bedford GW.
Sathyanarayan Expires January 6, 2014 [Page 31]
Internet-Draft Auto Discovery VPNs July 2013
A.2. Optimization for Videoconference with Partner
In this example, SmithCo has added a partner JonesCo and established
an IPsec SA between Paris GW (the main SmithCo office) and Tokyo GW
(the main JonesCo office).
Users have initiated a videoconference between the Ashby branch
office of SmithCo and the Concord branch office of JonesCo. Each
branch office has an IPsec gateway that is configured to send all
traffic to the IPsec gateway at the main office for that company.
Figure 8 illustrates this initial situation, showing these four
IPsec gateways and the IPsec SAs in place when the videoconference
starts.
+----------+ +----------+
| Paris GW |-------| Tokyo GW |
+----------+ +----------+
/ \
/ \
/ \
/ \
/ \
/ \
/ \
+----------+ +------------+
| Ashby GW | | Concord GW |
+----------+ +------------+
Figure 8: Initial IPsec SAs within SmithCo and JonesCo
All gateways in this example support SHORTCUT notifications.
Therefore, they all sent the Vendor ID payload described in Section
Error! Reference source not found.to each other in their initial IKE
exchanges. This means that they are all aware that SHORTCUT
notifications may be used on the IPsec SAs illustrated in Figure 8.
Further, these gateways have been configured to use SHORTCUT
notifications to optimize routing for video traffic within their
organizations and among SmithCo and JonesCo gateways.
Once the videoconference begins, the Paris GW notices a large amount
of videoconference traffic transiting the Paris GW between the Ashby
GW and the Tokyo GW. Therefore, the Paris GW sends a SHORTCUT
notification to the Ashby GW and the Tokyo GW, suggesting that they
establish a shortcut. We will not cover all the details of this
process because most are similar to the previous example. However,
assume that the Ashby GW and the Tokyo GW have certificates from
different CAs and may not be configured to trust each other's CA.
Sathyanarayan Expires January 6, 2014 [Page 32]
Internet-Draft Auto Discovery VPNs July 2013
Therefore, the Paris GW generates a PSK and sends it to both the
Ashby GW and the Tokyo GW. The Ashby GW and the Tokyo GW use this
PSK to establish a shortcut SA, as shown in Figure 9. Because of the
Traffic Selectors sent by the Paris GW in the SHORTCUT
notifications, this shortcut SA may only be used for video traffic
between the Ashby GW and JonesCo.
+----------+ +----------+
| Paris GW |-------| Tokyo GW |
+----------+ +----------+
/ --/ \
/ --/ \
/ --/ \
/ --/ \
/ --/ \
/ --/ \
/ / \
+----------+ +------------+
| Ashby GW | | Concord GW |
+----------+ +------------+
Figure 9: SmithCo and JonesCo with First Shortcut
After this first shortcut SA has been established, Tokyo GW notices
large volumes of video traffic between Ashby GW and Concord GW.
Therefore, Tokyo GW sends a SHORTCUT notification to the Ashby GW
and the Concord GW, suggesting that they establish a shortcut. We do
not cover all details of this process because they are mostly
similar to the previous example. Again, the Ashby GW and the Concord
GW probably have certificates from different CAs so the Tokyo GW
generates a PSK and sends it to both the Ashby GW and the Concord
GW. The Ashby GW and the Concord GW use this PSK to establish a
shortcut SA, as shown in Figure 10. Because of the Traffic Selectors
sent by the Tokyo GW in the SHORTCUT notifications, this shortcut SA
may only be used for video traffic between the Ashby GW and the
Concord GW.
Sathyanarayan Expires January 6, 2014 [Page 33]
Internet-Draft Auto Discovery VPNs July 2013
+----------+ +----------+
| Paris GW |-------| Tokyo GW |
+----------+ +----------+
/ --/ \
/ --/ \
/ --/ \
/ --/ \
/ --/ \
/ --/ \
/ / \
+----------+ +------------+
| Ashby GW |-------------------------------| Concord GW |
+----------+ +------------+
Figure 10: SmithCo and JonesCo with Second Shortcut
After some period, the Ashby GW or the Tokyo GW may realize that no
traffic is flowing over the SA between them and therefore decide to
terminate this SA. This will result in the SA configuration shown in
Figure 11.
Note that this optimal SA configuration has been reached without
needing to have any special configuration or global knowledge and it
involves multiple domains. The only requirement is a policy on the
Paris GW and the Tokyo GW indicating that video traffic between
SmithCo and JonesCo should be optimized by creating shortcut SAs.
+----------+ +----------+
| Paris GW |-------| Tokyo GW |
+----------+ +----------+
/ \
/ \
/ \
/ \
/ \
/ \
/ \
+----------+ +------------+
| Ashby GW |-------------------------------| Concord GW |
+----------+ +------------+
Figure 11: SmithCo and JonesCo in Final Configuration
The shortcut between the Ashby GW and the Concord GW will remain up
until its timeout is reached or traffic levels on this SA drop off
because the videoconference has finished.
Sathyanarayan Expires January 6, 2014 [Page 34]
Internet-Draft Auto Discovery VPNs July 2013
A.3. Heterogeneous Wireless Networks Traffic
As wireless networks increase their access capacities, denser
deployments will become the norm. In addition, we observe an
increasing number of cases where operators, for various reasons that
are outside of the scope of this document, opt for network
deployments that use a variety of coverage sites. In practice, this
means that, for instance, macro cells are complemented by smaller
cells (pico cells, femto cells, etc.) that boost capacity and
improve end-user experience. Today's cellular networks can provide
access rates in the order of tens of Mb/s with high quality of
service guarantees, and can thus be used as connections where small
and medium enterprises can base their VPNs. Within this context, the
operator may use different gateways for securing subscriber VPN
traffic.
Consider, for example, the case illustrated in Figure 12 where two
colleagues from different departments of the same company use
multimedia conferencing to collaborate with some customers. Dotted
lines in the Figure indicate IP connectivity, while dashed lines
indicate an established SA. All gateways and endpoints in the Figure
support the protocol described in this document, i.e., they have
indicated so to each other as described in Section Error! Reference
source not found.One of them, Peer 1 has joined the teleconference
while on the go, but will be arriving at the company office prior to
the conclusion of the teleconference. As Peer 1 roams in the mobile
network, changing cell sites as it travels towards the office, the
multimedia traffic flows through the Macro GW.
Sathyanarayan Expires January 6, 2014 [Page 35]
Internet-Draft Auto Discovery VPNs July 2013
+----------+ +---------+
| Macro GW |-------| Pico GW |
+----------+ +---------+
. . \ \
. . \ \
. . \ \
. . \ \
. +--------+ \ \
. | Cell 2 | \ \
. +--------+ \ \
+--------+ +--------+ +-----------+
| Cell 1 | | Cell 3 | | Office GW |
+--------+ +--------+ +-----------+
\ \
\ \
+--------+ +--------+
Peer 1 movement >>> | Peer 1 | | Peer 2 |
+--------+ +--------+
Figure 12: Initial IPsec SAs within the HetNet
Note that both the Macro GW and the Pico GW are in the realm of the
mobile operator, while the Office GW is in the realm of the company.
The company and the mobile operator have an already established
trust relationship. Moreover, for end-user experience reasons as
well as traffic flow optimization both the company network
administrators and the mobile operator have policies that favor
traffic routes that are contained in the local company network.
Once Peer 1 enters the area of the company campus the wireless
network small-cell deployment covering the company buildings is the
preferred means of connecting to the network, both from the
perspective of the company and the mobile operator. At this stage in
our scenario, the fact that Peer 1 is in the coverage area of the
Pico GW is recognized by the Macro GW, which initiates (as a
shortcut suggester) the procedure described in Section 3. As a
result, the first step in the route optimization is performed and
Peer 1 sets up the shortcut with the Pico GW, which becomes its
shortcut partner.
Figure 13 illustrates the newly established shortcut as well as the
fact that Peer 1 continues to use the same radio interface as
before, i.e. this scenario does not involve vertical handovers.
Sathyanarayan Expires January 6, 2014 [Page 36]
Internet-Draft Auto Discovery VPNs July 2013
+----------+ +---------+
| Macro GW |-------| Pico GW |
+----------+ +---------+
. . . | \
. . . | \
. . . | \
. . . | \
. +--------+ . | \
. | Cell 2 | . | \
. +--------+ . | \
+--------+ +--------+ | +-----------+
| Cell 1 | | Cell 3 | | | Office GW |
+--------+ +--------+ | +-----------+
| . \
| . \
+--------+ +--------+
| Peer 1 | | Peer 2 |
+--------+ +--------+
Figure 13: First route optimization within the HetNet
Once Peer 1 moves within the company premises and establishes the
shortcut with the operator Pico GW more route optimization
opportunities arise, and the ADVPN protocol can implement them
without requiring any additional manual configuration neither by the
operator nor by the company administrator.
At this stage, we assume that the Pico GW can determine the fact
that Peer 1 could become a shortcut partner of the Office GW.
Similarly to what was mentioned above, the Pico GW initiates the
shortcut (i.e. acts as a shortcut suggester) indicating to Peer 1
and the Office GW that they should establish an SA with each other.
The partners agree to these recommendations, as per their respective
local policies, and proceed with the establishment. At the end of
this process, the configuration is as illustrated in Figure 14.
Sathyanarayan Expires January 6, 2014 [Page 37]
Internet-Draft Auto Discovery VPNs July 2013
+----------+ +---------+
| Macro GW |-------| Pico GW |
+----------+ +---------+
. . . \
. . . \
. . . \
. . . \
. +--------+ . \
. | Cell 2 | . \
. +--------+ . \
+--------+ +--------+ +-----------+
| Cell 1 | | Cell 3 | | Office GW |
+--------+ +--------+ +-----------+
/ \
/ \
+--------+ +--------+
| Peer 1 | | Peer 2 |
+--------+ +--------+
Figure 14: Second route optimization within the HetNet
After this optimization all IPsec traffic is contained within the
local small-cell wireless network. Note that the company network may
include several pico cells, all of which can establish SAs with the
Office GW.
In principle, the protocol can be used to proceed with a further
traffic optimization. Namely, Peer 1 and Peer 2 can establish a
direct shortcut between each other, i.e. become shortcut partners
and thus avoid routing through the Office GW. This is a decision
that the Office GW may take based on local connectivity information.
In this case, after following the same procedure described earlier,
the two Peers will establish an SA, as illustrated in Figure 15.
As Figure 15 shows, traffic may still flow through the Office
routers but Peer 1 and Peer 2 do not need to maintain an SA with the
Office GW (if there is no other traffic).
Finally, note that, in principle, the Office GW could determine that
since no traffic is flowing through its SA with the Pico GW, the
respective SA could be temporarily terminated and initiated later on
when the need arises. This final configuration is illustrated in
Figure 16.
Sathyanarayan Expires January 6, 2014 [Page 38]
Internet-Draft Auto Discovery VPNs July 2013
+----------+ +---------+
| Macro GW |-------| Pico GW |
+----------+ +---------+
. . . \
. . . \
. . . \
. . . \
. +--------+ . \
. | Cell 2 | . \
. +--------+ . \
+--------+ +--------+ +-----------+
| Cell 1 | | Cell 3 | | Office GW |
+--------+ +--------+ +-----------+
. .
. .
+--------+ +--------+
| Peer 1 |------| Peer 2 |
+--------+ +--------+
Figure 15: Third route optimization within the HetNet
+----------+ +---------+
| Macro GW |-------| Pico GW |
+----------+ +---------+
. . . .
. . . .
. . . .
. . . .
. +--------+ . .
. | Cell 2 | . .
. +--------+ . .
+--------+ +--------+ +-----------+
| Cell 1 | | Cell 3 | | Office GW |
+--------+ +--------+ +-----------+
. .
. .
+--------+ +--------+
| Peer 1 |------| Peer 2 |
+--------+ +--------+
Figure 16: Final configuration
Sathyanarayan Expires January 6, 2014 [Page 39]
Internet-Draft Auto Discovery VPNs July 2013
Appendix B. Comparison Against ADVPN Requirements
This section compares the ADVPN protocol specified in this document
against requirements set by [ADVPNreq] (Section 4).
Requirement #1 :
This section details modifications when an endpoint, a gateway, a
spoke and a hub is added or removed or changed.
End points establish a tunnel with a gateway to communicate with
another endpoint. The gateway may use the ADVPN protocol to
optimize communication and either set up endpoint-to-endpoint
communication if both endpoints are attached to the "initial
gateway", or to point to a "closer alternative gateway". The ADVPN
protocol described in this document, impacts either the two
endpoints or the endpoint and the "closer alternative gateway".
Hubs or gateways other than the "initial gateway" or the "closer
alternative gateway" IPsec configuration are not impacted.
An ADVPN is changed means that its IP address is modified.
Updating the outer IP address is the purpose of MOBIKE and
involves the two peers connected with their outer IP addresses.
Similarly, removing an endpoint only impacts the IPsec
configuration of the gateways or the other endpoint it is
communicating with. It is up to local policy that the "initial
gateway" decides to keep the IPsec configuration of the endpoint
or to remove it once the endpoint has moved to the "alternative
gateway that is closer". In the case the "initial gateway" does
not remove the SAs associated to the endpoint, the endpoint is
considered attached simultaneously to two gateways.
The use of ADVPN with an endpoint that is added, removed or
changed results in local IPsec configuration modifications. Only
gateways that the endpoint is attached to are modified. Other
gateways, spokes and hub are not impacted.
Gateways may accept traffic from another gateway. The traffic may
be the one associated to an endpoint or to a gateway. In the first
case, the gateway is considered as the "closer alternative
gateway" as discussed above. The second case occurs if the
"initial gateway" tunnels traffic from an "alternative gateway" to
a "closer alternative gateway". It may then use ADVPN so traffic
directly goes from the "alternative gateway" to the "closer
alternative gateway". The IPsec configuration is then updated on
Sathyanarayan Expires January 6, 2014 [Page 40]
Internet-Draft Auto Discovery VPNs July 2013
both the "alternative gateways" and the "closer alternative
gateway".
Similarly, when the "closer alternative gateway" is removed, only
gateways and endpoints attached to these gateways are impacted.
The use of ADVPN with a gateway that is added or removed results
in local IPsec configuration modifications. Only gateways attached
to are modified. Others gateways, spokes and hub are not impacted.
Spokes are between endpoints and gateways. Unlike end points, they
have a complete network, and they are attached to a hub. If a
spoke-to-spoke communication is set with ADVPN, then IPsec
policies of the two spokes are updated. The hub may not modify its
IPsec policies. Similarly, when a spoke is removed, the IPsec
policies of the other spokes are updated.
The use of ADVPN with a spoke that is added or removed results in
local IPsec configuration modifications. Only spokes attached to
the one being removed are modified. Other gateways, spokes and
hubs are not impacted.
Anytime a shortcut is established, new security policies are
created on the shortcut initiator and the shortcut responders.
ADVPN avoids these security policies to be created manually. In
addition, it uses PSK authentication, which is, reduces latency
and round trip times over other authentication methods like EAP-
SIM.
Requirement #2 :
The solution specified in this document does not require any
manual intervention for establishing a direct tunnel between
endpoints. As described in Requirement #1 above and in Section 4.
, SPD and SAD entries get automatically updated without any manual
intervention. If an IP address of a shortcut partner has changed,
MOBIKE can help in updating SPD entries automatically. If an IP
address change happens after a reboot of a shortcut partner, then
the peer shortcut partner will detect this condition using IKEv2
keep-alive and can divert the traffic back to the "initial-
gateway". Once rebooted, the shortcut partner will establish IPsec
tunnel with the "initial-gateway". At this stage, the "initial-
gateway" will send SHORTCUT notification to the shortcut partners,
to establish shortcut tunnel with new IP address of shortcut
partners.
Sathyanarayan Expires January 6, 2014 [Page 41]
Internet-Draft Auto Discovery VPNs July 2013
Requirement #3 :
This draft enables shortcut partners to establish a secure channel
between them automatically. This will allow other tunneling and
routing protocols to establish direct tunnels or exchange route
updates. However, how a routing protocol module is aware of this
new shortcut tunnel (or how it exchanges route updates), with
shortcut partners, using shortcut tunnel or how other tunneling
protocols establish direct tunnel between shortcut partners, is
specific to the vendor implementation. Thus it is out of scope of
this specification.
Requirement #4 :
While this document describes the syntax of SHORTCUT messages, it
makes no mandates about the policy for initiating shortcuts, nor
about the policy for accepting or rejecting shortcuts. Some
endpoints may agree to accept shortcuts from any peer, as long as
the traffic selectors are a subset of those that the SPD says
should go to that peer. Others may filter the shortcuts based on
IKE ID, so that they do not open tunnels to endpoints outside
their administrative domain. Future documents may profile such
behavior.
Requirement #5 :
When a spoke becomes compromised it may compromise
inbound/outbound communications associated with it. A compromised
spoke may want to use ADVPN in order to corrupt additional traffic
that go through other gateways and spokes. The ADVPN protocol
provides facilities to create shortcuts, however the shortcuts for
given traffic is always triggered by an endpoint dealing with that
traffic. As a result, a compromised host does not affect the
security of other unrelated peers.
Requirement #6 :
This document addresses seamless session handoffs when endpoints
roam around different policy boundaries. A detailed explanation
about this is given in Section A.3.
Sathyanarayan Expires January 6, 2014 [Page 42]
Internet-Draft Auto Discovery VPNs July 2013
Requirement #7 :
When a shortcut between different gateways is created for a given
endpoint-to-endpoint session, the endpoint-to-endpoint
communication is not impacted by the shortcut. In other words,
this is transparent to the endpoints. More precisely, a new
shortcut partner is created on the two alternate gateways, spokes
or hubs. This modifies the communication path, but not the session
itself.
Requirement #8 :
This document does not explicitly detail all NAT scenarios, in
this version at least, but does provide two mechanisms that
address this. Because the hub gateway has performed IKE_AUTH with
both satellites, it can detect when one of the endpoint is behind
a NAT box while the other is not. In that case, the hub gateway
can instruct the endpoint that is behind the NAT to be the
initiator. When both potential partners are behind a NAT, the hub
can forgo the shortcut. Alternatively, existing protocols, such as
STUN (RFC 5389), can be considered for addressing this type of
scenarios.
Requirement #9 :
This document does not create a MIB. However, it does define
several events that can be reportable:
* The gateway suggests a shortcut
* The peer accepts or rejects a shortcut (the former involves a
change in policy)
* A shortcut times out (again involves a change in policy)
Requirement #10 :
The document is independent of administrative domains. One of the
properties that may be associated with administrative domains is a
Sathyanarayan Expires January 6, 2014 [Page 43]
Internet-Draft Auto Discovery VPNs July 2013
set of one or more trust anchors used to issue certificates for
VPN gateways and endpoints. To avoid the need for cross-trusting
these anchors, this document offers the option of using
dynamically-generated PSKs.
Requirement #11 :
While this document describes the syntax of SHORTCUT messages, it
makes no mandates about the policy for initiating shortcuts, or
the policy for accepting and rejecting shortcuts. Some endpoints
may agree to accept shortcuts from any peer, as long as the
Traffic Selectors are a subset of those that the SPD says should
go to that peer. Others may filter the shortcuts based on IKE ID,
so that they do not open tunnels to endpoints outside their
administrative domain. Future documents may profile such behavior.
Requirement #12 :
The Traffic Selectors in the SHORTCUT message can be used to
specify both multicast routing protocols, such as IGMP, and
multicast traffic through the use of multicast addresses in
selectors. With this, the SHORTCUT tunnels can be used to pass
multicast and multicast routing traffic.
Requirement #13 :
This document defines several events that can be logged and
monitored:
* The gateway suggests a shortcut
* The peer accepts or rejects a shortcut (the former involves a
change in policy)
* A shortcut times out (again involving a change in policy)
A status report listing active shortcuts for a particular gateway
is also possible and recommended for implementations.
Sathyanarayan Expires January 6, 2014 [Page 44]
Internet-Draft Auto Discovery VPNs July 2013
Requirement #14 :
L3VPNs all use some kind of transport-layer protocol. GRE uses
protocol number 43, IP-in-IP uses 4, and so on. Selectors for
these protocols can easily be specified using the TS payloads
included in SHORTCUTs. The additional information that may be
needed to set up a tunnel for each of these protocols is outside
the scope of this document.
Requirement #15 :
QoS policy is outside the scope of this document. However, the
mandate of RFC 5996 to allow multiple parallel SAs for different
classes of QoS applies to peers that a VPN box learns about
through SHORTCUT messages. This means that QoS policy can still be
enforced. If there are any additional requirements to be addressed
with respect to QoS, the SHORTCUT message structure can be
extended to support identified QoS attributes that should be
exchanged.
Authors' Addresses
Praveen Sathyanarayan
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
USA
Email: praveenys@juniper.net
Steve Hanna
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
USA
Email: shanna@juniper.net
Suresh Melam
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sathyanarayan Expires January 6, 2014 [Page 45]
Internet-Draft Auto Discovery VPNs July 2013
Sunnyvale, CA 94089
USA
Email: nmelam@juniper.net
Yoav Nir
Check Point Software Technologies Ltd.
5 Hasolelim st.
Tel Aviv 6789735
Israel
Email: ynir@checkpoint.com
Daniel Migault
Francetelecom - Orange
38 rue du General Leclerc
92794 Issy-les-Moulineaux Cedex 9
France
Email: mglt.ietf@gmail.com
Kostas Pentikousis
Huawei Technologies
Carnotstrasse 4
10587 Berlin
Germany
Email: k.pentikousis@huawei.com
Sathyanarayan Expires January 6, 2014 [Page 46]