One document matched: draft-duffy-ppvpn-ipsec-vlink-00.txt
Network Working Group M. Duffy
Internet Draft Quarry Technologies
Expires: April 2003 October 2002
Framework for IPsec Protected Virtual Links for PPVPNs
draft-duffy-ppvpn-ipsec-vlink-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Abstract
This memo explores some choices that arise when IPsec is to be used
to implement secure "virtual links" interconnecting customer premises
VPN devices and/or network based virtual routers. The main focus is
on the network based cases.
Requirements are proposed and some relevant aspects of the IPsec
protocol suite are discussed. A number of different protocol
architectures for virtual links are then evaluated.
This memo is informational in nature; it is intended that it will
focus discussion toward a standard in this area.
Duffy Expires - April 2003 [Page 1]
Internet Draft IPsec Protected Virtual Links October 2002
Table of Contents
1. Introduction...................................................2
2. Terminology Used in This Document..............................3
3. Virtual Link Objectives........................................3
4. Protocol Functions Needed to Implement Virtual Links...........4
5. IPsec Considerations...........................................5
5.1 Tunnel Mode vs. Transport Mode.............................5
5.2 The Security Policy Database (SPD).........................5
5.3 VPN Context Correlation....................................7
6. Some Possible Protocol Architectures...........................8
6.1 Tunnel Mode SA as Virtual Link.............................8
6.2 Shared IP-in-IP Tunnel with Transport Mode IPsec...........9
6.3 Distinct IP-in-IP Tunnel with Transport Mode IPsec.........9
6.4 GRE Tunnel with Transport Mode IPsec......................10
6.5 MPLS Tunnel with Transport Mode IPsec.....................11
6.6 L2TP with Transport Mode IPsec............................11
7. Recommendation................................................12
8. Security Considerations.......................................12
9. References....................................................13
9.1 Normative References......................................13
9.2 Informative References....................................13
10. Summary for Sub-IP Related Internet Drafts...................14
Author's Addresses...............................................14
Full Copyright Statement.........................................14
1. Introduction
A number of different technologies have been identified for
implementing Provider Provisioned Virtual Private Networks (PPVPNs).
Among the options for providing VPN services at layer 3 are virtual
router based VPNs, CE-based IPsec VPNs, and BGP/MPLS VPNs. All three
types can capitalize on the creation of IPsec-protected virtual links
between VPN-aware nodes at the edge of the network (either PE or CE
based). Both the virtual router approach and the dynamically routed
flavor of CE-based IPsec approach require a virtual link mechanism,
while the reach of BGP/MPLS VPNs can be extended by using virtual
links to include remote sites.
Although all these VPN types can use virtual links that carry IP
packets across an IP network the VR-based L3 VPN overlay environment
[VR-VPN] is the most demanding in terms of a solution. This is
because the VR approach requires a virtual link solution that
simultaneously supports multiple links for multiple contexts, between
a given pair of devices.
Duffy Expires - April 2003 [Page 2]
Internet Draft IPsec Protected Virtual Links October 2002
A number of drafts have been published dealing with the CE-CE case
but there has not been much discussion of the VR (multi-context)
case.
This memo assumes some familiarity with the IPsec protocol suite
including [IPSEC] and [IKE].
The principal content of this memo is organized as follows: Section
3 lists some desirable properties of a virtual link mechanism.
Section 4 describes protocol functions a virtual link system must
perform. Section 5 explains some aspects of IPsec that must be
considered in using IPsec as a component of a secure virtual link
solution. Section 6 presents and evaluates a number of potential
protocol architectures.
2. Terminology Used in This Document
CE: Customer Edge router
PE: Provider Edge router
Tunnel ingress node: A system or device that transmits packets
into a tunnel
Tunnel egress node: A system or device that receives packets from
a tunnel
Tunnel endpoint: Either a tunnel ingress node or a tunnel
egress node
3. Virtual Link Objectives
For purposes of this memo we define a virtual link as a construct
that provides a point-to-point link layer service implemented over an
IP network. Each end of a virtual link terminates as an IP interface
of a router or virtual router (VR), which may form routing
adjacencies and forward IP packets over the link.
The following are viewed as important properties for virtual links:
- Support multiple independent virtual links between a given pair
of systems (e.g. PE devices) serving different contexts (e.g.
different VR pairs).
- Provide IPsec security services for each virtual link including
integrity, data origin authentication, protection against replays,
and confidentiality.
- Provide a choice of using IPsec or not, with per-VPN-context and
per-remote-PE granularity.
Duffy Expires - April 2003 [Page 3]
Internet Draft IPsec Protected Virtual Links October 2002
- Support interoperation of network-based (PE-based) virtual
routers with Provider Provisioned CE based IPsec VPN devices.
- Operate in systems that simultaneously use IPsec for other
purposes.
- Require no new protocol development and minimum extensions to
existing protocols.
4. Protocol Functions Needed to Implement Virtual Links
Virtual links are implemented using tunneling technologies. A
tunnel, by means of encapsulation, provides isolation for packets
sent through it. It thus allows packets to traverse domains they
could perhaps not traverse natively, or to be delivered to
intermediate destinations not implied by their destination addresses.
Besides encapsulation, tunneling for virtual links requires:
- Multiplexing. The ability to support and distinguish multiple
logical streams of data within a tunnel and/or the ability to support
and distinguish multiple tunnels between a pair of tunnel endpoints.
In fact, the two abilities are logically equivalent and differ only
by which entity one applies the term "tunnel" to. In the remainder
of this document we shall use the word tunnel in the latter sense
i.e. a tunnel carries packets for one VPN context but there may be
multiple tunnels between a given pair of tunnel endpoints.
- Tunnel management (setup/maintenance/teardown) signalling. This
allows the tunnel endpoints to be explicitly aware of whether a
particular tunnel is present or not and perhaps whether it has
connectivity (liveliness). In cases where the tunnel mechanism
itself does not provide liveliness detection, dynamic routing
protocols, if used, can provide this function.
- VPN context correlation. The ability to determine, at the
tunnel egress node, what application and context each received packet
is intended for. The term "application" here refers to any one of
perhaps several functional areas in the node that use tunnels, e.g.
virtual link, IPsec security gateway, etc. The "context," for the
virtual link application, is a particular VPN i.e. as identified by a
[VPN-ID]. Correlation may be done packet by packet in a
connectionless manner, however this is likely to impose a high
overhead cost. An alternative, available with connection-oriented
tunneling technologies, is to establish the correlation on a per-
tunnel basis at tunnel setup time, binding the context identification
Duffy Expires - April 2003 [Page 4]
Internet Draft IPsec Protected Virtual Links October 2002
to a more compact multiplexing field that is transmitted on a per-
packet basis.
Support for Path MTU Discovery and for Quality of Service (QoS) on
virtual links are important but are not considered in this memo.
Reliable or in-order delivery are not required.
5. IPsec Considerations
This section explores a number of choices and issues that must be
addressed to use IPsec for virtual links. Although these are
separate issues they interrelate heavily with one another.
5.1 Tunnel Mode vs. Transport Mode
IPsec may be used in two different encapsulation modes: IPsec tunnel
mode provides in-IP tunneling as a package deal with the security
protocol. IPsec transport mode does not provide tunneling. In a
virtual link application, IPsec transport mode is of necessity used
in conjunction with some other in-IP tunneling protocol for an
overall solution.
At first glance tunnel mode seems attractive because it appears to be
a one stop shop providing encapsulation, multiplexing, and (via IKE)
explicit tunnel management. However, there are difficulties with the
semantics of the security policy and with VPN context correlation, as
described in the following subsections.
Decoupling tunneling and IPsec and providing them independently
yields greater modularity, generally recognized as a Good Thing.
Keeping tunneling and IPsec separate also allows for selective use of
IPsec since the needed virtual link functions of encapsulation,
multiplexing, tunnel management, and correlation are provided
separately and there is no reliance on IPsec for these services.
5.2 The Security Policy Database (SPD)
IPsec uses the IKE protocol to negotiate Security Associations (SAs)
and their keying. A fundamental aspect of this is the Quick Mode
negotiation, via Client IDs, of the access control policy (packet
selectors) for each IPsec SA. IPsec devices base this negotiation on
their provisioned Security Policy Databases (SPDs). A nominally
separate SPD exists for each interface on which IPsec is to run.
The access control policy is one of the basic security services
provided by IPsec. It is packet classification against this policy
that controls which packets are sent on, or must be received on, a
Duffy Expires - April 2003 [Page 5]
Internet Draft IPsec Protected Virtual Links October 2002
given SA. By contrast, when using virtual links, we generally want
to use a routing decision to determine which packets are sent on a
given virtual link, and we generally don't require validation that
packets were received from a "correct" link. In a sense, we want a
service that is like link-level encryption (, authentication, etc.)
for the virtual link. Thus, we have a mismatch between the way IPsec
works and the way we want virtual links to work. The nature and
extent of this mismatch depends in large part of the relationship
between IPsec SAs and virtual links: *Is* a tunnel mode SA the
virtual link, or does the virtual link have an existence of its own
to which transport mode IPsec may be applied?
5.2.1 Tunnel Mode IPsec and the SPD
If IPsec tunnel mode is used to implement a virtual link we would
expect the negotiated selectors to apply to the headers of the "inner
packets" e.g. the packets of the VPN. Generally, these packets will
be assigned to virtual links based on dynamic routing state and
therefore the set of packets to be sent over a particular virtual
link are not known a priori. From the point of view of IPsec policy,
this is essentially an arbitrary set of packets. What is needed then
is an SA that will carry any packets -- an SA whose selectors are all
wildcards. However, when multiple virtual links are required between
the same pair of tunnel endpoints (e.g. for multiple VPN contexts)
multiple SAs with the same wildcard client IDs must be negotiated.
Classic IPsec will not generally negotiate multiple SAs out of a
given SPD, those SAs having the same client IDs, since in the classic
case it has no way to determine which to use for a given outgoing
packet. Resolving this requires a slightly liberal interpretation of
IPsec, to have an SPD per virtual interface. Unfortunately, it then
becomes problematic for the IKE responder to determine which SPD to
evaluate an incoming proposal against; this is discussed in section
5.3.
5.2.2 Transport Mode IPsec and the SPD
If another protocol is used to implement the tunnels, with IPsec
applied in transport mode, we have essentially positioned the routing
and tunneling a layer above IPsec. In this case then the negotiated
IPsec selectors might reasonably be expected to apply to the packet
headers of the "outer packets" of the tunnel e.g. the GRE, L2TP, IP-
in-IP, etc. packets. The selectors match the endpoint addresses of
the tunnel and the tunnel protocol. There is no need to create
multiple SAs with the same client IDs, and no need for an SPD per
virtual interface.
This would seem to be a better match with the access control
functions of IPsec. However, if IPsec is controlled solely by
Duffy Expires - April 2003 [Page 6]
Internet Draft IPsec Protected Virtual Links October 2002
evaluating SPD policy against already-encapsulated packets, it cannot
provide much in the way of differentiated protection. In particular,
if the tunneling mechanism used is such that all tunnels between a
pair of systems have the same outer addresses, protocol, and ports,
then we cannot use the SPD to meet the goal of selecting IPsec on a
per-VPN basis.
5.2.3 A Hybrid Transport Mode Approach
Another possibility is to use a separate tunneling protocol with
transport mode IPsec, but negotiate and apply IPsec policy on the
"inner" packets. This opens the possibility for a richer range of
differentiated protection than the basic transport mode approach (in
which the selectors of packets in the tunnel are invariant).
However, this requires a very liberal interpretation of IPsec. As
such, it may be difficult to implement in some environments and it
may engender strong objections from the IPsec community.
5.3 VPN Context Correlation
For a system that is maintaining multiple contexts (e.g. multiple
virtual routers) and which may therefore maintain multiple virtual
links to a given remote system, it is essential that there be a way
to determine at the downstream end which links are for which
contexts. In the cases where IPsec SAs are used to multiplex the
virtual links this implies a need to determine which of potentially
multiple IPsec applications in the system (e.g. Security Gateway
service, IPsec-protected virtual links, etc.) a given SA is for. For
those SAs intended for virtual links, it is further necessary to
associate them with the correct VPN context.
Several recent Internet-Drafts ([CE-VPN], [TOUCH], [KNIGHT]) have
discussed this area but they are all focused on the CE-based VPN case
and do not address the multiplexing of multiple contexts between a
pair of PE devices. They do address the question of determining
whether an SA is for a virtual link or not. These drafts propose
adopting the following convention: an IKE proposal for transport
mode IPsec for protocol IP-in-IP and client IP addresses that match
the IKE endpoint addresses implies that the tunnel will be viewed as
a virtual link and routing adjacencies may be formed on it. This
convention is expedient, but it is implicit rather than explicit, and
it relies on an expectation that existing systems are not already
using such proposals under other circumstances. Also, it is not
extensible to cover other possible applications.
There are several ways that correlation info (e.g. a VPN-ID) could be
passed explicitly from the IKE initiator (which presumably knows it)
to the responder (which needs to know it) and bound to a particular
Duffy Expires - April 2003 [Page 7]
Internet Draft IPsec Protected Virtual Links October 2002
SA they negotiate. Vendor specific payloads could be defined to
carry the application identifier (e.g. virtual link) and the context
(e.g. VPN-ID) in IKE. However, vendor specific payloads are not a
good approach to standardization. New standardized IKE payloads
could be defined, but this is unlikely to happen for IKE given the
current focus of the IPsec working group on developing its successor.
The now-expired [LORDELLO] proposed defining such new payloads within
a new ISAKMP Domain of Interpretation (DOI).
It is also possible to pass the correlation info implicitly from
initiator to responder, by addressing the IKE proposal to different
IP addresses belonging to the responder and/or by presenting
different initiator addresses or IKE identities belonging to the
initiator. This approach has a number of disadvantages: it is crude,
and it requires the maintenance of a tunnel endpoint IP address per
VPN context. Even at that it does not convey a VPN identification in
absolute terms; rather, coordinated provisioning is still needed at
both ends to establish which IP address corresponds with which VPN-
ID, etc. Furthermore, the scalability is severely decreased because
this forces a separate (and computationally expensive) ISAKMP SA to
be needed for each context.
6. Some Possible Protocol Architectures
This section presents six different approaches to constructing
virtual links secured by IPsec. Each is evaluated against the
requirements and considerations described in the preceding sections.
6.1 Tunnel Mode SA as Virtual Link
This approach uses a tunnel mode IPsec SA to realize each virtual
link. Multiple virtual links between a pair of systems, serving
different contexts, may be negotiated under a single ISAKMP SA. The
client IDs are all-wildcarded.
Each IPsec SA is bound to a VPN-ID through a payload exchanged during
the Quick Mode negotiation.
Pros:
. This approach leverages the IKE Quick Mode as a tunnel management
protocol.
Cons:
. There is no IPsec-less (unsecured) operation available since it
relies on IPsec for tunneling.
Duffy Expires - April 2003 [Page 8]
Internet Draft IPsec Protected Virtual Links October 2002
. The current IKE standard does not define a payload to convey a
VPN-ID; this would require a vendor-specific payload, IKE
extension, etc.
. Requires the tunnel end points to support negotiating multiple
IPsec SAs with the same client IDs.
. Unlikely to interoperate with CE-based devices.
6.2 Shared IP-in-IP Tunnel with Transport Mode IPsec
This approach uses IP-in-IP tunneling [IP-IP] and a distinct
transport mode IPsec SA to realize each virtual link. Multiple
virtual links between a pair of systems use the same IP-in-IP tunnel
(i.e. the same endpoint addresses). A single ISAKMP SA between a
pair of systems is used.
Each virtual link uses a separate transport mode IPsec SA, but they
all have the same client IDs. It is the SA (i.e. the SPI field) that
distinguishes one virtual link from another. Each IPsec SA is bound
to a VPN-ID through a payload exchanged during the Quick Mode
negotiation.
Pros:
. This approach leverages the IKE Quick Mode as a tunnel management
protocol.
. Likely to interoperate with CE-based devices to form routing
adjacencies.
Cons:
. There is no IPsec-less (unsecured) operation available since it
relies on IPsec for multiplexing and for tunnel management
signaling.
. The current IKE standard does not define a payload to convey a
VPN-ID; this would require a vendor-specific payload, IKE
extension, etc.
. Requires the tunnel end points to support negotiating multiple
IPsec SAs with the same client IDs.
6.3 Distinct IP-in-IP Tunnel with Transport Mode IPsec
This approach uses a distinct IP-in-IP tunnel to realize each virtual
link. Multiple virtual links between a pair of systems use distinct
IP-in-IP tunnels (i.e. different endpoint addresses). Transport mode
IPsec is used to secure the tunnels, and the IKE also provides tunnel
management signaling. Each virtual link has its own distinct ISAKMP
and IPsec SAs.
Each virtual link terminates on a different tunnel endpoint (i.e.
"outer") IP address and it is this that distinguishes one virtual
Duffy Expires - April 2003 [Page 9]
Internet Draft IPsec Protected Virtual Links October 2002
link from another. The VPN context is bound to each tunnel endpoint
address through configuration, directory lookup, or VPN
autodiscovery.
Pros:
. This approach leverages the IKE Quick Mode as a tunnel management
protocol.
. Likely to interoperate with CE-based devices to form routing
adjacencies. This is the proposal of [KNIGHT] and [CE-VPN]
extended to multi-context systems.
Cons:
. There is no IPsec-less (unsecured) operation available since it
relies on IPsec for the tunnel management signaling. (Unless one
does not care about the tunnel management.)
. Requires recognizing, and terminating tunnels on, multiple IP
addresses (one per VPN context).
. Scales poorly because it requires an expensive ISAKMP SA per
virtual link.
. VPN context correlation requires an external means to associate
tunnel endpoint addresses to VPN-IDs and make the association
known at both tunnel endpoints.
6.4 GRE Tunnel with Transport Mode IPsec
This approach uses [GRE] to provide the tunneling. Using the Key
extension to GRE ([GRE-KEY]) multiple virtual links between a pair of
systems are multiplexed within one GRE tunnel. Transport mode IPsec
is used when desired to secure the GRE tunnel -- one ISAKMP and one
IPsec SA are used per PE pair. Application of IPsec is based on an
SPD rule matching the GRE (i.e. "outer") packet header.
A VPN context is bound to each Key value through configuration,
directory lookup, or VPN autodiscovery.
Pros:
. IPsec-less operation is available since the tunneling is provided
completely independently of IPsec.
. Requires neither extension nor liberal interpretation of IPsec.
Cons:
. Unlikely to interoperate with CE-based devices.
. No tunnel management protocol.
. VPN context correlation requires an external means to associate
GRE Key values to VPN-IDs and make the association known at both
tunnel endpoints.
. Controlling IPsec use on a per-VPN basis cannot be done within the
standard IPsec SPD model, since packets of different VPNs are not
Duffy Expires - April 2003 [Page 10]
Internet Draft IPsec Protected Virtual Links October 2002
discernible by the selectors available to IPsec (the outer GRE
packet).
6.5 MPLS Tunnel with Transport Mode IPsec
This approach uses MPLS-in-IP ([MPLS], [MPLS-IP]) to provide the
tunneling. Using an MPLS label in an IP encapsulation, multiple
virtual links between a pair of systems are multiplexed within one
MPLS-in-IP tunnel. Transport mode IPsec is used when desired to
secure the MPLS-in-IP tunnel -- one ISAKMP and one IPsec SA are used
per PE pair. Application of IPsec is based on an SPD rule matching
the MPLS-in-IP (i.e. "outer") packet header.
A VPN context is bound to each MPLS label value. MPLS labels might
be distributed by a label distribution protocol, or by configuration,
directory lookup, or piggybacked on autodiscovery. If a label
distribution protocol is used, that might serve as a tunnel
management protocol.
Pros:
. IPsec-less operation is available since the tunneling is provided
completely independently of IPsec.
. Requires neither extension nor liberal interpretation of IPsec.
Cons:
. Unlikely to interoperate with CE-based devices.
. VPN context correlation requires an external means to associate
MPLS labels to VPN-IDs and make the association known at both
tunnel endpoints.
. Controlling IPsec use on a per-VPN basis cannot be done within the
standard IPsec SPD model, since packets of different VPNs are not
discernible by the selectors available to IPsec (the outer MPLS-
in-IP packet).
6.6 L2TP with Transport Mode IPsec
This approach uses [L2TP] to provide the tunneling. Using L2TP
sessions carrying PPP sessions, multiple virtual links between a pair
of systems are multiplexed within one L2TP tunnel. Transport mode
IPsec is used when desired to secure the tunnel -- one ISAKMP and one
IPsec SA are used per PE pair. Application of IPsec is based on an
SPD rule matching the L2TP (i.e. "outer") packet header.
A VPN context is bound to each L2TP session via the exchange of L2TP
AVPs (e.g. the End Identifier AVP of L2TPv3 -- a similar AVP could be
defined for L2TPv2).
Pros:
Duffy Expires - April 2003 [Page 11]
Internet Draft IPsec Protected Virtual Links October 2002
. IPsec-less operation is available since the tunneling is provided
completely independently of IPsec.
. Requires neither extension nor liberal interpretation of IPsec.
. The L2TP control protocol serves as a tunnel management protocol.
. Other helpful PPP and L2TP features are available such as address
negotiation, keepalives, etc.
Cons:
. Unlikely to interoperate with CE-based devices.
. Controlling IPsec use on a per-VPN basis cannot be done within the
standard IPsec SPD model, since packets of different VPNs are not
discernible by the selectors available to IPsec (the outer L2TP
packet).
7. Recommendation
The PPVPN working group should develop a standard for IPsec-protected
virtual links for the PE-PE environment and one for the CE-CE
environment. If those standards can be one and the same or if the
CE-CE one can be a subset of the other it would be a plus.
Of the approaches advanced in this memo, the L2TP based approach
(section 6.6) appears to provide the nicest characteristics for the
PE-PE case. However, vendors of CPE equipment are unlikely to
embrace this approach for the CE-CE case. Also, it is arguably a bit
on the heavyweight side.
The distinct IP-in-IP tunnel approach (section 6.3) is also promising
as it is likely to interoperate with CE-CE VPN devices, and it does
not require extensions to IKE to signal the VPN-ID.
8. Security Considerations
This memo deals with ways in which IPsec may be used to secure
virtual links in virtual router based PPVPNs. As such security
issues are discussed throughout.
Because the virtual router approach exchanges routing messages in-
band with the VPN data on the virtual links, securing those links
simultaneously secures both the VPN data plane and control plane (or
more accurately, the reachability distribution part of the control
plane).
Security beyond the boundaries of the provider-provisioned network is
beyond the scope of this memo and indeed, beyond the scope of the
solutions described here.
Duffy Expires - April 2003 [Page 12]
Internet Draft IPsec Protected Virtual Links October 2002
9. References
9.1 Normative References
9.2 Informative References
[CE-VPN] De Clercq, Paridaens, Krywaniuk, and Wang, "An
Architecture for Provider Provisioned CE-based Virtual Private
Networks using IPsec," (Work in progress) draft-ietf-ppvpn-ce-
based-02.txt, June 2002.
[GRE] Farinacci, Li, Hanks, Meyer, and Traina, "Generic Routing
Encapsulation (GRE)," RFC 2784, March 2000.
[GRE-KEY] Dommety, G., "Key and Sequence Number Extensions to GRE,"
RFC 2890, September 2000.
[IKE] Harkins, D. and Carrel, D., "The Internet Key Exchange
(IKE)," RFC 2409, November 1998.
[IP-IP] Perkins, C., "IP Encapsulation within IP," RFC 2003,
October 1996.
[IPSEC] Kent, S. and Atkinson, R., "Security Architecture for the
Internet Protocol," RFC 2401, November 1998.
[KNIGHT] Knight, P. and Gleeson, B., "A Method to Provide Dynamic
Routing in IPsec VPNs," (Work in progress) draft-knight-ppvpn-
ipsec-dynroute-01.txt, July 2002.
[L2TP] Townsley, Valencia, Rubens, Pall, Zorn, and Palter, "Layer
Two Tunneling Protocol L2TP," RFC 2661, August 1999.
[MPLS] Rosen, E., Viswanathan, A., and Callon, R., "Multiprotocol
Label Switching Architecture," RFC 3031, January 2001.
[MPLS-IP] Wooster, T., Rekhter, Y., and Rosen, E., "Encapsulating
MPLS in IP or GRE," (Work in progress) draft-rosen-mpls-in-ip-or-
gre-00.txt, August 2002.
[TOUCH] Touch, J. and Eggert, L., "Use of IPsec Transport Mode for
Dynamic Routing,". (Work in progress) draft-touch-ipsec-vpn-04.txt,
June 2002.
[VPN-ID] Fox, B. and Gleeson, B., "Virtual Private Networks
Identifier," RFC 2685, September 1999.
Duffy Expires - April 2003 [Page 13]
Internet Draft IPsec Protected Virtual Links October 2002
[VR-VPN] Knight, P. et al, "Network based IP VPN Architecture using
Virtual Routers," (Work in progress) draft-ietf-ppvpn-vpn-vr-
03.txt, July 2002.
10. Summary for Sub-IP Related Internet Drafts
RELATED DOCUMENTS
The References section lists a number of related documents. [CE-VPN]
and [KNIGHT] in particular discuss IPsec-protected virtual links,
however the solution they propose is aimed at CE-based VPNs and is
inadequate for PE-based VPNs, serving multiple contexts.
WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK?
This I-D is intended for the PPVPN Working Group.
WHY IS IT TARGETED AT THIS WG(s)?
This document addresses a component that is essential for Virtual
Router and CE-based provider provisioned VPNs, which are within the
purview of the PPVPN working group.
JUSTIFICATION
The PPVPN working group has the charter, among other things, to
develop virtual router based VPN standards and to provide for
security and privacy of user data in a VPN environment.
Author's Addresses
Mark Duffy
Quarry Technologies
8 New England Executive Park
Burlington MA 01803 USA
Email: mduffy@quarrytech.com
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
Duffy Expires - April 2003 [Page 14]
Internet Draft IPsec Protected Virtual Links October 2002
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Duffy Expires - April 2003 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-21 10:55:23 |