IPsecME Working Group                                           S. Hanna
Internet-Draft                                                   Juniper
Intended status: Informational                                 V. Manral
Expires: February 22, 2013                                            HP
                                                         August 21, 2012


         Auto Discovery VPN Problem Statement and Requirements
                  draft-ietf-ipsecme-ad-vpn-problem-00

Abstract

   This document describes the problem of enabling a large number of
   systems to communicate directly using IPsec to protect the traffic
   between them.  It then expands on the requirements, for such a
   solution.

   Manual configuration of all possible tunnels is too cumbersome in
   many such cases.  In other cases the IP address of endpoints change
   or the endpoints may be behind NAT gateways, making static
   configuration impossible.  The Auto Discovery VPN solution is
   chartered to address these requirements.

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).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on February 22, 2013.

Copyright Notice

   Copyright (c) 2012 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



Hanna & Manral          Expires February 22, 2013               [Page 1]


Internet-Draft             Auto Discovery VPN                August 2012


   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.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Conventions Used in This Document  . . . . . . . . . . . .  4
   2.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Endpoint-to-Endpoint AD VPN Use Case . . . . . . . . . . .  5
     2.2.  Gateway-to-Gateway AD VPN Use Case . . . . . . . . . . . .  5
     2.3.  Endpoint-to-Gateway AD VPN Use Case  . . . . . . . . . . .  6
   3.  Inadequacy of Existing Solutions . . . . . . . . . . . . . . .  7
     3.1.  Exhaustive Configuration . . . . . . . . . . . . . . . . .  7
     3.2.  Star Topology  . . . . . . . . . . . . . . . . . . . . . .  7
     3.3.  Proprietary Approaches . . . . . . . . . . . . . . . . . .  8
   4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  9
     4.1.  Gateway and Endpoint Requirements  . . . . . . . . . . . .  9
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15























Hanna & Manral          Expires February 22, 2013               [Page 2]


Internet-Draft             Auto Discovery VPN                August 2012


1.  Introduction

   IPsec [RFC4301] is used in several different cases, including tunnel-
   mode site-to-site VPNs and Remote Access VPNs.  Host to host
   communication employing transport mode also exists, but is far less
   commonly deployed.

   The subject of this document is the problem presented by large scale
   deployments of IPsec and the requirements on a solution to address
   the problem.  These may be a large collection of VPN gateways
   connecting various sites, a large number of remote endpoints
   connecting to a number of gateways or to each other, or a mix of the
   two.  The gateways and endpoints may belong to a single
   administrative domain or several domains with a trust relationship.

   Section 4.4 of RFC 4301 describes the major IPsec databases needed
   for IPsec processing.  It requires an extensive configuration for
   each tunnel, so manually configuring a system of many gateways and
   endpoints becomes infeasible and inflexible.

   The difficulty is that all the configuration mentioned in RFC 4301 is
   not superfluous.  IKE implementations need to know the identity and
   credentials of all possible peer systems, as well as the addresses of
   hosts and/or networks behind them.  A simplified mechanism for
   dynamically establishing point-to-point tunnels is needed.  Section 2
   contains several use cases that motivate this effort.

1.1.  Terminology

   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.

   Point-to-Point - Direct communication between two parties without
   active participation (e.g. encryption or decryption) by any other
   parties.

   Hub - The central point in a star topology, generally implemented in
   a gateway.

   Spoke - The edge devices in a star topology, implemented in endpoints
   or gateways.

   Security Association (SA) - Defined in [RFC4301].





Hanna & Manral          Expires February 22, 2013               [Page 3]


Internet-Draft             Auto Discovery VPN                August 2012


1.2.  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 [RFC2119].














































Hanna & Manral          Expires February 22, 2013               [Page 4]


Internet-Draft             Auto Discovery VPN                August 2012


2.  Use Cases

   This section presents the key use cases for large-scale point-to-
   point VPN.

   In all of these use cases, the participants (endpoints and gateways)
   may be from a single organization or from multiple organizations with
   an established trust relationship.  When multiple organizations are
   involved, products from multiple vendors are employed so open
   standards are needed to provide interoperability.  Establishing
   communications between participants with no established trust
   relationship is out of scope for this effort.

