One document matched: draft-baker-nested-vpn-routing-00.txt
Network Working Group F. Baker
Internet-Draft Cisco Systems
Expires: August 17, 2005 P. Bose
D. Voce
Lockheed Martin
February 13, 2005
Routing in a Nested VPN
draft-baker-nested-vpn-routing-00
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 August 17, 2005.
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.
Baker, et al. Expires August 17, 2005 [Page 1]
Internet-Draft Routing in a Nested VPN February 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Nested Virtual Private Networks . . . . . . . . . . . . . 3
1.2 Defining Terms . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Fundamental Requirements for Routing . . . . . . . . . . . 5
1.4 Fundamental proposal: use of a one-way hash . . . . . . . 5
2. Unicast Routing Solution . . . . . . . . . . . . . . . . . . . 8
2.1 Static configuration . . . . . . . . . . . . . . . . . . . 9
2.2 Forming a ciphertext address from a plaintext prefix . . . 9
2.3 Routing between enclaves . . . . . . . . . . . . . . . . . 10
2.4 Routing to a remote address . . . . . . . . . . . . . . . 10
2.5 Proving recursiveness . . . . . . . . . . . . . . . . . . 11
2.6 Open Issues (Author's notes to self) . . . . . . . . . . . 12
3. Multicast Routing Solution - SSM . . . . . . . . . . . . . . . 14
3.1 Forming a ciphertext group address from a plaintext
address . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Routing to a remote address . . . . . . . . . . . . . . . 16
3.3 Proving recursiveness . . . . . . . . . . . . . . . . . . 17
3.4 Issues (Author's notes to self) . . . . . . . . . . . . . 17
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1 Normative References . . . . . . . . . . . . . . . . . . . 21
7.2 Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
A. Additional stuff . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . 25
Baker, et al. Expires August 17, 2005 [Page 2]
Internet-Draft Routing in a Nested VPN February 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. The concepts extend to IPv4, but
with difficulty due to the number of bits available in the address.
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 / '-. ,
Baker, et al. Expires August 17, 2005 [Page 3]
Internet-Draft Routing in a Nested VPN February 2005
`-------' \ / `-------'
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
(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 messages are sent without additional
encryption.
Cipher Text: A domain in which messages 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.
Baker, et al. Expires August 17, 2005 [Page 4]
Internet-Draft Routing in a Nested VPN February 2005
Domain: In the context of this document, the routing domain of
relevance. This will be either a Cipher text or a Plain text
domain.
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.
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. This is shown in Figure 2.
Baker, et al. Expires August 17, 2005 [Page 5]
Internet-Draft Routing in a Nested VPN February 2005
Plain text Unit Cipher text Unit
+------------------+ +------------------+
|+----------------+| |+----------------+|
||Security Assoc. || +--------+ ||Security Assoc. ||
||Management ++----+ Hash +----++Management ||
|+----------------+| +--------+ |+----------------+|
|+----------------+| +--------+ |+----------------+|
|| IP +-----+Encrypt/+-----+ IP ||
|+----------------+| |Decrypt | |+----------------+|
|+----------------+| +--------+ |+----------------+|
|| Link || || Link ||
|+----------------+| |+----------------+|
+------------------+ +------------------+
Figure 2: VPN Router Functional Breakdown
The interconnection function performs three basic functions: it
o permits internal messages to cross between the plain text and
cipher text units in specified cases,
o encrypts or decrypts datagrams and passes them with a few
specified parameters to the far side
o hashes numbers and sends them to the far side. These hashes may
be parameters of internal messages or of datagrams.
The hash function accepts a number of 0 to 64 bits and hashes it
according to an externally specific (e.g., not intrinsic to this
specification) algorithm. Possible algorithms include CRCs, SHA1,
MD5 hashes, etc. An important characteristic of such a one-way hash
is that it lose information - that there not be a "one-to-one and
onto" relationship between the input and the output.
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.
Baker, et al. Expires August 17, 2005 [Page 6]
Internet-Draft Routing in a Nested VPN February 2005
| 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 August 17, 2005 [Page 7]
Internet-Draft Routing in a Nested VPN February 2005
2. Unicast Routing Solution
+------+ +------+ +------+
|Host 1| |Host 1| |Host 1|
+--+---+ +--+---+ +--+---+
| | |
/--+-------------+-+--------------+---/
|
+------+------+
|+-----------+|
||Plain text ||
|+-----------+| VPN Router
| +--+ |
| +--+ |
|+-----------+|
||Cipher text ||
|+-----------+|
+------+------+
|
,-----------+-----------------.
( IP Network )
`-------------+---------------'
|
+----+--------+
|+-----------+|
||Cipher text ||
|+-----------+|
| +--+ |
| +--+ |
VPN Router |+-----------+|
||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?
o How does the plain text prefix of the upper LAN or address of Host
Baker, et al. Expires August 17, 2005 [Page 8]
Internet-Draft Routing in a Nested VPN February 2005
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 Static configuration
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 ex. plaintext directory servers who 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 ex. to peer enterprise VPN routers or to
enterprise headquarters).
2.2 Forming a ciphertext address from a plaintext prefix
First, a VPN Router 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
Baker, et al. Expires August 17, 2005 [Page 9]
Internet-Draft Routing in a Nested VPN February 2005
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 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).
+----------------------+----------------------+
| IPv6 Prefix of | Host part of |
| Plaintext domain | IPv6 Address |
+----------------------+----------------------+
\\
\\
,---------------.
( Hash Function )
`---------------'
\\
\\
+----------------------+----------------------+
| IPv6 Prefix of | Hashed Plaintext |
| Ciphertext domain | IPv6 Address |
+----------------------+----------------------+
Figure 5: Forming a unicast ciphertext address from a plaintext
address
2.3 Routing between enclaves
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.4 Routing to a remote address
Let us imagine that the two enclaves in Figure 4 have just performed
Baker, et al. Expires August 17, 2005 [Page 10]
Internet-Draft Routing in a Nested VPN February 2005
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 message in an IPv6 datagram header and
ships it to its friendly neighborhood router, which happens to be a
VPN Router in this case. The VPN Router performs its defined
encryption transformation, and in addition hashes the destination
address /64 prefix and passes both to the cipher text side.
The cipher text side first determines whether it has an active
security association with any router whose address contains the
hashed value as its host part. If so, it simply forwards the message
using that security association. Failing such, however, it
o searches its route table for any host route having that hashed
value as the host part of the /128 address
o If it finds one, uses the IKE procedure to open a security
association and exchange keys, and
o now sends the message using the new security association.
If the route lookup or the security association fails, the message is
dropped.
The receiving unit follows standard IPsec tunnel-mode security
procedures. Its cipher text side decrypts the message and hands it
to the plain text side, which in turn directs it to its target.
2.5 Proving recursiveness
The proof of recursiveness is simple. Consider Figure 1 and presume
that H1 wishes to exchange files with H6.
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
Baker, et al. Expires August 17, 2005 [Page 11]
Internet-Draft Routing in a Nested VPN February 2005
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 message 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
from H1 to H6 is encrypted and passed along.
2.6 Open Issues (Author's notes to self)
How interface domain 1 and interface domain 2 find each other to
exchange routing? We are assuming that there is an overarching
routing domain at this level. Need to work out the details of this.
Does this preclude anycast applications?
Baker, et al. Expires August 17, 2005 [Page 12]
Internet-Draft Routing in a Nested VPN February 2005
We need to deal with the possibility that the hash function produces
collisions... These would include
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
ciphertext 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 August 17, 2005 [Page 13]
Internet-Draft Routing in a Nested VPN February 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 group 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
[RFC3513] 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 August 17, 2005 [Page 14]
Internet-Draft Routing in a Nested VPN February 2005
| 8 | 4 | 4 | 112 bits |
+------ -+----+----+---------------------------------------------+
|11111111|flgs|scop| group ID |
+--------+----+----+---------------------------------------------+
Figure 6: IPv6 Multicast Address, from RFC 3513
As shown in Figure 7, the VPN Router's plain text side will join
every multicast route in the enclave that might leave it. 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
+-----------+-----------+-----------+-----------+
| Plaintext | Plaintext | Plaintext | Plaintext |
| Source | Source | Group and | Group Addr|
| Prefix | Host Part | Flags |"Host Part"|
+-----------+-----------+-----------+-----------+
\\ ||
\\ ||
,-------. ,-------.
( Hash ) ( Hash )
`-------' `-------'
\\ ||
\\ ||
+-----------+-----------+-----------+-----------+
| Ciphertext| Ciphertext| Ciphertext| Ciphertext|
| 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
groups for each the plain text domain. If a given host in the plain
text domain requires multiple multicast groups, it creates multiple
Baker, et al. Expires August 17, 2005 [Page 15]
Internet-Draft Routing in a Nested VPN February 2005
group addresses.
3.2 Routing to a remote address
A host in a remote enclave determines the SSM {S,G} address pair out
of band (in a manner, often application-specific, not specified
here), and joins it. The "join" heads toward the VPN Router, which
performs the same transformation as noted in Section 3.1, and the
ciphertext side of that system joins that multicast group.
A host in a remote enclave determines the SSM {S,G} address pair out
of band (in a manner, often application-specific, not specified
here), and joins it. The "join" heads toward the VPN Router, which
performs the same transformation as noted in Section 3.1, and the
ciphertext side of that system joins that multicast group. As an
example, assume that the enclaves in Figure 4 have established
unicast connectivity across the cyphertext domain via the procedure
described in Section 2.2. Further assume that Host 4 is the source
of an plaintext multicast group G and the plaintext side of its VPN
router has been configured to join towards this group. Host 1 learns
of the SSM channel defined by Host 4 and Group G out of band. It
joins towards this channel through normal MLDv2 [rfc3810] multicast
listener report messaging. The plaintext side of its VPN router
receives the report, hashes the source prefix (Host 4) and the host
part of the plaintext group address G, and communicates the hashed
values to the ciphertext side.
The ciphertext side joins towards the ciphertext domain connecting
the enclaves using the source address formed by the procedure
described in Section 2.2 and a ciphertext group address formed by
combining its configured ciphertext multicast group prefix with the
hashed host part of the plaintext group address G. A source-specific
tree is constructed through the domain and a join reaches the
ciphertext side of the source enclaveÇÖs VPN router. The source VPN
router creates join state for the multicast channel on its ciphertext
side. When Host 4 transmits multicast packets on the channel, the
plaintext side of its VPN router passes the (encrypted) packet to the
cyphertext side along with a hash of the enclave unicast prefix and a
hash of the host part of the plaintext group address G. The packet
is forwarded down the source-specific tree within the ciphertext
domain towards the VPN router fronting Host 1. The VPN router
decrypts the packet and passes it to its plaintext 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 ciphertext domain, they
must know of each otherÇÖs configured ciphertext multicast prefixes
prior to establishing the source-specific tree. They may learn of
Baker, et al. Expires August 17, 2005 [Page 16]
Internet-Draft Routing in a Nested VPN February 2005
their respective ciphertext multicast prefixes through
pre-configuration, or they may inform each other following the
establishment of a unicast SA.
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 August 17, 2005 [Page 17]
Internet-Draft Routing in a Nested VPN February 2005
4. IANA Considerations
This document makes no request of the IANA.
Note to RFC Editor: in the process assigning numbers and building
IANA registries prior to publication, this section will have served
its purpose. It may therefore be removed upon publication as an RFC.
Baker, et al. Expires August 17, 2005 [Page 18]
Internet-Draft Routing in a Nested VPN February 2005
5. 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 plaintext addresses which are hashed to derive ciphertext
addresses. As an improvement to (static) configuration of ciphertext
addresses within the plaintext databases of the VPN enclave, the
automatic mechanism described in this document can easily complement
other security procedures such as ciphertext address change on a
pseudorandom or periodic basis without manual intervention.
Baker, et al. Expires August 17, 2005 [Page 19]
Internet-Draft Routing in a Nested VPN February 2005
6. Acknowledgements
Initial comment from Brian Weis and Dave McGrew was very helpful.
Baker, et al. Expires August 17, 2005 [Page 20]
Internet-Draft Routing in a Nested VPN February 2005
7. References
7.1 Normative References
[I-D.ietf-ssm-arch]
Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", Internet-Draft draft-ietf-ssm-arch-06, September
2004.
[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.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
7.2 Informative References
[I-D.ietf-rpsec-bgpsecrec]
Christian, B., "BGP Security Requirements",
Internet-Draft draft-ietf-rpsec-bgpsecrec-00, December
2004.
[I-D.ietf-rpsec-generic-requirements]
McPherson, D., "Generic Security Requirements for Routing
Protocols",
Internet-Draft draft-ietf-rpsec-generic-requirements-01,
January 2005.
[I-D.ietf-rpsec-ospf-vuln]
Jones, E. and O. Moigne, "OSPF Security Vulnerabilities
Analysis", Internet-Draft draft-ietf-rpsec-ospf-vuln-01,
December 2004.
[I-D.ietf-rpsec-routing-threats]
Barbir, A., Murphy, S. and Y. Yang, "Generic Threats to
Routing Protocols",
Baker, et al. Expires August 17, 2005 [Page 21]
Internet-Draft Routing in a Nested VPN February 2005
Internet-Draft draft-ietf-rpsec-routing-threats-07,
October 2004.
[I-D.puig-rpsec-rqts-opened-questions]
Puig, J., "Generic Security Requirements for Routing
Protocols - Opened Questions",
Internet-Draft draft-puig-rpsec-rqts-opened-questions-01,
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.
[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.
[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, March
2000.
[RFC2917] Muthukrishnan, K. and A. Malis, "A Core MPLS IP VPN
Baker, et al. Expires August 17, 2005 [Page 22]
Internet-Draft Routing in a Nested VPN February 2005
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.
[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.baker@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
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 August 17, 2005 [Page 23]
Internet-Draft Routing in a Nested VPN February 2005
Appendix A. Additional stuff
Baker, et al. Expires August 17, 2005 [Page 24]
Internet-Draft Routing in a Nested VPN February 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 August 17, 2005 [Page 25]
| PAFTECH AB 2003-2026 | 2026-04-23 13:47:08 |