IKEv2 Security Gateway Discovery
draft-mglt-ipsecme-security-gateway-discovery-00
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Authors | Daniel Migault , Kostas Pentikousis | ||
| Last updated | 2013-08-18 (Latest revision 2013-02-14) | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
Modern Virtual Private Network (VPN) services are typically deployed using several security gateways and are frequently accessed over a wireless network. There are several reasons for such a deployment ranging from enhancing system resilience to improving performance. For example, in order to handle traffic efficiently and reduce the burden in the core network, the VPN service may be implemented in a distributed manner using multiple Security Gateways. A mobile VPN End User is attached to one of them using a WLAN interface and over time is likely to change its Security Gateway of attachment. In this case, in order to optimize the overall user Quality of Experience (QoE), a VPN End User should select the next most appropriate Security Gateway based on the characteristics of the available Security Gateways. This draft specifies how a VPN End User can securely collect information about Security Gateways in its network neighborhood in order to optimize its VPN experience.
Authors
Daniel Migault
Kostas Pentikousis
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)