< draft-ietf-ipsecme-ad-vpn-problem-03.txt   draft-ietf-ipsecme-ad-vpn-problem-04.txt >
IPsecME Working Group S. Hanna IPsecME Working Group S. Hanna
Internet-Draft Juniper Internet-Draft Juniper
Intended status: Informational V. Manral Intended status: Informational V. Manral
Expires: June 20, 2013 HP Expires: August 25, 2013 HP
December 17, 2012 February 21, 2013
Auto Discovery VPN Problem Statement and Requirements Auto Discovery VPN Problem Statement and Requirements
draft-ietf-ipsecme-ad-vpn-problem-03 draft-ietf-ipsecme-ad-vpn-problem-04
Abstract Abstract
This document describes the problem of enabling a large number of This document describes the problem of enabling a large number of
systems to communicate directly using IPsec to protect the traffic systems to communicate directly using IPsec to protect the traffic
between them. It then expands on the requirements, for such a between them. It then expands on the requirements, for such a
solution. solution.
Manual configuration of all possible tunnels is too cumbersome in Manual configuration of all possible tunnels is too cumbersome in
many such cases. In other cases the IP address of endpoints change many such cases. In other cases the IP address of endpoints change
or the endpoints may be behind NAT gateways, making static or the endpoints may be behind NAT gateways, making static
configuration impossible. The Auto Discovery VPN solution is configuration impossible. The Auto Discovery VPN solution will
chartered to address these requirements. address these requirements.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 20, 2013. This Internet-Draft will expire on August 25, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Conventions Used in This Document . . . . . . . . . . . . 4 1.2. Conventions Used in This Document . . . . . . . . . . . . 4
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Endpoint-to-Endpoint AD VPN Use Case . . . . . . . . . . . 5 2.1. Endpoint-to-Endpoint ADVPN Use Case . . . . . . . . . . . 5
2.2. Gateway-to-Gateway AD VPN Use Case . . . . . . . . . . . . 5 2.2. Gateway-to-Gateway ADVPN Use Case . . . . . . . . . . . . 5
2.3. Endpoint-to-Gateway AD VPN Use Case . . . . . . . . . . . 6 2.3. Endpoint-to-Gateway ADVPN Use Case . . . . . . . . . . . . 6
3. Inadequacy of Existing Solutions . . . . . . . . . . . . . . . 7 3. Inadequacy of Existing Solutions . . . . . . . . . . . . . . . 7
3.1. Exhaustive Configuration . . . . . . . . . . . . . . . . . 7 3.1. Exhaustive Configuration . . . . . . . . . . . . . . . . . 7
3.2. Star Topology . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Star Topology . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Proprietary Approaches . . . . . . . . . . . . . . . . . . 8 3.3. Proprietary Approaches . . . . . . . . . . . . . . . . . . 8
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Gateway and Endpoint Requirements . . . . . . . . . . . . 9 4.1. Gateway and Endpoint Requirements . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. Normative References . . . . . . . . . . . . . . . . . . . . . 15 8. Normative References . . . . . . . . . . . . . . . . . . . . . 15
skipping to change at page 3, line 40 skipping to change at page 3, line 40
contains several use cases that motivate this effort. contains several use cases that motivate this effort.
1.1. Terminology 1.1. Terminology
Endpoint - A device that implements IPsec for its own traffic but Endpoint - A device that implements IPsec for its own traffic but
does not act as a gateway. does not act as a gateway.
Gateway - A network device that implements IPsec to protect traffic Gateway - A network device that implements IPsec to protect traffic
flowing through the device. flowing through the device.
Point-to-Point - Direct communication between two parties without Point-to-Point - Communication between two parties without active
active participation (e.g. encryption or decryption) by any other participation (e.g. encryption or decryption) by any other parties.
parties.
Hub - The central point in a star topology/ dynamic full mesh Hub - The central point in a star topology/ dynamic full mesh
topology, or one of the central points in the full mesh style VPN, topology, or one of the central points in the full mesh style VPN,
i.e. gateway where multiple other hubs or spokes connect to. The i.e. gateway where multiple other hubs or spokes connect to. The
hubs usually forward traffic coming from encrypted links to other hubs usually forward traffic coming from encrypted links to other
encrypted links, i.e. there is no devices connected to it in clear. encrypted links, i.e. there are no devices connected to it in clear.
Spoke - The edge devices in the a star topology/ dynamic full mesh Spoke - The edge devices in a star topology/ dynamic full mesh
topology, or gateway which forwards traffic from multiple cleartext topology, or gateway which forwards traffic from multiple cleartext
devices to other hubs or spokes, and some of those other devices are devices to other hubs or spokes, and some of those other devices are
connected to it in clear (i.e. it encrypt data coming from cleartext connected to it in clear (i.e. it encrypts data coming from cleartext
device and forwards it to the AD VPN). devices and forwards it to the ADVPN).
ADVPN Peer - any member of an ADVPN including gateways, endpoints,
hub or spoke.
Star topology - This is the topology where there is direct Star topology - This is the topology where there is direct
connectivity only between the hub and spoke and communication between connectivity only between the hub and spoke and communication between
the 2 spokes happens through the hub. the 2 spokes happens through the hub.
Full Mesh topology - This is the topology where there is a direct Full Mesh topology - This is the topology where there is a direct
connectivity between every Spoke to every other Spoke directly, connectivity between every Spoke to every other Spoke directly,
without the traffic between the spokes having to be redirected without the traffic between the spokes having to be redirected
through an intermediate hub device. through an intermediate hub device.
skipping to change at page 5, line 11 skipping to change at page 5, line 11
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Use Cases 2. Use Cases
This section presents the key use cases for large-scale point-to- This section presents the key use cases for large-scale point-to-
point VPN. point VPN.
In all of these use cases, the participants (endpoints and gateways) In all of these use cases, the participants (endpoints and gateways)
may be from a single organization or from multiple organizations with may be from a single organization (administrative domain) or from
an established trust relationship. When multiple organizations are multiple organizations with an established trust relationship. When
involved, products from multiple vendors are employed so open multiple organizations are involved, products from multiple vendors
standards are needed to provide interoperability. Establishing are employed so open standards are needed to provide
communications between participants with no established trust interoperability. Establishing communications between participants
relationship is out of scope for this effort. with no established trust relationship is out of scope for this
effort.
2.1. Endpoint-to-Endpoint AD VPN Use Case 2.1. Endpoint-to-Endpoint ADVPN Use Case
Two endpoints wish to communicate securely via a direct, point-to- Two endpoints wish to communicate securely via a point-to-point
point Security Association (SA). Security Association (SA).
The need for secure endpoint to endpoint communications is often The need for secure endpoint to endpoint communications is often
driven by a need to employ high-bandwidth, low latency local driven by a need to employ high-bandwidth, low latency local
connectivity instead of using slow, expensive links to remote connectivity instead of using slow, expensive links to remote
gateways. For example, two users in close proximity may wish to gateways. For example, two users in close proximity may wish to
place a direct, secure video or voice call without needing to send place a direct, secure video or voice call without needing to send
the call through remote gateways, which would add latency to the the call through remote gateways, which would add latency to the
call, consume precious remote bandwidth, and increase overall costs. call, consume precious remote bandwidth, and increase overall costs.
Such a use case also enables connectivity when both endpoints are Such a use case also enables connectivity when both behind NAT
behind NAT gateways. Such use case should allow for seamless gateways. Such a use case ought to allow for seamless connectivity
connectivity even as endpoints roam, even if they are moving out from even as endpoints roam, even if they are moving out from behind a NAT
behind a NAT gateway, from behind one NAT gateway to behind another, gateway, from behind one NAT gateway to behind another, or from a
or from a standalone position to behind a NAT gateway. standalone position to behind a NAT gateway.
In a hub and spoke topology when two endpoints communicate, they must In a star topology when two endpoints communicate, they need a
use a mechanism for authentication, such that they do not expose them mechanism for authentication, such that they do not expose themselves
to impersonation by the other spoke endpoint. to impersonation by the other spoke endpoint.
2.2. Gateway-to-Gateway AD VPN Use Case 2.2. Gateway-to-Gateway ADVPN Use Case
A typical Enterprise traffic model follows a star topology, with the A typical Enterprise traffic model follows a star topology, with the
gateways connecting to each other using IPsec tunnels. gateways connecting to each other using IPsec tunnels.
However for the voice and other rich media traffic that requires a However for voice and other rich media traffic that requires a lot of
lot of bandwidth or is performance sensitive, the traffic tromboning bandwidth or is performance sensitive, the traffic tromboning to the
to the hub can create traffic bottlenecks on the hub and can lead to hub can create traffic bottlenecks on the hub and can lead to an
an increase in cost. A fully meshed solution would make best use of increase in cost. A fully meshed solution would make best use of the
the available network capacity and performance but the deployment of available network capacity and performance but the deployment of a
a fully meshed solution involves considerable configuration, fully meshed solution involves considerable configuration, especially
especially when a large number of nodes are involved. It is for this when a large number of nodes are involved. It is for this purpose
purpose spoke-to-spoke tunnels are dynamically created and torn-down. spoke-to-spoke tunnels are dynamically created and torn-down. For
the reasons of cost and manual error reduction, it is desired that
For the reasons of cost and manual error reduction, it is desired there be minimal configuration on each gateway.
that there be minimal configuration on each gateway.
The solution should work in cases where the endpoints are The solution ought to work in cases where the endpoints are in
administrated by separate management domains, albeit, ones that have different administrative domains, albeit, ones that have an existing
an existing trust relationship (for example two organisations who are trust relationship (for example two organisations who are
collaborating on a project, they may wish to join their networks, collaborating on a project, they may wish to join their networks,
whilst retaining independent control over configuration). It is whilst retaining independent control over configuration). It is
highly desirable that the solution works for the star, full mesh as highly desirable that the solution works for the star, full mesh as
well as dynamic full mesh topology. well as dynamic full mesh topology.
The solution should also address the case where gateways use dynamic The solution ought to also address the case where gateways use
IP addresses. dynamic IP addresses.
Additionally, the routing implications of gateway-to-gateway Additionally, the routing implications of gateway-to-gateway
communication must be addressed. In the simple case, selectors communication need to be addressed. In the simple case, selectors
provide sufficient information for a gateway to forward traffic provide sufficient information for a gateway to forward traffic
appropriately. In other cases, additional tunneling (e.g., GRE) and appropriately. In other cases, additional tunneling (e.g., Generic
routing (e.g., OSPF) protocols are run over IPsec tunnels, and the Routing Encapsulation - GRE) and routing (e.g., Open Shortest Path
configuration impact on those protocols must be considered. There is First - OSPF) protocols are run over IPsec tunnels, and the
also the case when L3VPNs operate over IPsec Tunnels. configuration impact on those protocols needs to be considered.
There is also the case when Layer-3 Virtual Private Networks (L3VPNs)
operate over IPsec Tunnels.
When two gateways communicate, they must use a mechanism for When two gateways communicate, they need to use a mechanism for
authentication, such that they do not expose themselves to the risk authentication, such that they do not expose themselves to the risk
of impersonation by the other entities. of impersonation by the other entities.
2.3. Endpoint-to-Gateway AD VPN Use Case 2.3. Endpoint-to-Gateway ADVPN Use Case
An endpoint should be able to use the most efficient gateway as it An endpoint ought to be able to use the most efficient gateway as it
roams in the internet. roams in the internet.
A mobile user roaming on the Internet may connect to a gateway, which 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 because of roaming is no longer the most efficient gateway to use
(reasons could be cost/ efficiency/ latency or some other factor). (reasons could be cost/ efficiency/ latency or some other factor).
The mobile user should be able to discover and then connect to the The mobile user ought to be able to discover and then connect to the
current most efficient gateway without having to reinitiate the current most efficient gateway without having to reinitiate the
connection. connection.
3. Inadequacy of Existing Solutions 3. Inadequacy of Existing Solutions
Several solutions exist for the problems described above. However, Several solutions exist for the problems described above. However,
none of these solutions is adequate, as described here. none of these solutions is adequate, as described here.
3.1. Exhaustive Configuration 3.1. Exhaustive Configuration
One simple solution is to configure all gateways and endpoints in One simple solution is to configure all gateways and endpoints in
advance with all the information needed to determine which gateway or advance with all the information needed to determine which gateway or
endpoint is optimal and to establish an SA with that 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 endpoint. However, this solution does not scale in a large network
with hundreds of thousands of gateways and endpoints, especially when with hundreds of thousands of gateways and endpoints, especially when
multiple organizations are involved and things are rapidly changing multiple administrative domains are involved and things are rapidly
(e.g. mobile endpoints). Such a solution is also limited by the changing (e.g. mobile endpoints). Such a solution is also limited by
smallest endpoint/ gateway, as the same exhaustive configuration is the smallest endpoint/ gateway, as the same exhaustive configuration
to be applied on all endpoints/ gateways. A more dynamic, secure and is to be applied on all endpoints/ gateways. A more dynamic, secure
scalable system for establishing SAs between gateways is needed. and scalable system for establishing SAs between gateways is needed.
3.2. Star Topology 3.2. Star Topology
The most common way to address a part of this this problem today is The most common way to address a part of this this problem today is
to use what has been termed a "star topology". In this case one or a 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 few gateways are defined as "hub gateways", while the rest of the
systems (whether endpoints or gateways) are defined as "spokes". The systems (whether endpoints or gateways) are defined as "spokes". The
spokes never connect to other spokes. They only open tunnels with spokes never connect to other spokes. They only open tunnels with
the hub gateways. Also for a large number of gateways in one the hub gateways. Also for a large number of gateways in one
administrative domain, one gateway may be defined as the hub, and the administrative domain, one gateway may be defined as the hub, and the
rest of the gateways and remote access clients connect only to that rest of the gateways and remote access clients connect only to that
gateway. gateway.
This solution however is complicated by the case when the spokes use This solution however is complicated by the case when the spokes use
dynamic IP addresses and DNS with dynamic updates must be used. It dynamic IP addresses and DNS with dynamic updates needs to be used.
is also desired that there is minimal to no configuration on the hub It is also desired that there is minimal to no configuration on the
as the number of spokes increases and new spokes are added and hub as the number of spokes increases and new spokes are added and
deleted randomly. deleted randomly.
Another problem with the star topology is that it creates a high load 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 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 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 bandwidth. A single packet in the hub-and-spoke scenario can be
encrypted and decrypted multiple times. It would be much preferable encrypted and decrypted multiple times. It would be much preferable
if these gateways and clients could initiate tunnels between them, if these gateways and clients could initiate tunnels between them,
bypassing the hub gateways. Additionally, the path bandwidth to bypassing the hub gateways. Additionally, the path bandwidth to
these hub gateways may be lower than that of the path between the these hub gateways may be lower than that of the path between the
skipping to change at page 9, line 30 skipping to change at page 9, line 30
Specifically, when evaluating potential proposals, we will compare Specifically, when evaluating potential proposals, we will compare
them by looking at how many endpoints or gateways must be them by looking at how many endpoints or gateways must be
reconfigured when a new gateway or endpoint is added, removed, or reconfigured when a new gateway or endpoint is added, removed, or
changed and how substantial this reconfiguration is, besides the changed and how substantial this reconfiguration is, besides the
amount of static configuration required. amount of static configuration required.
This requirement is driven by use cases 2.1 and 2.2 and by the This requirement is driven by use cases 2.1 and 2.2 and by the
scaling limitations pointed out in section 3.1. scaling limitations pointed out in section 3.1.
2. Gateways and endpoints MUST allow IPsec Tunnels to be setup 2. ADVPN peers MUST allow IPsec Tunnels to be setup with other
without any configuration changes, even when peer addresses get members of the ADVPN without any configuration changes, even when
updated every time the device comes up. This implies that SPD peer addresses get updated every time the device comes up. This
entries or other configuration based on peer IP address will need to implies that SPD entries or other configuration based on peer IP
be automatically updated, avoided, or handled in some manner to avoid address will need to be automatically updated, avoided, or handled in
a need to manually update policy whenever an address changes. 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. In many cases additional tunneling protocols (e.g. GRE) or 3. In many cases additional tunneling protocols (e.g. GRE) or
Routing protocols (e.g. OSPF) are run over the IPsec tunnels. Routing protocols (e.g. OSPF) are run over the IPsec tunnels.
Gateways MUST allow for the operation of tunneling and Routing Gateways MUST allow for the operation of tunneling and Routing
protocols operating over spoke-to-spoke IPsec Tunnels with minimal or protocols operating over spoke-to-spoke IPsec Tunnels with minimal or
no, configuration impact. The ADVPN solution SHOULD NOT increase the no, configuration impact. The ADVPN solution SHOULD NOT increase the
amount of information required to configure protocols running over amount of information required to configure protocols running over
IPsec tunnels. IPsec tunnels.
4. In the full mesh and dynamic full mesh topology, Spokes MUST 4. In the full mesh and dynamic full mesh topology, Spokes MUST
allow for direct communication with other spoke gateways and allow for direct communication with other spoke gateways and
endpoints. In the star topology mode, direct communication between endpoints. In the star topology mode, direct communication between
spokes MUST be disallowed. spokes MUST be disallowed.
This requirement is driven by use cases 2.1 and 2.2 and by the 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. limitations of a star topology pointed out in section 3.2.
5. One spoke MUST NOT be able to impersonate another spoke. 5. One ADVPN peer MUST NOT be able to impersonate another ADVPN
peer.
This requirement is driven by use case 2.1. Spokes become This requirement is driven by use case 2.1. ADVPN peers (especially
compromised fairly often. The compromise of one Spoke should not spokes) become compromised fairly often. The compromise of one ADVPN
affect the security of other endpoints. peer SHOULD NOT affect the security of other peers.
6. Gateways SHOULD allow for seamless handoff of sessions in case 6. Gateways SHOULD allow for seamless handoff of sessions in case
endpoints are roaming, even if they cross policy boundaries. This endpoints are roaming, even if they cross policy boundaries. This
would mean the data traffic is minimally affected even as the handoff would mean the data traffic is minimally affected even as the handoff
happens. External factors like firewall, NAT box will not be happens. External factors like firewall, NAT boxes will not be
considered part of this solution. considered part of this solution.
This requirement is driven by use case 2.1. Today's endpoints are This requirement is driven by use case 2.1. Today's endpoints are
mobile and transition often between different networks (from 4G to mobile and transition often between different networks (from 4G to
WiFi and among various WiFi networks). WiFi and among various WiFi networks).
7. Gateways SHOULD allow for easy handoff of a session to another 7. Gateways SHOULD allow for easy handoff of a session to another
gateway, to optimize latency, bandwidth, load balancing, gateway, to optimize latency, bandwidth, load balancing,
availability, or other factors, based on policy. availability, or other factors, based on policy.
This requirement is driven by use case 2.3. This requirement is driven by use case 2.3.
8. Gateways and endpoints MUST have the capability to participate in 8. Gateways and endpoints MUST have the capability to participate in
an AD VPN even when they are located behind NAT boxes. However, in an ADVPN even when they are located behind NAT boxes. However, in
some cases they may be deployed in such a way that they will not be some cases they may be deployed in such a way that they will not be
fully reachable behind a NAT box. It is especially difficult to fully reachable behind a NAT box. It is especially difficult to
handle cases where the Hub is behind a NAT box. Where the two handle cases where the Hub is behind a NAT box. Where the two
endpoints are both behind separate NATs, communication between these endpoints are both behind separate NATs, communication between these
spokes SHOULD be supported using workarounds such as port forwarding spokes SHOULD be supported using workarounds such as port forwarding
by the NAT or detecting when two spokes are behind uncooperative NATs by the NAT or detecting when two spokes are behind uncooperative NATs
and using a hub in that case. and using a hub in that case.
This requirement is driven by use cases 2.1 and 2.2. Endpoints are This requirement is driven by use cases 2.1 and 2.2. Endpoints are
often behind NATs and gateways sometimes are. IPsec should continue often behind NATs and gateways sometimes are. IPsec SHOULD continue
to work seamlessly regardless, using AD VPN techniques whenever to work seamlessly regardless, using ADVPN techniques whenever
possible and providing graceful fallback to hub and spoke techniques possible and providing graceful fallback to hub and spoke techniques
as needed. as needed.
9. Changes such as establishing a new IPsec SA SHOULD be reportable 9. Changes such as establishing a new IPsec SA SHOULD be reportable
and manageable. However, creating a MIB or other management and manageable. However, creating a MIB or other management
technique is not within scope for this effort. technique is not within scope for this effort.
This requirement is driven by manageability concerns for all the use This requirement is driven by manageability concerns for all the use
cases, especially use case 2.2. As IPsec networks become more cases, especially use case 2.2. As IPsec networks become more
dynamic, management tools become more essential. dynamic, management tools become more essential.
10. To support allied and federated environments, endpoints and 10. To support allied and federated environments, endpoints and
gateways from different organizations SHOULD be able to connect to gateways from different organizations SHOULD be able to connect to
each other. each other.
This requirement is driven by demand for all the use cases in
federated and allied environments.
11. The administrator of the ADVPN SHOULD allow for the 11. The administrator of the ADVPN SHOULD allow for the
configuration of a Star, Full mesh or a partial full mesh topology, configuration of a Star, Full mesh or a partial full mesh topology,
based on which tunnels are allowed to be setup. based on which tunnels are allowed to be setup.
This requirement is driven by demand for all the use cases in This requirement is driven by demand for all the use cases in
federated and allied environments. federated and allied environments.
12. The ADVPN solution SHOULD be able to scale for multicast 12. The ADVPN solution SHOULD be able to scale for multicast
traffic. traffic.
skipping to change at page 12, line 7 skipping to change at page 12, line 7
14. There is also the case when L3VPNs operate over IPsec Tunnels, 14. There is also the case when L3VPNs operate over IPsec Tunnels,
for example Provider Edge (PE) based VPN's. An ADVPN MUST support for example Provider Edge (PE) based VPN's. An ADVPN MUST support
L3VPN as an application protected by the IPsec Tunnels. L3VPN as an application protected by the IPsec Tunnels.
This requirement is driven by demand for all the use cases in This requirement is driven by demand for all the use cases in
federated and allied environments. federated and allied environments.
5. Security Considerations 5. Security Considerations
This is a Problem state and requirement document for the ADVPN This is a Problem statement and requirement document for the ADVPN
solution, and in itself does not introduce any new security concerns. solution, and in itself does not introduce any new security concerns.
The solution to the problems presented in this draft may involve The solution to the problems presented in this draft may involve
dynamic updates to databases defined by RFC 4301, such as the dynamic updates to databases defined by RFC 4301, such as the
Security Policy Database (SPD) or the Peer Authorization Database Security Policy Database (SPD) or the Peer Authorization Database
(PAD). (PAD).
RFC 4301 is silent about the way these databases are populated, and 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 it is implied that these databases are static and pre-configured by a
human. Allowing dynamic updates to these databases must be thought human. Allowing dynamic updates to these databases must be thought
out carefully, because it allows the protocol to alter the security out carefully, because it allows the protocol to alter the security
 End of changes. 35 change blocks. 
85 lines changed or deleted 91 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/