2.1.  Endpoint-to-Endpoint AD VPN Use Case

   Two endpoints wish to communicate securely via a direct, point-to-
   point Security Association (SA).

   The need for secure endpoint to endpoint communications is often
   driven by a need to employ high-bandwidth, low latency local
   connectivity instead of using slow, expensive links to remote
   gateways.  For example, two users in close proximity may wish to
   place a direct, secure video or voice call without needing to send
   the call through remote gateways, which would add latency to the
   call, consume precious remote bandwidth, and increase overall costs.
   Such a use case also enables connectivity when both endpoints are
   behind NAT gateways.  Such use case should allow for seamless
   connectivity even as endpoints roam, even if they are moving out from
   behind a gateway, from behind one gateway to behind another, or from
   a standalone position to behind a gateway.

   In a hub and spoke topology when two endpoints communicate, they must
   use a mechanism for authentication, such that they do not expose them
   to impersonation by the other spoke endpoint.

2.2.  Gateway-to-Gateway AD VPN Use Case

   A typical Enterprise traffic model is hub and spoke, with the
   gateways connecting to each other using IPsec tunnels.

   However for the voice and other rich media traffic that occupies a
   lot of bandwidth and the traffic tromboning to the hub can create
   traffic bottlenecks on the hub and can lead to a increase cost.  It
   is for this purpose spoke-to-spoke tunnels are dynamically created
   and torn-down.

   The spoke gateways can themselves come up and down, getting different
   IP addresses in the process, making th static configuration



Hanna & Manral          Expires February 22, 2013               [Page 5]


Internet-Draft             Auto Discovery VPN                August 2012


   impossible.

   Also for the reasons of cost and manual error reduction, it is
   desired there be minimal or even no configuration on the hub as a new
   spoke Router is added or removed.

   In a hub and spoke topology when two spoke gateways communicate, they
   must use a mechanism for authentication, such that they do not expose
   them to impersonation by the other gateways spoke.

2.3.  Endpoint-to-Gateway AD VPN Use Case

   An endpoint should be able to use the most efficient gateway as it
   roams in the internet.

   A mobile user roaming on the Internet may connect to a gateway, which
   because of roaming is no longer the most efficient gateway to use
   (reasons could be cost/ efficiency/ latency or some other factor).
   The mobile user should be able to discover and then connect to the
   current most efficient gateway without having to reinitiate the
   connection.






























Hanna & Manral          Expires February 22, 2013               [Page 6]


Internet-Draft             Auto Discovery VPN                August 2012


3.  Inadequacy of Existing Solutions

   Several solutions exist for the problems described above.  However,
   none of these solutions is adequate, as described here.

3.1.  Exhaustive Configuration

   One simple solution is to configure all gateways and endpoints in
   advance with all the information needed to determine which gateway or
   endpoint is optimal and to establish an SA with that gateway or
   endpoint.  However, this solution does not scale in a large network
   with hundreds of thousands of gateways and endpoints, especially when
   multiple organizations are involved and things are rapidly changing
   (e.g. mobile endpoints).  Such a solution is also limited by the
   smallest endpoint/ gateway, as the same exhaustive configuration is
   to be applied on all endpoints/ gateways.  A more dynamic, secure and
   scalable system for establishing SAs between gateways is needed.

