Internet DRAFT - draft-baker-nested-vpn-routing
draft-baker-nested-vpn-routing
Network Working Group F. Baker
Internet-Draft Cisco Systems
Expires: April 24, 2006 P. Bose
D. Voce
Lockheed Martin
October 21, 2005
Routing across Nested VPNs
draft-baker-nested-vpn-routing-02
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 April 24, 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 April 24, 2006 [Page 1]
Internet-Draft Nested VPN Routing October 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 to a remote address . . . . . . . . . . . . . . . 13
2.4. Routing between enclaves . . . . . . . . . . . . . . . . . 14
2.4.1. Routing between enclaves across a common
ciphertext domain . . . . . . . . . . . . . . . . . . 14
2.4.2. Routing between enclaves across a multiple
ciphertext domains . . . . . . . . . . . . . . . . . . 14
2.5. Proving recursiveness . . . . . . . . . . . . . . . . . . 15
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. Operational Considerations . . . . . . . . . . . . . . . . . . 23
5.1. Scaling issues in host routing . . . . . . . . . . . . . . 23
5.2. The place of manual configuration and server-based
solutions . . . . . . . . . . . . . . . . . . . . . . . . 24
5.3. Use Case for Enterprise Network . . . . . . . . . . . . . 24
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
Baker, et al. Expires April 24, 2006 [Page 2]
Internet-Draft Nested VPN Routing October 2005
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. Normative References . . . . . . . . . . . . . . . . . . . 30
9.2. Informative References . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . . . 34
Baker, et al. Expires April 24, 2006 [Page 3]
Internet-Draft Nested VPN Routing October 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 April 24, 2006 [Page 4]
Internet-Draft Nested VPN Routing October 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 April 24, 2006 [Page 5]
Internet-Draft Nested VPN Routing October 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
Plaintext Domain: A network domain in which datagrams are sent
without additional encryption.
Ciphertext Domain: A network domain in which datagrams that
originated in a plaintext domain are sent with additional
encryption. Note that if there is an additional layer of
encryption in the network beyond that provided by a given
ciphertext domain, a ciphertext domain will be treated by that
ciphertext domain as if it were a plaintext 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 ciphertext or a plaintext
domain.
Baker, et al. Expires April 24, 2006 [Page 6]
Internet-Draft Nested VPN Routing October 2005
Enclave: A plaintext Domain, as seen from the ciphertext 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 plaintext and ciphertext 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 proposal that the
authors are aware of that truly leaks no information across domains
has scalability issues in networks larger than a few tens or hundreds
of enclaves (i.e. broadcast a request to all domains asking the right
one to respond). All other known approaches require some level of
sharing of knowledge between domains - the CE router creates, whether
through configuration or some more dynamic process, a tunnel to a
router across the ciphertext domain by connecting to a specified
ciphertext 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:
Plaintext Router: A router that is entirely within the plaintext
enclave network.
Baker, et al. Expires April 24, 2006 [Page 7]
Internet-Draft Nested VPN Routing October 2005
Ciphertext 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 Ciphertext
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 Plaintext 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.
Plaintext Router Ciphertext Router
+------------------+ +------------------+
|+----------------+| +--------+ |+----------------+|
||Configuration || |Network | ||Configuration ||
||Management ++----+Manager +----++Management ||
|+----------------+| +----+---+ |+----------------+|
| | | | |
|+----------------+| +----+---+ |+----------------+|
|| IP +-----+Encrypt/+-----+ IP ||
|+----------------+| |Decrypt | |+----------------+|
|+----------------+| +--------+ |+----------------+|
|| Link || || Link ||
|+----------------+| |+----------------+|
+------------------+ +------------------+
Figure 2: VPN Router Functional Breakdown
Typically the relationship between the different functions in
Figure 2 does not change for a given operational configuration and a
unique mapping exists between Plaintext IP address to Ciphertext IP
address. The hash function accepts a number of 0 to 64 bits and
Baker, et al. Expires April 24, 2006 [Page 8]
Internet-Draft Nested VPN Routing October 2005
hashes it 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 plaintext router (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 April 24, 2006 [Page 9]
Internet-Draft Nested VPN Routing October 2005
2. Unicast Routing Solution
+------+ +------+ +------+
|Host 1| |Host 2| |Host 3|
+--+---+ +--+---+ +--+---+
| | |
/--+-------------+-+--------------+---/
|
+------+------+
|+-----------+|
||plaintext ||
|+-----------+| VPN Router 1
| +--+ |
| +--+ |
|+-----------+|
||ciphertext ||
|+-----------+|
+------+------+
|
,-----------+-----------------.
( IP Network )
`-------------+---------------'
|
+----+--------+
|+-----------+|
||ciphertext ||
|+-----------+|
| +--+ |
| +--+ |
VPN Router 2 |+-----------+|
||plaintext ||
|+-----------+|
+------+------+
|
/---+--------------+-+-------------+--/
| | |
+---+--+ +---+--+ +---+--+
|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 ciphertext router of the VPN Router?
Baker, et al. Expires April 24, 2006 [Page 10]
Internet-Draft Nested VPN Routing October 2005
o How does the plaintext prefix of the upper LAN or address of Host
1 relate to routing?
o How does the corresponding ciphertext 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 ciphertext 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 routing protocols (e.g. IGP) 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 April 24, 2006 [Page 11]
Internet-Draft Nested VPN Routing October 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 plaintext 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 plaintext domain or disseminate them in other
ways.
As shown in Figure 5, knowing the prefix for the enclave LAN, the
plaintext router of the VPN Router hashes the prefix (the /64 or the
appropriate subset of it) and communicates the hashed value to the
ciphertext router. That interface is similarly engaged in stateless
address autoconfiguration. It uses the prefix from that router
(whether configured or learned) with the hashed value to form an
address for the ciphertext router.
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 ciphertext router.
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 ciphertext-router address is now included in routing in the IP
network on the ciphertext router 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 April 24, 2006 [Page 12]
Internet-Draft Nested VPN Routing October 2005
+----------------------+----------------------+
| 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 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 plaintext router, which
happens to be a VPN Router in this case. Processing in the VPN
router is a little different, however:
o The plaintext 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]). Accomplishing this requires
* Identifying the remote ciphertext router. The Network manager
enquires of the local ciphertext router whether there is one or
more host routes (/128) whose host part equals the hash of the
remote plaintext prefix.
Baker, et al. Expires April 24, 2006 [Page 13]
Internet-Draft Nested VPN Routing October 2005
* If so, it establishes a security association to the specified
address. It may try them sequentially or in parallel, and it
may choose to leave all such associations open or to close the
ones that are not useful, per local policy.
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 ciphertext
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 ciphertext datagram to
the ciphertext 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 ciphertext router presents the datagram to the
encrypt/decrypt unit, which decapsulates and decrypts it, and
presents the resulting datagram to the plaintext router.
2.4. Routing between enclaves
This system may obviously be used in two ways. It may be used across
a common ciphertext domain, or across multiple ciphertext domains
that route traffic through intermediate enclaves.
2.4.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.4.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
Baker, et al. Expires April 24, 2006 [Page 14]
Internet-Draft Nested VPN Routing October 2005
case, a network can be built across multiple plaintext domains.
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 plaintext router 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 ciphertext-router 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 ciphertext 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 ciphertext domain. It hashes the /64 of
the datagram's source address and passes that to the ciphertext
router. There is no corresponding security association, but
VPN6's ciphertext-router address shows up in routing, with R7 as
the next hop. VPN1 now opens a security association with VPN6,
meaning that its ciphertext router 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 ciphertext domain. It hashes the
/64 of the datagram's source address and passes that to its
ciphertext router. There is no corresponding security
association, but VPN8's ciphertext-router address shows up in
routing, with R9 as the next hop. VPN7 now opens a security
association with VPN8, meaning that its ciphertext router must
Baker, et al. Expires April 24, 2006 [Page 15]
Internet-Draft Nested VPN Routing October 2005
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)
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
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 April 24, 2006 [Page 16]
Internet-Draft Nested VPN Routing October 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 ciphertext router of the VPN
Router?
o How does the plaintext address Host 1 relate to routing of a
multicast group used by Host 1?
o How does the corresponding ciphertext group address relate to
routing?
o How does a host in a remote enclave determine the plaintext group
address and join it?
o How does a VPN Router in front of a remote enclave determine the
corresponding ciphertext 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 ciphertext router 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 plaintext group address.
Baker, et al. Expires April 24, 2006 [Page 17]
Internet-Draft Nested VPN Routing October 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 ciphertext domain
and unknown to the plaintext router
o The IPv6 prefix used for unicast addresses in the ciphertext
domain.
o The hashed prefix part of the plaintext router sender address
o The hashed "host part" of the plaintext router 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 ciphertext domain's prefix plus the hashed plaintext prefix form
the "sender address", identical to the ciphertext domain unicast
address. The ciphertext group address prefix plus the hashed host
part of the plaintext group address creates the ciphertext multicast
Baker, et al. Expires April 24, 2006 [Page 18]
Internet-Draft Nested VPN Routing October 2005
group. If a given host in the plaintext 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 ciphertext router of that system joins that
multicast group. As an example, assume that the enclaves in Figure 4
have established unicast connectivity across the ciphertext domain
via the procedure described in Section 2.2. Further assume that Host
4 is the source of a plaintext 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 plaintext router of VPN Router 1 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
router. This triggers a join toward the ciphertext multicast channel
supporting the plaintext channel. The original join is also directed
across a unicast security association to the plaintext router of VPN
Router 2, and continues joining toward Host 4.
The ciphertext router 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 router of the source enclave's VPN router. The source VPN
router creates join state for the multicast channel on its ciphertext
router. When Host 4 transmits multicast packets on the channel, the
plaintext router of its VPN router passes the (encrypted) packet to
the ciphertext router 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 router
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
their respective ciphertext multicast prefixes through pre-
configuration, or they may inform each other following the
establishment of a unicast SA.
Baker, et al. Expires April 24, 2006 [Page 19]
Internet-Draft Nested VPN Routing October 2005
One approach to distribution of the encryption key used by the
multicast data stream and the multicast group's group address in the
ciphertext 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 ciphertext 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 April 24, 2006 [Page 20]
Internet-Draft Nested VPN Routing October 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 April 24, 2006 [Page 21]
Internet-Draft Nested VPN Routing October 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 April 24, 2006 [Page 22]
Internet-Draft Nested VPN Routing October 2005
5. Operational Considerations
[RFC1958], in section 3, gives some general principles for making
Internet technology that works well. Key points include:
o Heterogeneity is inevitable and must be supported by design.
o All designs must scale readily to very many nodes per site and to
many millions of sites.
o Performance and cost must be considered as well as functionality.
o Keep it simple. When in doubt during design, choose the simplest
solution.
o Modularity is good. If you can keep things separate, do so.
From the viewpoint of constructing technology that scales to a large
network, this proposal obviously has some issues. One is that each
VPN Router ends up with a host route per VPN Router in the network,
which may have scaling issues and in any event makes route
aggregation difficult. Another is that other technologies, including
manual configuration and a form of database lookup, are already in
use and need to be integrated with - and may have long-term utility
in the network. This section attempts to address those issues.
5.1. Scaling issues in host routing
One of the principles that has improved Internet scaling is that of
information hiding: differing routing domains simple advertise a
prefix or set of prefixes to each other and hide internal structure.
Specifically, they don't advertise host addresses or LAN prefixes,
and in some cases prefixes belonging to multiple ISPs and edge
networks are aggregated to represent continental regions.
On the other hand, at this writing, the Internet backbone reportedly
carries about 150,000 routes in default-free routing. The conditions
under which this is true are that BGP routing is used between domains
and is essentially stable (a small percentage of routes are changing
at any given time, but the bulk of routes are stable), and some form
of link state routing is used within most non-edge domains. It seems
rational to expect that an IP-based network is capable of carrying on
the order of 50,000-75,000 host routes, 50-75K LAN routes within the
black domain, and some number of external routes, if the same
conditions apply. In general, given current technology, the matters
driving aggregation of routes are more related to information
assurance issues and administrative boundaries than the scaling of
routing.
Baker, et al. Expires April 24, 2006 [Page 23]
Internet-Draft Nested VPN Routing October 2005
Therefore, we initially recommend that in stable domains the number
of host routes within a single routing domain be engineered to not
exceed 50,000. This recommendation may change in operational
practice.
5.2. The place of manual configuration and server-based solutions
Currently, customer-provisioned VPNs (of which this is an example)
are generally configured manually. In certain cases, nested VPN
routing is being implemented using a database solution which may be
constructively compared to DNS: when an address or prefix must be
found dynamically, a query is sent to a server, which replies with
the necessary information.
We would suggest that these can be accommodated into this proposal if
the lookup for a Security Association follows this rule:
o If a security association exists, it should be used. This would
include any security association which had been set up dynamically
as a result of some previous exchange, or any manually configured
association.
o Failing that, the routing table may be inquired of using an
appropriate API. If a host route is found, the approach suggested
in this document applies.
o Failing that, the server should be queried.
o Failing that, the peer is unknown.
5.3. Use Case for Enterprise Network
The applicability of the rule described in Section Section 5.2
can be understood under the context of the use case shown in
Figure 8.
Baker, et al. Expires April 24, 2006 [Page 24]
Internet-Draft Nested VPN Routing October 2005
_.--------.
,-'' `--.
,' PT Enclave 1 `.
,' +-----------+ `.
/ R1.H1 |PT-Router-1| \ ,---.
; |...........| : / \
|--------|E/D :: Mgmt|--------| / CT \
: |...........| ; B1.h(R1) ( Hub )
\ |CT-Router-1|.........................\ B1.H0 /
`. +-----------+ ,' .-'\ /
`. CT Enclave 1 ,' .' `--+'
`--. _.-' .-' |
`--------'' .-' |
.-' |
B1.h(R3).' |B1.h(R3)
_.--------. .-' _.---+----.
,-'' `--. .-' ,-'' | `--.
,' CT Enclave 2 .'. ,' CT Enc|ave 3 `.
,' +-----------.-' `. ,' +-----+-----+ `.
/ |CT-Router 2| \ / |CT-Router-3| \
; |...........| : ; |...........| :
|--------|E/D :: Mgmt|--------| |--------|E/D :: Mgmt|--------|
: |...........| ; : |...........| ;
\ R2.H2 |PT-Router-2| / \ R3.H3 |PT-Router-3| /
`. +-----------+ ,' `. +-----------+ ,'
`. PT Enclave 2 ,' `. PT Enclave 3 ,'
`--. _.-' `--. _.-'
`--------'' `--------''
Figure 8: Routing in a Hub & Spoke VPN
Figure 8 depicts a simple hub and spoke enterprise network employing
the VPN routing approach described in this draft. Three VPN enclave
sites are connected to each other via the ciphertext hub which also
serves the enterprise headquarters and connects to the Internet.
Multiple security associations between any two sites may be set up as
neccessary. A typical operational scenario employing the solution
described in this document would apply as follows:
o The ciphertext address of VPN router (e.g. B1.h(H1)) at any given
site is derived from the plaintext address of the VPN router (e.g.
R1.H1) via the hash rule described in Section 1.4
o In this scenario both manual configuration or host routes would
serve as a simple mechanism to route to a remote ciphertext
address. If the enclave sites are expected to setup on-demand
security associations between sites due to traffic needs or
mobility, then host routes would better serve this dynamic nature
Baker, et al. Expires April 24, 2006 [Page 25]
Internet-Draft Nested VPN Routing October 2005
of the network. [Note: Scalability of host routes in such an
enterprise network of even hundreds of enclaves is well within the
limits of know network routing scalability].
Baker, et al. Expires April 24, 2006 [Page 26]
Internet-Draft Nested VPN Routing October 2005
6. IANA Considerations
This memo adds no new 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 April 24, 2006 [Page 27]
Internet-Draft Nested VPN Routing October 2005
7. 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
pseudo-random or periodic basis without manual intervention.
Baker, et al. Expires April 24, 2006 [Page 28]
Internet-Draft Nested VPN Routing October 2005
8. Acknowledgements
Commentary from Brian Weis and Dave McGrew was very helpful. Some
concepts and questions also came from Bharat Doshi and his associates
of the US DoD GIG Routing Working Group. Comments by Eric Fleischman
helped improve the document.
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 April 24, 2006 [Page 29]
Internet-Draft Nested VPN Routing October 2005
9. References
9.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-07 (work in progress),
October 2005.
[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.
9.2. Informative References
[I-D.ietf-rpsec-bgpsecrec]
Christian, B. and T. Tauber, "BGP Security Requirements",
draft-ietf-rpsec-bgpsecrec-02 (work in progress),
July 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 April 24, 2006 [Page 30]
Internet-Draft Nested VPN Routing October 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.
[RFC1958] Carpenter, B., "Architectural Principles of the Internet",
RFC 1958, June 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.
Baker, et al. Expires April 24, 2006 [Page 31]
Internet-Draft Nested VPN Routing October 2005
[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
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.
Baker, et al. Expires April 24, 2006 [Page 32]
Internet-Draft Nested VPN Routing October 2005
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
700 North Frederick Ave
Gaithersburg, Maryland 20871
USA
Phone: +1-301-240-7041
Fax: +1-301-240-5748
Email: pratik.bose@lmco.com
Dan Voce
Lockheed Martin
3201 Jermantown Road
Fairfax, Virginia 22030
USA
Phone: +1-703-293-5732
Fax: +1-703-293-4460
Email: daniel.voce@lmco.com
Baker, et al. Expires April 24, 2006 [Page 33]
Internet-Draft Nested VPN Routing October 2005
Full 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.
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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Baker, et al. Expires April 24, 2006 [Page 34]
