|
|
|
|
|
|
|
|
|
|
| Last Update: Jul 21, 2010
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC5685
11/2009
(15 p.)
pdf(2p)
|
V. Devarapalli
K. Weniger |
|
Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2) |
|
The Internet Key Exchange Protocol version 2 (IKEv2) is a protocol
for setting up Virtual Private Network (VPN) tunnels from a remote
location to a gateway so that the VPN client can access services in
the network behind the gateway. This document defines an IKEv2
extension that allows an overloaded VPN gateway or a VPN gateway that
is being shut down for maintenance to redirect the VPN client to
attach to another gateway. The proposed mechanism can also be used
in Mobile IPv6 to enable the home agent to redirect the mobile node
to another home agent.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC5723
01/2010
(26 p.)
pdf(2p)
|
Y. Sheffer
H. Tschofenig |
|
Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption |
The Internet Key Exchange version 2 (IKEv2) protocol has a certain
computational and communication overhead with respect to the number
of round trips required and the cryptographic operations involved.
In remote access situations, the Extensible Authentication Protocol
(EAP) is used for authentication, which adds several more round trips
and consequently latency.
To re-establish security associations (SAs) upon a failure recovery
condition is time consuming especially when an IPsec peer (such as a
VPN gateway) needs to re-establish a large number of SAs with various
endpoints. A high number of concurrent sessions might cause
additional problems for an IPsec peer during SA re-establishment.
In order to avoid the need to re-run the key exchange protocol from
scratch, it would be useful to provide an efficient way to resume an
IKE/IPsec session. This document proposes an extension to IKEv2 that
allows a client to re-establish an IKE SA with a gateway in a highly
efficient manner, utilizing a previously established IKE SA.
A client can reconnect to a gateway from which it was disconnected.
The proposed approach encodes partial IKE state into an opaque ticket,
which can be stored on the client or in a centralized store, and is
later made available to the IKEv2 responder for re-authentication. We
use the term ticket to refer to the opaque data that is created by the
IKEv2 responder. This document does not specify the format of the
ticket but examples are provided.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC5739
02/2010
(32 p.)
pdf(2p)
|
P. Eronen
J. Laganier
C. Madson |
|
IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2) |
|
When Internet Key Exchange Protocol version 2 (IKEv2) is used for
remote VPN access (client to VPN gateway), the gateway assigns the
client an IP address from the internal network using IKEv2
configuration payloads. The configuration payloads specified in
RFC 4306 work well for IPv4 but make it difficult to use certain features
of IPv6. This document specifies new configuration attributes for
IKEv2 that allows the VPN gateway to assign IPv6 prefixes to clients,
enabling all features of IPv6 to be used with the client-gateway
"virtual link".
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC5840
04/2010
(15 p.)
pdf(2p)
|
K. Grewal
G. Montenegro
M. Bhatia |
|
Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility |
|
This document describes the Wrapped Encapsulating Security
Payload (WESP) protocol, which builds on the Encapsulating
Security Payload (ESP) RFC 4303 and is designed to allow
intermediate devices to (1) ascertain if data confidentiality is
being employed within ESP, and if not, (2) inspect the IPsec
packets for network monitoring and access control functions.
Currently, in the IPsec ESP standard, there is no deterministic
way to differentiate between encrypted and unencrypted payloads
by simply examining a packet. This poses certain challenges to
the intermediate devices that need to deep inspect the packet
before making a decision on what should be done with that packet
(Inspect and/or Allow/Drop). The mechanism described in this
document can be used to easily disambiguate integrity-only ESP
from ESP-encrypted packets, without compromising on the security
provided by ESP.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC5879
05/2010
(32 p.)
pdf(2p)
|
T. Kivinen
D. McDonald |
|
Heuristics for Detecting ESP-NULL Packets |
|
This document describes a set of heuristics for distinguishing IPsec
ESP-NULL (Encapsulating Security Payload without encryption) packets
from encrypted ESP packets. These heuristics can be used on
intermediate devices, like traffic analyzers, and deep-inspection
engines, to quickly decide whether or not a given packet flow is
encrypted, i.e., whether or not it can be inspected. Use of these
heuristics does not require any changes made on existing IPsec hosts
that are compliant with RFC 4303.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