3.2.  Star Topology

   The most common way to address this problem today is to use what has
   been termed a "star topology".  In this case one or a few gateways
   are defined as "hub gateways", while the rest of the systems (whether
   endpoints or gateways) are defined as "spokes".  The spokes never
   connect to other spokes.  They only open tunnels with the hub
   gateways.  Also for a large number of gateways in one administrative
   domain, one gateway may be defined as the hub, and the rest of the
   gateways and remote access clients connect only to that gateway.

   This solution however does not work when the spokes get dynamic IP
   address which the "hub gateways" cannot be configured with.  It is
   also desired that there is minimal to no configuration on the hub as
   the number of spokes increases and new spokes are added and deleted
   randomly.

   Another problem with the star topology is that it creates a high load
   on the hub gateways as well as on the connection between the spokes
   and the hub.  This load is both in processing power and in network
   bandwidth.  A single packet in the hub-and-spoke scenario can be
   encrypted and decrypted three times.  It would be much preferable if
   these gateways and clients could initiate tunnels between them,
   bypassing the hub gateways.  Additionally, the path bandwidth to
   these hub gateways may be lower than that of the path between the
   spokes.  For example, two remote access users may be in the same
   building with high-speed wifi (for example, at an IETF meeting).
   Channeling their conversation through the hub gateways of their
   respective employers seems extremely wasteful, as well as having
   lower bandwidth.



Hanna & Manral          Expires February 22, 2013               [Page 7]


Internet-Draft             Auto Discovery VPN                August 2012


   The challenge is to build a large scale, IPsec protected networks
   that can dynamically change with minimum administrative overhead.

3.3.  Proprietary Approaches

   Several vendors offer proprietary solutions to these problems.
   However, these solutions offer no interoperability between equipment
   from one vendor and another.  This means that they are generally
   restricted to use within one organization, and it is harder to move
   off such solutions as the features are not standardized.  Besides
   multiple organizations cannot be expected to all choose the same
   equipment vendor.







































Hanna & Manral          Expires February 22, 2013               [Page 8]


Internet-Draft             Auto Discovery VPN                August 2012


4.  Requirements

   This section is currently being updated and hence under flux.

4.1.  Gateway and Endpoint Requirements

   1.  For any network topology (whether hub-and-spoke or Full Mesh)
   gateways and endpoints MUST minimize configuration changes when a new
   gateway or endpoint is added, removed or changed.  Specifically, when
   evaluating potential solutions, we will compare them by looking at
   how many endpoints or gateways must be reconfigured when a new
   gateway or endpoint is added, removed, or changed and how substantial
   this reconfiguration is.

   This requirement is driven by use cases 2.1 and 2.2 and by the
   scaling limitations pointed out in section 3.1.

   2.  Gateways and endpoints MUST allow IPsec Tunnels to be setup
   without any configuration changes, even when peer addresses get
   updated every time the device comes up.  This implies that SPD
   entries or other configuration based on peer IP address will need to
   be automatically updated, avoided, or handled in some manner to avoid
   a need to manually update policy whenever an address changes.

   This requirement is driven by use cases 2.1 and 2.2 and by the
   scaling limitations pointed out in section 3.1.

   3.  Gateways MUST allow tunnel binding, such that applications like
   Routing using the tunnels can work seamlessly without any updates to
   the higher level application configuration i.e.  OSPF configuration.

   4.  In a hub-and-spoke topology, spoke gateways and endpoints MUST
   allow for direct communication with other spoke gateways and
   endpoints.

   This requirement is driven by use cases 2.1 and 2.2 and by the
   limitations of a star topology pointed out in section 3.2.

   5.  One spoke MUST NOT be able to impersonate another spoke.

   This requirement is driven by use case 2.1.  Endpoints become
   compromised fairly often.  The compromise of one endpoint should not
   affect the security of other endpoints.

   6.  Gateways SHOULD allow for easy handoff of sessions in case
   endpoints are roaming, even if they cross policy boundaries.  This
   means that TCP session breakage and packet loss should be avoided,
   when possible.



Hanna & Manral          Expires February 22, 2013               [Page 9]


