One document matched: draft-baker-nested-vpn-routing-01.txt
Differences from draft-baker-nested-vpn-routing-00.txt
Network Working Group F. Baker
Internet-Draft Cisco Systems
Expires: January 18, 2006 P. Bose
D. Voce
Lockheed Martin
July 17, 2005
Routing across Nested VPNs
draft-baker-nested-vpn-routing-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on January 18, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document discusses the general problem of routing in an IPv6
Nested Virtual Private Network. A solution is proposed based on one-
way hashes of IP Prefix values. The concepts extend to IPv4, but
with difficulty due to the number of bits in question.
Requirements Language
Baker, et al. Expires January 18, 2006 [Page 1]
Internet-Draft Nested VPN Routing July 2005
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 RFC 2119 [RFC2119].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Nested Virtual Private Networks . . . . . . . . . . . . . 5
1.2 Defining Terms . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Fundamental Requirements for Routing . . . . . . . . . . . 7
1.4 Fundamental proposal: use of a one-way hash . . . . . . . 7
2. Unicast Routing Solution . . . . . . . . . . . . . . . . . . . 10
2.1 Inner domain routing . . . . . . . . . . . . . . . . . . . 11
2.2 Forming a ciphertext address from a plaintext prefix . . . 12
2.3 Routing between enclaves . . . . . . . . . . . . . . . . . 13
2.3.1 Routing between enclaves across a common
ciphertext domain . . . . . . . . . . . . . . . . . . 13
2.3.2 Routing between enclaves across a multiple
ciphertext domains . . . . . . . . . . . . . . . . . . 13
2.4 Routing to a remote address . . . . . . . . . . . . . . . 14
2.5 Proving recursiveness . . . . . . . . . . . . . . . . . . 14
2.6 Open Issues (Author's notes to self) . . . . . . . . . . . 16
3. Multicast Routing Solution - SSM . . . . . . . . . . . . . . . 17
3.1 Forming a ciphertext group address from a plaintext
address . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Routing to a remote address . . . . . . . . . . . . . . . 19
3.3 Proving recursiveness . . . . . . . . . . . . . . . . . . 20
3.4 Issues (Author's notes to self) . . . . . . . . . . . . . 20
4. Key Management Procedures . . . . . . . . . . . . . . . . . . 21
4.1 Key Management Requirements . . . . . . . . . . . . . . . 21
4.2 Key Management Procedures . . . . . . . . . . . . . . . . 21
4.3 Pathological Cases . . . . . . . . . . . . . . . . . . . . 22
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
6. Security Considerations . . . . . . . . . . . . . . . . . . . 24
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.1 Normative References . . . . . . . . . . . . . . . . . . . 26
8.2 Informative References . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28
Baker, et al. Expires January 18, 2006 [Page 2]
Internet-Draft Nested VPN Routing July 2005
A. Additional stuff . . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . 31
Baker, et al. Expires January 18, 2006 [Page 3]
Internet-Draft Nested VPN Routing July 2005
1. Introduction
This document discusses the general problem of routing in an IPv6
Nested Virtual Private Network. A solution is proposed based on one-
way hashes of IP Prefix values, or equivalently, the use of encrypted
prefix values. The concepts extend to IPv4, but with difficulty due
to the number of bits available in the address.
Baker, et al. Expires January 18, 2006 [Page 4]
Internet-Draft Nested VPN Routing July 2005
1.1 Nested Virtual Private Networks
/ \
( +--+ +--+ enclave ) ,---------.
.----------. \ |H2+---+R2| / ,-' `
+--+ +--+`--.\ +--+ ++-+ / / +--+ +--+
|H1+---+R1| \`. | ,' / |R3+---+H3|
+--+ +-++ ) '--. +----++ _.-' ( ++-+ +--+
| / _.`---|VPN2||''-. \ |
enclave +----+-i.--'' +----++ `----.\ +----+ enclave
--------|VPN1|' | ``|VPN3| ,
,+----+ | +----+------'
,' --+-------+----------+------------------+---`.
,' ++-+ `.
,' |R7+--------+ `.
/ interface +--+ | \
domain 1 +-+--+ \
_.--------|VPN7|--------.
,-----'' +--+-+ `------. .
`-. ,-' | `-. .-'
`-: inner domain +-++ `.'
( |R9| )
.'. ++-+ ;-.
.' `-. | ,-' `-.
' `------. +-+--+ _.-----' `
interface `---------|VPN8|-------''
domain 2 +-+--+ /
\ | +--+ /
`. +----------+R8| ,'
`. ++-+ ,'
`. --+------------------+-----------+------+-- ,'
,-----+----+ | +----+------.
,' |VPN6|. | _.|VPN4| `
+----+.`----. +----+ _.--'' ,+----+
| \ `--=.-|VPN5|---:' / |
+--+ ++-+ : ,-'' +----+ `--. ; ++-+ +--+
|H6+---+R6| | ,' | `.| |R4+---+H4|
+--+ +--+ ;/ +--+ ++-+ : +--+ +--+
// |H5+---+R5| \
enclave ,'( +--+ +--+ `. enclave
`. ,' \ enclave / '-. ,
`-------' \ / `-------'
Figure 1: Nested Virtual Private Network
Figure 1 shows what the authors have described as a "Nested VPN".
Like normal VPNs, this is a network that has a variety of enclaves
that communicate across an encrypted cloud that is invisible to them
Baker, et al. Expires January 18, 2006 [Page 5]
Internet-Draft Nested VPN Routing July 2005
(apart from effects such as delay or jitter) and to which they are
invisible. It differs in that the construct is recursive - such
encrypted clouds may themselves appear to be enclaves to further
underlying VPN networks - and that little or no information is
permitted to cross the boundary and yet any enclave must be enabled
to communicate with any other enclave at the same nesting level.
Normal VPNs tend to be managed in one of two ways. One is that a
service provider offers the VPN, and provides an underlying circuit
network, often MPLS, that connects the underlying endpoints as
defined in a contract. These are referred to as "Provider-
Provisioned VPNs" [RFC3809]. The other, generally referred to as
"customer-provisioned", is that the edge routers themselves provide
tunnels over an underlying network using one of a variety of types of
IP tunnel technologies loose source routes as specified in DVMRP
[RFC1075], IP/IP [RFC2003], IPsec/ESP [RFC2401][RFC2406], L2TP
[RFC2661], GRE [RFC2784], and others.
In this context, a "Nested VPN" is an example of an IPsec or IPsec-
like VPN, and is therefore "customer-provisioned". Such networks
have in the past been built in a very ad hoc fashion, without
significant knowledge or concern for the underlying network
infrastructure. They have often consisted of either a haphazard
collection of tunnels, or a star or multi-star network in which a
large set of client sites maintain static or semi-static tunnels with
a much smaller set of service sites. Such networks support
telecommuters working from home offices, small distributed companies,
and so on.
1.2 Defining Terms
Plain Text: A domain in which datagrams are sent without additional
encryption.
Cipher Text: A domain in which datagrams are sent with additional
encryption. Note that if there is an additional layer of
encryption in the network beyond that provided by a given cipher
text domain, a cipher text domain will be treated by that cipher
text domain as if it were a plain text domain - traffic entering
it will be encrypted, and traffic leaving it will be decrypted.
Domain: In the context of this document, the routing domain of
relevance. This will be either a Cipher text or a Plain text
domain.
Baker, et al. Expires January 18, 2006 [Page 6]
Internet-Draft Nested VPN Routing July 2005
Enclave: A Plain text Domain, as seen from the Cipher text domain
One Way Hash: One of a variety of approaches that scramble the bits
in a string or number to produce a different one, and from which
the original cannot be deduced. Examples, include CRCs, MD5, etc.
Encrypted addresses have also been suggested, and would work in
this context, but require management of the ability to decrypt the
address, via key management.
VPN Router: A special case of a router supporting IPsec or IPsec-like
tunnels over an IP network, and having the characteristic that
information leakage between plain text and cipher text parts of
the same router is absolutely minimal - ideally zero.
1.3 Fundamental Requirements for Routing
[I-D.ietf-rpsec-routing-threats] describes in general terms the
threats that one deals with in routing, and [I-D.ietf-rpsec-generic-
requirements] describes general security requirements for routing.
They might be summarized as relating to four basic attack vectors:
authenticity of the channel, privacy of the channel (both of which
might be adequately addressed by IPsec), correctness of the data, and
scalability to the network design in question. These issues apply to
any routing solution.
In addition, nested VPNs in this context require as close to zero
information leakage as possible between domains. Note that as a
practical matter this is not quite "zero"; the only approach that has
been suggested to date that truly leaks no information across domains
(broadcast a request to all domains asking the right one to respond)
has scalability issues in networks larger than a few tens or hundreds
of enclaves. All other known approaches require some level of
sharing of knowledge between domains - the CPE router creates,
whether through configuration or some more dynamic process, a tunnel
to a router across the cipher text domain by connecting to a
specified cipher text domain address.
1.4 Fundamental proposal: use of a one-way hash
First, imagine that a VPN Router consists of two independent
functional elements, whether physical or logical, and information
crosses between them through a narrowly defined interconnection
function. These four functions are:
Baker, et al. Expires January 18, 2006 [Page 7]
Internet-Draft Nested VPN Routing July 2005
Plain Text Router: A router that is entirely within the plaintext
enclave network.
Cipher Text Router: A router that is entirely within the ciphertext
network.
Encrypt/Decrypt Unit: A functional element (either an interface card
or a separate device) with three interfaces:
* A local interface to the plaintext router, in which datagrams
are passed as IP datagrams associated with a plaintext network
next hop address. Such datagrams are encrypted using IPsec
ESP's [RFC2406] Tunnel Mode, and passed to the Cipher Text
Router.
* An interface to the ciphertext router, which is or is
functionally equivalent to a LAN interface. Messages received
on it are decrypted and handed to the Plain Text Router.
* A network management interface, which enables the programming
of security associations in the encrypt/decrypt process.
Network Manager A functional element (software or hardware) that is
capable of programming security associations and passes narrowly
defined communications between the plaintext and ciphertext
routers. These communciations might include configuration
information and commands to generate or forward QoS signaling.
Such a configuration is shown in Figure 2.
Plain Text Router Cipher Text Router
+------------------+ +------------------+
|+----------------+| +--------+ |+----------------+|
||Configuration || |Network | ||Configuration ||
||Management ++----+Manager +----++Management ||
|+----------------+| +----+---+ |+----------------+|
| | | | |
|+----------------+| +----+---+ |+----------------+|
|| IP +-----+Encrypt/+-----+ IP ||
|+----------------+| |Decrypt | |+----------------+|
|+----------------+| +--------+ |+----------------+|
|| Link || || Link ||
|+----------------+| |+----------------+|
+------------------+ +------------------+
Figure 2: VPN Router Functional Breakdown
The hash function accepts a number of 0 to 64 bits and hashes it
Baker, et al. Expires January 18, 2006 [Page 8]
Internet-Draft Nested VPN Routing July 2005
according to an externally specific (e.g., not intrinsic to this
specification) algorithm. Possible algorithms include CRCs, SHA1,
MD5 hashes, AES encryption, etc.
Coupled with Stateless Address Autoconfiguration [RFC2462] and
specifically its Privacy extensions [RFC3041], this enables us to
create a host part of an IPv6 address based on a randomized number
taken from the enclave and build an address based on it unknown on
the plain text side (either within the enclave or in any remote
enclave) but in a certain sense predictable by it.
| 64 bit component | 64 bit component |
+----------------------+----------------------+
| IPv6 Prefix | IPv6 host part |
+----------------------+----------------------+
| |
| |
| |
,-------.
( Hash )
`-------'
| |
| |
| | 64 bit result
+----------------------+
| Hashed number |
+----------------------+
Figure 3: One-way Hash
Baker, et al. Expires January 18, 2006 [Page 9]
Internet-Draft Nested VPN Routing July 2005
2. Unicast Routing Solution
+------+ +------+ +------+
|Host 1| |Host 2| |Host 3|
+--+---+ +--+---+ +--+---+
| | |
/--+-------------+-+--------------+---/
|
+------+------+
|+-----------+|
||Plain text ||
|+-----------+| VPN Router 1
| +--+ |
| +--+ |
|+-----------+|
||Cipher text||
|+-----------+|
+------+------+
|
,-----------+-----------------.
( IP Network )
`-------------+---------------'
|
+----+--------+
|+-----------+|
||Cipher text||
|+-----------+|
| +--+ |
| +--+ |
VPN Router 2 |+-----------+|
||Plain text ||
|+-----------+|
+------+------+
|
/---+--------------+-+-------------+--/
| | |
+---+--+ +---+--+ +---+--+
|Host 4| |Host 5| |Host 6|
+------+ +------+ +------+
Figure 4: Unicast Example
Let us work through an example of unicast use. Figure 4 shows a
simple case of a VPN. The fundamental problems are:
o Given a prefix on the LAN in the upper enclave, how does one form
an address on the cipher text side of the VPN Router?
Baker, et al. Expires January 18, 2006 [Page 10]
Internet-Draft Nested VPN Routing July 2005
o How does the plain text prefix of the upper LAN or address of Host
1 relate to routing?
o How does the corresponding cipher text prefix or address relate to
routing?
o How does a host in a remote enclave determine the address of Host
1?
o How does a host in a remote enclave direct a datagram to the
appropriate VPN Router to get it to Host 1?
o Presuming that the two VPN Routers are unknown to each other, how
do they form the appropriate security association?
2.1 Inner domain routing
IPSec or IPSec like routers currently support static configuration of
ciphertext addresses in security databases. These addresses are used
by the VPN router to initialize security associations to a set of
well-known ciphertext addresses. The mechanism to dynamically create
and discover new or changing cipher text addresses as described in
this document complements the static configuration mechanism or other
legacy mechanisms (for example, directory servers could resolve
ciphertext address queries). Static configuration of a known set of
ciphertext addresses on a VPN router is useful in setting up default
security associations (for example to peer enterprise VPN routers or
to enterprise headquarters).
In the inner domain of Figure 1 , the authors consider it likely that
security associations between VPN8 and VPN7 are likely to be
statically configured, allowing IGP routing to run over them as
through a tunnel. This connects the routing of the interface
domains, enabling the alogrithm described in Section 2.2 to work
properly.
In addition, other approaches exist to distribute routing information
in the core. For example, one could use Mobile IP to connect to a
central "Home Agent" within the ciphertext domain which would be able
to provide, through Optimized Routing, the address of the proper peer
as a Care-of Address. Having established that relationship, OSPF
with the Do-Not-Age flag could allow the domains to exchange routing
information but not have to maintain continuous routing relationships
thereafter. Another alternative would be a directory service similar
to LDAP or DNS that could associate the hashed nonce with the
ciphertext address located within the ciphertext domains.
Baker, et al. Expires January 18, 2006 [Page 11]
Internet-Draft Nested VPN Routing July 2005
2.2 Forming a ciphertext address from a plaintext prefix
First, a VPN Router (as shown in Figure 2) is in every sense a
router, as defined by the IPv6 Architecture [RFC2460], which defines
a router as any "node that forwards IPv6 packets not explicitly
addressed to itself. " As a router, it may advertise (using
theStateless Address Autoconfiguration [RFC2462] Router
Advertisement) a prefix into its plain text domain, or it may pick up
similar advertisements from another router. It and the other hosts
in the enclave form addresses within the enclave's prefix as
specified in that procedure, and may subsequently advertise these
addresses in DNS in the plain text domain or disseminate them in
other ways.
As shown in Figure 5, knowing the prefix for the enclave LAN, the
plain text side of the VPN Router hashes the prefix (the /64 or the
appropriate subset of it) and communicates the hashed value to the
cipher text side. That interface is similarly engaged in stateless
address autoconfiguration. It uses the prefix from that side
(whether configured or learned) with the hashed value to form an
address for the cipher text side.
There are two approaches to placing multiple LANs within an enclave.
One is to have the VPN Router participate in routing within the
enclave, and form multiple such addresses on the cipher text side.
Another is to use a shorter prefix in each enclave, such as perhaps a
/60. A /60 would permit every enclave to support 16 IPv6 LANs
without expanding routing.
The cipher text-side address is now included in routing in the IP
network on the cipher text side as a host route (/128), or may be
distributed in an OSPF Opaque LSA (if the routing domain is entirely
OSPF).
Baker, et al. Expires January 18, 2006 [Page 12]
Internet-Draft Nested VPN Routing July 2005
+----------------------+----------------------+
| IPv6 Prefix of | Host part of |
| Plain text domain | IPv6 Address |
+----------------------+----------------------+
\\
\\
,---------------.
( Hash Function )
`---------------'
\\
\\
+----------------------+----------------------+
| IPv6 Prefix of | Hashed Plain text |
| Cipher text domain | IPv6 Address |
+----------------------+----------------------+
Figure 5: Forming a unicast ciphertext address from a plaintext
address
2.3 Routing between enclaves
This system may obviously be used in two ways. It may be used across
a common ciphertext domain, or across mulpitple ciphertext domains
that route traffic through intermediate enclaves.
2.3.1 Routing between enclaves across a common ciphertext domain
Once the security association is set up between two VPN routers, the
respective enclaves can exchange routing information in the security
association. As an example, if the two disjoint enclaves learn
routes inside their respective enclaves via the use of an IGP
protocol like OSPF, OSPF route advertisements can be exchanged in the
security association which is set up using the procedure described
above. Hence hosts and routers within each enclave learn routes from
the remote enclave using the same protocol that is used within their
enclave via the invisible security association between the VPN
routers.
2.3.2 Routing between enclaves across a multiple ciphertext domains
By extension, if a router in an intermediate enclave establishes
relationships with multiple plaintext peers, it has the option to
advertise its capability as a transit path between them. In this
case, a network can be built across multiple plaintext domains.
Baker, et al. Expires January 18, 2006 [Page 13]
Internet-Draft Nested VPN Routing July 2005
2.4 Routing to a remote address
Let us imagine that the two enclaves in Figure 4 have just performed
the procedure in Section 2.2 and at this point have no active
security association. Host 4 is able to determine the address of
Host 1 via DNS, and wishes to commune with it.
Host 4 is essentially unaware of the network connecting it to Host 1,
and unaware of the presence or absence of a VPN Router. Like any
IPv6 host, it encapsulates the datagram in an IPv6 datagram header
and ships it to its friendly neighborhood plain text router, which
happens to be a VPN Router in this case. Processing in the VPN
router is a little different, however:
o The plain router first determines the next hop address (via
routing functions such as OSPF or BGP).
o It then determines whether there is an established security
association from the Network Management process
o if not, it lets the Network Management process establish such an
association (see [RFC2401]).
o It then presents either the next hop address or the SPI that has
been associated with it, with the datagram, to the encrypt/decrypt
unit.
o The encrypt/decrypt unit derives the appropriate remote cipher
text address from the security association information stored in
it.
o Having encrypted the datagram and appropriately re-encapsulated
it, the encrypt/decrypt unit presents the cipher text datagram to
the cipher text router.
If at any point in this process the route lookup or the security
association fails, the datagram is dropped.
The receiving process follows standard IPsec tunnel-mode security
procedures. The cipher text router presents the datagram to the
encrypt/decrypt unit, which decapsulates and decrypts it, and
presents the resulting datagram to the plain text router.
2.5 Proving recursiveness
The proof of recursiveness is simple. Consider Figure 1 and presume
that H1 wishes to exchange files with H6.
Baker, et al. Expires January 18, 2006 [Page 14]
Internet-Draft Nested VPN Routing July 2005
When the networks come up, H1 derive its address from R1 and H6
derives its address from R6. VPN1's plain text side participates in
the routing, and learns of the two LANs in the domain, or learns of
the shorter prefix encompassing them if that is the case in this
network. It forms a cipher text-side address for each relevant
prefix. Similarly, VPN6 participates in the routing of its domain
and forms relevant addresses. So also the other peripheral enclaves.
Routing to those host addresses is injected into the routing of
interface domain 1 and interface domain 2.
This is also true of interface domain 1 and interface domain 2. VPN7
and VPN8 see the interface domains as enclaves and the inner domain
as a cipher text domain. VPN7 and VPN8 form addresses in the inner
domain from the prefixes used in the interface domains, and advertise
corresponding host routes into the routing of the inner domain.
So:
o Host H1 sends a datagram to H6, passing it to R1.
o R1 passes it along its default route, to VPN1.
o VPN1 finds that the next hop towards H6 is VPN6, either by
inspection of the prefix or by knowledge from routing, and knows
that this is across the cipher text domain. It hashes the /64 of
the datagram's source address and passes that to the cipher text
side. There is no corresponding security association, but VPN6's
cipher text-side address shows up in routing, with R7 as the next
hop. VPN1 now opens a security association with VPN6, meaning
that its cipher text side must send a datagram to VPN6.
o The SA-Open datagram is handed to R7, which hands it to VPN7.
o VPN7 finds that the next hop towards VPN6 is VPN8, either by
inspection of the prefix or by knowledge from routing, and knows
that this is across the inner cipher text domain. It hashes the
/64 of the datagram's source address and passes that to its cipher
text side. There is no corresponding security association, but
VPN8's cipher text-side address shows up in routing, with R9 as
the next hop. VPN7 now opens a security association with VPN8,
meaning that its cipher text side must send a datagram to VPN8.
o The IKE exchange happens between VPN7 and VPN8, and when the
relationship is accepted, the datagram initiating the IKE exchange
between VPN1 and VPN6 is encrypted and passed along.
o The IKE exchange happens between VPN1 and VPN6, and when the
relationship is accepted, the datagram initiating the datagram
Baker, et al. Expires January 18, 2006 [Page 15]
Internet-Draft Nested VPN Routing July 2005
from H1 to H6 is encrypted and passed along.
2.6 Open Issues (Author's notes to self)
Anycast: Does this preclude anycast applications?
Hash collisions: A good hash such as SHA should keep the collisions
to a minimum, but theoretically they can still happen.
Plaintext prefix collisions: If two enclaves chose the same prefix,
this would result in two VPN gateways advertising the same
address. This is a configuration error (two enclaves shouldn't do
that, not in an IP network)
Ciphertext host part collisions: A VPN router properly forms its
cipher text address, and finds that its address collides with the
address of another device on its link. The autoconfiguration
process provides for arbitration, but the VPN router can't change
its address. Wouldn't that be a fatal problem?
Baker, et al. Expires January 18, 2006 [Page 16]
Internet-Draft Nested VPN Routing July 2005
3. Multicast Routing Solution - SSM
It has been aptly said that anyone who thinks he understands
something in routing should repeat his statement using the word
"multicast". This section proposes to do exactly that. Figure 4
shows a simple case of a VPN. Rather than attempting to solve the
most general case, which many have found difficult, use Single Source
Multicast [RFC3569]as the basic technology. The fundamental problems
are:
o Given a group prefix on the LAN in the upper enclave, how does one
form a corresponding address on the cipher text side of the VPN
Router?
o How does the plain text address Host 1 relate to routing of a
multicast group used by Host 1?
o How does the corresponding cipher text group address relate to
routing?
o How does a host in a remote enclave determine the plain text group
address and join it?
o How does a VPN Router in front of a remote enclave determine the
corresponding cipher text group address and join it?
o Presuming that the two VPN Routers are unknown to each other, how
do they form the appropriate security association?
o How are keys exchanged?
3.1 Forming a ciphertext group address from a plaintext address
Single Source Multicast identifies a multicast channel using the
source address and group address as an {S,G} pair. Using IPv6
addresses, this has a natural breakdown: the Sender Address has a
prefix part (a /64 prefix) and a host part, and the group address
(defined in [I-D.ietf-ipv6-addr-arch-v4] and shown in Figure 6)
similarly has 16 bits of discriminator, flags, and scope, and 112
bits of Group ID. For the purposes of this document, we will
consider that Group ID to have 64 bits in its lower part and 48 bits
in its upper part, and that the upper part represents a prefix that
may be configured for a routing domain. In this game, we will create
the cipher text side of the VPN router's "sender address" just as we
did in Section 2, and will additionally use the hash of the host part
of the plain text group address.
Baker, et al. Expires January 18, 2006 [Page 17]
Internet-Draft Nested VPN Routing July 2005
| 8 | 4 | 4 | 112 bits |
+------ -+----+----+---------------------------------------------+
|11111111|flgs|scop| group ID |
+--------+----+----+---------------------------------------------+
Figure 6: IPv6 Multicast Address, from RFC 3513
As shown in Figure 7, when a host joins a multicast tree emanating
from a host in another enclave, the joins will migrate toward the
sender following SSM's algorithms, and crossing the intervening VPN
as through a tunnel. When such a route is created, the following
four elements are combined:
o a configured multicast group prefix used in the cipher text domain
and unknown to the plain text side
o The IPv6 prefix used for unicast addresses in the cipher text
domain.
o The hashed prefix part of the plain text side sender address
o The hashed "host part" of the plain text side group address
+-----------+-----------+-----------+-----------+
| Plain text| Plain text| Plain text| Plain text|
| Source | Source | Group and | Group Addr|
| Prefix | Host Part | Flags |"Host Part"|
+-----------+-----------+-----------+-----------+
\\ ||
\\ ||
,-------. ,-------.
( Hash ) ( Hash )
`-------' `-------'
\\ ||
\\ ||
+-----------+-----------+-----------+-----------+
|Cipher text|Cipher text|Cipher text|Cipher text|
| Source | Source | Group and | Group Addr|
| Prefix | Host Part | Flags | LSB |
+-----------+-----------+-----------+-----------+
Figure 7: Forming a ciphertext address pair from a plaintext address
pair
The cipher text domain's prefix plus the hashed plain text prefix
form the "sender address", identical to the cipher text domain
unicast address. The cipher text group address prefix plus the
hashed host part of the sender address creates multiple multicast
Baker, et al. Expires January 18, 2006 [Page 18]
Internet-Draft Nested VPN Routing July 2005
groups for each the plain text domain. If a given host in the plain
text domain requires multiple multicast groups, it creates multiple
group addresses.
3.2 Routing to a remote address
A host in a remote enclave determines the SSM channel identifier, an
{S,G} address pair and joins it. The "join" heads toward the VPN
Router, which performs the same transformation as noted in
Section 3.1, and the cipher text side of that system joins that
multicast group. As an example, assume that the enclaves in Figure 4
have established unicast connectivity across the cipher text domain
via the procedure described in Section 2.2. Further assume that Host
4 is the source of a plain text multicast group G. Host 1 learns of
the SSM channel {Host 4, Group G} out of band. It joins towards this
channel through normal MLDv2 [RFC3810] multicast listener report
messaging. The plain text side of VPN Router 1 receives the report,
hashes the source prefix (Host 4) and the host part of the plain text
group address G, and communicates the hashed values to the cipher
text side. This triggers a join toward the cipher text multicast
channel supporting the plain text channel. The original join is also
directed across a unicast security association to the plain text side
of VPN Router 2, and continues joining toward Host 4.
The cipher text side joins towards the cipher text domain connecting
the enclaves using the source address formed by the procedure
described in Section 2.2 and a cipher text group address formed by
combining its configured cipher text multicast group prefix with the
hashed host part of the plain text group address G. A source-specific
tree is constructed through the domain and a join reaches the cipher
text side of the source enclave's VPN router. The source VPN router
creates join state for the multicast channel on its cipher text side.
When Host 4 transmits multicast packets on the channel, the plain
text side of its VPN router passes the (encrypted) packet to the
cipher text side along with a hash of the enclave unicast prefix and
a hash of the host part of the plain text group address G. The packet
is forwarded down the source-specific tree within the cipher text
domain towards the VPN router fronting Host 1. The VPN router
decrypts the packet and passes it to its plain text side which
forwards it to Host 1 due to the join state previously created via
MLDv2.
If the VPN routers do not border the same cipher text domain, they
must know of each other's configured cipher text multicast prefixes
prior to establishing the source-specific tree. They may learn of
their respective cipher text multicast prefixes through pre-
configuration, or they may inform each other following the
Baker, et al. Expires January 18, 2006 [Page 19]
Internet-Draft Nested VPN Routing July 2005
establishment of a unicast SA.
One approach to distribution of the encryption key used by the
multicast data stream and the multicast group's group address in the
cipher text domain would be for VPN Router 1 to query VPN Router 2 in
the black domain to determine what 48 bit group address portion,
flags, and scope are in use and the key used for the channel. This
would occur using the cipher text domain's unicast security
association.
3.3 Proving recursiveness
Since the components required in Section 3.1 are the same at both
levels, both levels work.
3.4 Issues (Author's notes to self)
We need to deal with the possibility that the hash function produces
collisions...
Baker, et al. Expires January 18, 2006 [Page 20]
Internet-Draft Nested VPN Routing July 2005
4. Key Management Procedures
4.1 Key Management Requirements
The various ways that one hashes bits are checksum generation or
cryptographic mechanisms. These generally use some initial data to
parameterise the algorithm; this may be included in the result or
used (such as in a CRC) to select feedback paths in the algorithm, or
other approaches. For generality, in this document such parameters
will be referred to as "keys".
It is strongly desirable that a hypothetical security breach in one
Internet protocol not automatically compromise other Internet
protocols. A key configured for use in this specification SHOULD NOT
be stored using protocols or algorithms that have known flaws.
Implementations MUST support the storage of more than one key at the
same time, although it is recognized that only one key will normally
be active on an interface. They MUST associate a specific lifetime
(i.e., date/time first valid and date/time no longer valid) and a key
identifier with each key, and MUST support manual key distribution
(e.g., the privileged user manually typing in the key, key lifetime,
and key identifier on the router console). The lifetime may be
infinite. If more than one algorithm is supported, then the
implementation MUST require that the algorithm be specified for each
key at the time the other key information is entered. Keys that are
out of date MAY be deleted at will by the implementation without
requiring human intervention. Manual deletion of active keys SHOULD
also be supported.
4.2 Key Management Procedures
As with all security methods using keys, it is necessary to change
the key on a regular basis. To maintain routing stability during
such changes, implementations MUST be able to store and use more than
one Key on a given interface at the same time.
Each key will have its own Key Identifier, which is stored locally.
The combination of the Key Identifier and the interface associated
with the datagram uniquely identifies the algorithm and key in use.
As noted above, the VPN Router will select a valid key from the set
of valid keys for that interface. The receiver will use the Key
Identifier and interface to determine which key to use for
authentication of the received datagram. More than one key may be
associated with an interface at the same time.
Hence it is possible to have fairly smooth Key rollovers without
Baker, et al. Expires January 18, 2006 [Page 21]
Internet-Draft Nested VPN Routing July 2005
losing legitimate traffic because the stored key is incorrect and
without requiring people to change all the keys at once. To ensure a
smooth rollover, each communicating VPN Router must be updated with
the new key several minutes before the current key will expire and
several minutes before the new key lifetime begins. The new key
should have a lifetime that starts several minutes before the old key
expires. This gives time for each VPN Router to learn of the new key
before that key will be used. It also ensures that the new key will
begin being used and the current key will go out of use before the
current key's lifetime expires. For the duration of the overlap in
key lifetimes, a system may receive datagrams using either key and
authenticate the datagram. The Key-ID in the received datagram is
used to select the appropriate key for authentication.
4.3 Pathological Cases
Two pathological cases exist which must be handled, which are
failures of the network manager. Both of these should be exceedingly
rare.
During key switchover, devices may exist which have not yet been
successfully configured with the new key. Therefore, routers SHOULD
implement (and would be well advised to implement) an algorithm that
detects the set of keys being used by its neighbors, and transmits
its datagrams using both the new and old keys until all of the
neighbors are using the new key or the lifetime of the old key
expires. Under normal circumstances, this elevated transmission rate
will exist for a single update interval.
In the event that the last key associated with an interface expires,
it is unacceptable to revert to an unauthenticated condition, and not
advisable to disrupt routing. Therefore, the router should send a
"last authentication key expiration" notification to the network
manager and treat the key as having an infinite lifetime until the
lifetime is extended, the key is deleted by network management, or a
new key is configured.
Baker, et al. Expires January 18, 2006 [Page 22]
Internet-Draft Nested VPN Routing July 2005
5. IANA Considerations
This memo adds no new IANA considerations. The presence of this
template text indicates that the author/editor has not actually
reviewed IANA considerations.
Note to RFC Editor: This section will have served its purpose if it
correctly tells IANA that no new assignments or registries are
required, or if those assignments or registries are created during
the RFC publication process. From the author's perspective, it may
therefore be removed upon publication as an RFC at the RFC Editor's
discretion.
Baker, et al. Expires January 18, 2006 [Page 23]
Internet-Draft Nested VPN Routing July 2005
6. Security Considerations
The specification of a set of acceptable hash mechanisms is beyond
the scope of this document. The choice of the exact hash
algorithm(s) that may be employed is dependent on the security
considerations of the customer provisioning the specific virtual
private network. As described in Section 1.4, possible algorithm
choices are defined in MD5 [RFC1321], FIPS PUB 180-1 (SHA1) and ITU-T
Recommendation V.41, "Code-independent error-control system"
(CRC-32).
The appropriate choice of hash algorithm(s) can sufficiently secure
the plain text addresses which are hashed to derive cipher text
addresses. As an improvement to (static) configuration of cipher
text addresses within the plain text databases of the VPN enclave,
the automatic mechanism described in this document can easily
complement other security procedures such as cipher text address
change on a pseudo-random or periodic basis without manual
intervention.
Baker, et al. Expires January 18, 2006 [Page 24]
Internet-Draft Nested VPN Routing July 2005
7. Acknowledgements
Commentary from Brian Weis and Dave McGrew was very helpful.
The authors of RFC 2082, from which the initial text of section 4 was
remorselessly stolen, deserve credit for that contribution.
Baker, et al. Expires January 18, 2006 [Page 25]
Internet-Draft Nested VPN Routing July 2005
8. References
8.1 Normative References
[I-D.ietf-ipv6-addr-arch-v4]
Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", draft-ietf-ipv6-addr-arch-v4-04 (work in
progress), May 2005.
[I-D.ietf-ssm-arch]
Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", draft-ietf-ssm-arch-06 (work in progress),
September 2004.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001.
8.2 Informative References
[I-D.ietf-rpsec-bgpsecrec]
Christian, B., "BGP Security Requirements",
draft-ietf-rpsec-bgpsecrec-01 (work in progress),
February 2005.
[I-D.ietf-rpsec-generic-requirements]
McPherson, D., "Generic Security Requirements for Routing
Protocols", draft-ietf-rpsec-generic-requirements-01 (work
Baker, et al. Expires January 18, 2006 [Page 26]
Internet-Draft Nested VPN Routing July 2005
in progress), January 2005.
[I-D.ietf-rpsec-ospf-vuln]
Jones, E. and O. Moigne, "OSPF Security Vulnerabilities
Analysis", draft-ietf-rpsec-ospf-vuln-01 (work in
progress), December 2004.
[I-D.ietf-rpsec-routing-threats]
Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
Routing Protocols", draft-ietf-rpsec-routing-threats-07
(work in progress), October 2004.
[I-D.puig-rpsec-rqts-opened-questions]
Puig, J., "Generic Security Requirements for Routing
Protocols - Opened Questions",
draft-puig-rpsec-rqts-opened-questions-01 (work in
progress), January 2005.
[RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance
Vector Multicast Routing Protocol", RFC 1075,
November 1988.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC1924] Elz, R., "A Compact Representation of IPv6 Addresses",
RFC 1924, April 1996.
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547,
March 1999.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, August 1999.
[RFC2764] Gleeson, B., Heinanen, J., Lin, A., Armitage, G., and A.
Malis, "A Framework for IP Based Virtual Private
Networks", RFC 2764, February 2000.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
Baker, et al. Expires January 18, 2006 [Page 27]
Internet-Draft Nested VPN Routing July 2005
March 2000.
[RFC2917] Muthukrishnan, K. and A. Malis, "A Core MPLS IP VPN
Architecture", RFC 2917, September 2000.
[RFC3569] Bhattacharyya, S., "An Overview of Source-Specific
Multicast (SSM)", RFC 3569, July 2003.
[RFC3809] Nagarajan, A., "Generic Requirements for Provider
Provisioned Virtual Private Networks (PPVPN)", RFC 3809,
June 2004.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
Reserved for Documentation", RFC 3849, July 2004.
Authors' Addresses
Fred Baker
Cisco Systems
1121 Via Del Rey
Santa Barbara, California 93117
USA
Phone: +1-408-526-4257
Fax: +1-413-473-2403
Email: fred@cisco.com
Pratik Bose
Lockheed Martin
22300 Comsat Drive
Clarksburg, Maryland 20871
USA
Phone: +1-301-428-4215
Fax: +1-301-428-5414
Email: pratik.bose@lmco.com
Baker, et al. Expires January 18, 2006 [Page 28]
Internet-Draft Nested VPN Routing July 2005
Dan Voce
Lockheed Martin
22300 Comsat Drive
Clarksburg, Maryland 20871
USA
Phone: +1-301-428-?
Fax: +1-301-428-?
Email: daniel.voce@lmco.com
Baker, et al. Expires January 18, 2006 [Page 29]
Internet-Draft Nested VPN Routing July 2005
Appendix A. Additional stuff
Baker, et al. Expires January 18, 2006 [Page 30]
Internet-Draft Nested VPN Routing July 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Baker, et al. Expires January 18, 2006 [Page 31]
| PAFTECH AB 2003-2026 | 2026-04-23 18:34:59 |