Internet-Draft             Auto Discovery VPN                August 2012


   This requirement is driven by use case 2.1.  Today's endpoints are
   mobile and transition often between different networks (from 4G to
   WiFi and among various WiFi networks).

   7.  Gateways SHOULD allow for easy handoff of a session to another
   gateway, to optimize latency, bandwidth, load balancing,
   availability, or other factors, based on policy.

   This requirement is driven by use case 2.3.

   8.  Gateways and endpoints MUST be able to work when they are behind
   NAT boxes.  However, it is especially difficult to handle cases where
   gateways are behind NATs and where two endpoints are both behind
   separate NATs.  In those cases, workarounds MAY be used such as port
   forwarding by the NAT or detecting when two spokes are behind
   uncooperative NATs and using a hub in that case.

   This requirement is driven by use cases 2.1 and 2.2.  Endpoints are
   often behind NATs and gateways sometimes are.  IPsec should continue
   to work seamlessly regardless, using AD VPN techniques whenever
   possible and providing graceful fallback to hub and spoke techniques
   as needed.

   9.  Changes such as establishing a new IPsec SA SHOULD be reportable
   and manageable.  However, creating a MIB or other management
   technique is not within scope for this effort.

   This requirement is driven by manageability concerns for all the use
   cases, especially use case 2.2.  As IPsec networks become more
   dynamic, management tools become more essential.

   10.  To support allied and federated environments, endpoints and
   gateways from different organizations SHOULD be able to connect to
   each other.

   This requirement is driven by demand for all the use cases in
   federated and allied environments.

   11.  The solution SHOULD allow administrators the ability to
   configure a variety of permissible topologies: full mesh, partial
   mesh, star, etc.  They should be able to set different topologies for
   different types of traffic: voice, video, web, email, etc.

   This requirement is driven by counter-balancing requirements to log
   or control traffic of certain types (e.g. email) while ensuring
   efficient, low-latencies flows of other types (e.g. video).





Hanna & Manral          Expires February 22, 2013              [Page 10]


Internet-Draft             Auto Discovery VPN                August 2012


5.  Security Considerations

   The solution to the problems presented in this draft may involve
   dynamic updates to databases defined by RFC 4301, such as the
   Security Policy Database (SPD) or the Peer Authorization Database
   (PAD).

   RFC 4301 is silent about the way these databases are populated, and
   it is implied that these databases are static and pre-configured by a
   human.  Allowing dynamic updates to these databases must be thought
   out carefully, because it allows the protocol to alter the security
   policy that the IPsec endpoints implement.

   One obvious attack to watch out for is stealing traffic to a
   particular site.  The IP address for www.example.com is 192.0.2.10.
   If we add an entry to an IPsec endpoint's SPD that says that traffic
   to 192.0.2.10 is protected through peer Gw-Mallory, then this allows
   Gw-Mallory to either pretend to be www.example.com or to proxy and
   read all traffic to that site.  Updates to this database requires a
   clear trust model.

   More to be added.





























Hanna & Manral          Expires February 22, 2013              [Page 11]


Internet-Draft             Auto Discovery VPN                August 2012


6.  IANA Considerations

   No actions are required from IANA for this informational document.
















































Hanna & Manral          Expires February 22, 2013              [Page 12]


Internet-Draft             Auto Discovery VPN                August 2012


7.  Acknowledgements

   Many people have contributed to the development of this problem
   statement and many more will probably do so before we are done with
   it.  While we cannot thank all contributors, some have played an
   especially prominent role.  Yoav Nir, Yaron Scheffer, Jorge Coronel
   Mendoza, Chris Ulliott, and John Veizades wrote the document upon
   which this draft was based.  Geoffrey Huang, Suresh Melam, Praveen
   Sathyanarayan, Andreas Steffen, and Brian Weis provided essential
   input.









































Hanna & Manral          Expires February 22, 2013              [Page 13]


Internet-Draft             Auto Discovery VPN                August 2012


8.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.












































Hanna & Manral          Expires February 22, 2013              [Page 14]


Internet-Draft             Auto Discovery VPN                August 2012


Authors' Addresses

   Steve Hanna
   Juniper Networks, Inc.
   1194 N. Mathilda Ave.
   Sunnyvale, CA  94089
   USA

   Email: shanna@juniper.net


   Vishwas Manral
   Hewlett-Packard Co.
   19111 Pruneridge Ave.
   Cupertino, CA  95113
   USA

   Email: vishwas.manral@hp.com

































Hanna & Manral          Expires February 22, 2013              [Page 15]