Network Working Group M. Bagnulo
Internet-Draft Huawei Lab at UC3M
Intended status: Standards Track March 4, 2007
Expires: September 5, 2007
Proxy Shim6 (P-Shim6)
draft-bagnulo-pshim6-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 September 5, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This draft discusses extensions to the shim6 architecture to support
shim6 proxies that would allow the provision of the following
capabilities:
o Provide Upper Layer Identifier portability.
o Provide Traffic Engineering policy enforcement.
o Off-load of the shim6 context management from the actual peers of
the communication.
Bagnulo Expires September 5, 2007 [Page 1]
Internet-Draft P-Shim6 March 2007
o Enable legacy IPv6 nodes located in the multihomed site to obtain
full multihoming support (no modification of the end nodes).
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Components . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Centrally Managed Unique Local Addresses . . . . . . . . . 8
4.2. DNS component . . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. Reverse DNS . . . . . . . . . . . . . . . . . . . . . 8
4.2.2. DNS Application Level Gateway . . . . . . . . . . . . 8
4.3. DHCP server component. . . . . . . . . . . . . . . . . . . 9
4.4. Proxy-shim component . . . . . . . . . . . . . . . . . . . 9
4.5. Firewall component . . . . . . . . . . . . . . . . . . . . 10
5. Application scenario . . . . . . . . . . . . . . . . . . . . . 10
6. Protocol walkthrough . . . . . . . . . . . . . . . . . . . . . 11
6.1. Fault Tolerance. . . . . . . . . . . . . . . . . . . . . . 14
6.1.1. Path Failures. . . . . . . . . . . . . . . . . . . . . 14
6.1.2. Multiple P-Shim6 support. . . . . . . . . . . . . . . 14
6.1.3. P-Shim6 fault tolerance. . . . . . . . . . . . . . . . 15
7. Support for legacy sites and hosts. . . . . . . . . . . . . . 16
8. Compatibility with host based shim6 . . . . . . . . . . . . . 17
9. Alternative Design Choices . . . . . . . . . . . . . . . . . . 17
10. Other security mechanisms . . . . . . . . . . . . . . . . . . 21
11. Incompatibilities. . . . . . . . . . . . . . . . . . . . . . . 22
12. Security Considerations. . . . . . . . . . . . . . . . . . . . 22
13. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 22
14. Change History . . . . . . . . . . . . . . . . . . . . . . . . 23
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
15.1. Normative References . . . . . . . . . . . . . . . . . . . 23
15.2. Informative References . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 25
Bagnulo Expires September 5, 2007 [Page 2]
Internet-Draft P-Shim6 March 2007
1. Introduction
The shim6 architecture [11] provides scalable support for IPv6 end
site multihoming. As opposed to the BGP-style multihoming, where the
multihomed site injects its own prefix through the different
providers, in the shim6 approach, a multihomed site obtains a Provier
Aggregatable (PA) prefix from each of its providers' address blocks.
This enables aggressive prefix aggregation in the global routing
table, since the multihomed site prefixes do not need to be announced
independently in the global routing table and only ISP PA prefixes
are visible in the Default Free Zone. From the multihomed site
perspective, this configuration results in the presence of multiple
prefixes in the site (one per provider) and multiple global addresses
configured in the hosts (again, one per provider). The goal of the
shim6 protocols [6] [8] is to preserve established communications
through outages in the paths to the multihomed site. The shim6
protocol [6] is an end-to-end protocol that is used to create shim6
contexts between the peers of a communication that contain the
different addresses available for the communication. The shim6
architecture inserts a shim6 sublayer between the IP endpoint
sublayer and the IP forwarding sublayer. The shim6 sublayer uses the
shim6 context state to map between the address used by the upper
layers (know as the Upper Layer Identifier ULID) and the actual
addresses used for forwarding packets (called locators). The shim6
peers use the shim6 protocol to securely exchange the multiple
addresses available for each end of the communication so that in case
a failure is detected in the communication path, an alternative
address can be used as locator, while still presenting an unchanged
ULID.
Summarizing, the main characteristics of the shim6 architecture are:
o One prefix per ISP (PA addressing), resulting in multiple
addresses per host.
o All the addresses can be used as ULID and/or locators for any
communication.
o The involved protocols (shim6 protocol and REAP protocol) are end-
to-end protocols used to securely create and manage the ULID-
locator binding information.
The result is a clean architecture where the peers are aware of the
multiple addresses and can securely exchange context information that
binds all the different addresses of a given host. In addition, the
failure detection and recovery is also performed end to end providing
optimal fault tolerance within the fate-sharing region.
However, it has been pointed out [10] that the shim6 protocol does
fail to provide some key features provided by current BGP-based
approach to multihoming. In particular, the shim6 approach fails to
Bagnulo Expires September 5, 2007 [Page 3]
Internet-Draft P-Shim6 March 2007
provide the so-called portability of the address block used by the
multihomed site. This basically means that when a multihomed end
site changes one of its providers, the addresses associated to this
ISP need to be renumbered. Renumbering may be a costly and painful
process, so imposing address renumbering when changing providers does
increase provider lock-in. Another capability that is missing in the
shim6 architecture is traffic engineering policy enforcement
capabilities. The shim6 approach supports some forms of traffic
engineering, but because of its end-to-end nature, the traffic
engineering capabilities are available at the end-nodes, making it
hard to actually enforce the traffic engineering policies at a site
level. Finally, it has also been mentioned that for deployment and
performance issues, it may be important to be able to off-load the
shim6 context management from the end nodes to specialized middle
boxes.
This draft proposes some ideas to extend the shim6 architecture to
support shim6 proxies that would allow the provision all the
aforementioned capabilities and discusses difficult issues with it..
2. Goals
The goals of the design of shim6 proxies are the following:
o Provide Upper Layer Identifier portability.
o Provide Traffic Engineering policy enforcement.
o Off-load of the shim6 context management from the actual peers of
the communication.
o Enable legacy IPv6 nodes located in the multihomed site to obtain
full multihoming support (no modification of the end nodes).
o Do not require any modification to the routers of the "core".
o Allow shim6 peers to communicate with nodes served by a P-shim6
box while benefiting of the multihoming features.
o Do not introduce additional vulnerabilities to the Internet.
The goal of this draft is to provide an in depth discussion of the
difficult issues that need to be taken into account when designing a
proxy type of solution. Since we think that the difficulties are
more clearly identified when the details are fleshed out, we have
decided to use existent tools for the provision of the needed
services. In particular, we have decided to use Centrally Managed
Unique Local Addresses which have been discussed previously, as
provider independent ULIDs. In addition, we have decided to use the
reverse DNS to retrieve locator information for those ULIDs. It
should be noted that it would be possible to use alternative ULIDs
and alternative mechanisms to retrieve the locator information, but
we consider that using existent tools would help to have a clearer
picture of the issues involved. See Section "Alternative Design
Bagnulo Expires September 5, 2007 [Page 4]
Internet-Draft P-Shim6 March 2007
choices" for additional information.
3. Overview
In this approach, a multihomed site obtains a PA prefix from each of
its providers and a non-routable Provider Independent prefix from a
central registry (e.g. a Centrally Managed Unique Local Address
(CMULA) prefix [12]).
Hosts within the multihomed site are IPv6 hosts without any shim6
support and they are configured only with a single address containing
the CMULA prefix. This means that the addresses configured to the
hosts in the multihomed site do not depend of the ISPs and that a
change in the ISP would not imply a renumbering of the hosts of the
multihomed site. In this approach, all the addresses information is
published in the DNS. PA addresses are published in AAAA RR while
CMULAs are published in a new ULID RR.
The multihomed site is served by one or more Proxy-Shim6 (P-shim6)
boxes. The P-Shim6 box will execute the shim6 protocol on behalf of
the hosts of the multihomed site.
The peer of a external communication can be a host located in another
multihomed site or in a single-homed site. In any case, in order to
enable the shim6 support for the communication, either the peer needs
to be shim6-capable or it is behind another P-shim6 box that is
executing the shim6 protocol on its behalf. In the latter case, the
result is that the shim6 protocol is executed between the P- shim6
boxes that are serving each of the peers of the communication.
The proposed approach would work as follows.
When a (non-shim6 capable) host H1 located within the multihomed site
(see figure 1 below) initiates a communication with a peer host H2,
H1 normally performs a DNS query searching for H2.foo.com. The query
processed by a DNS ALG located in the P-Shim6 box of the multihomed
site and both AAAA and ULID records are queried for. The reply is
processed by the DNS ALG of the multihomed site and only the CMULA is
returned to H1 in a AAAA RR. From the perspective of the legacy host
H1 within the multihomed site, it is a regular DNS query that has
returned a single AAAA record. In addition to that, the P-Shim6 box
stores the PA address information returned in the original DNS reply
in the AAAA RR associated to the CMULA identifier obtained.
When H1 sends the first packet addressed to the CMULA of H2, the
packet is intercepted and processed by the P- Shim6 box of the
multihomed site. The P-Shim6 box retains the data packet and
Bagnulo Expires September 5, 2007 [Page 5]
Internet-Draft P-Shim6 March 2007
initiates the 4-way exchange to create a shim6 context with the
P-shim6 box of the peer network. This exchange uses the PA addresses
as locators and the CMULAs as ULIDs. Once that the shim6 context is
established between the local P-shim6 box and the remote P- Shim6
box, the local P-Shim6 box can forward the data packet with a shim6
payload header, referring to the established shim6 context.
This communication is now protected by the shim6 protocol, in the
sense that the reachability detection mechanisms of the REAP protocol
will monitor the path availability of the communication. In case a
failure is detected, alternative locator pairs will be explored and
the communication will be diverted to the alternative locator pair
that is available. Once that the communication stops, the P-shim6
boxes discard the associated shim6 state.
The result is that the legacy nodes within the multihomed site
benefit from the multihoming fault tolerance capabilities. Besides,
the hosts only have provider independent (non routable) addresses
configured, reducing the renumbering costs in case of a change of
providers. Finally, the P-shim6 box is the one managing the locator
set, so it is capable of enforcing traffic engineering policies for
the site and it can also off-load the shim6 processing from hosts
within the multihomed site.
Bagnulo Expires September 5, 2007 [Page 6]
Internet-Draft P-Shim6 March 2007
+---------------------------------------------+
| Multihomed site |
| Prefixes : PA1, PA2, PU |
| +---------+ |
| |non-shim6| |
| | host H1 | +---------+ |
| +---------+ | DNS ALG | |
| | PU:H | P-shim6 | |
| -------------------- +---------+ |
| | | |
| ------------------------------- |
| | | |
| +--------+ +---------+ |
| |Router 1| | Router 2| |
| +--------+ +---------+ |
+---------------|------------------|----------+
| |
+-------+ +-------+
| ISP 1 | | ISP 2 |
+-------+ +-------+
| |
+------------------------------------+
| Internet |
+------------------------------------+
|
+-------+
| ISP 3 |
+-------+
|
+------------------------------------|-------+
| +--------+ +--------+ +--------+|
| |Host H2 | |P-shim6'| |Router 3||
| +--------+ +--------+ +--------+|
| H2.foo.com | | | |
| PU':H | | | |
| ---------------------------------------- |
| Site foo.com Prefixes: PA3, PU' |
+--------------------------------------------+
Figure 1
4. Components
The proposed P-shim6 approach has the following components:
Bagnulo Expires September 5, 2007 [Page 7]
Internet-Draft P-Shim6 March 2007
4.1. Centrally Managed Unique Local Addresses
In the P-shim6 approach, the hosts within the multihomed site are
configured with a single address, the ULID. It is proposed that in
order to provide address portability, the ULID used are a form of
Centrally Managed ULAs (CMULAs) [12]. CMULAs have been proposed
before and while the exact form of the addresses does not need to be
the one proposed in the past, the following characteristics are
required by the P-shim6 approach:
o They must be globally unique.
o They must not be dependent of the location of the network to which
they are assigned.
o They are permanently allocated to the end site.
So, in the P-shim6 approach, an end site can obtain a CMULA block
that is independent of its ISP and it will be used as ULIDs for shim6
contexts.
4.2. DNS component
As we mentioned above, the hosts within the multihomed site are
configured with a single CMULA, which are by definition non globally
routable. In order to allow external peers to initiate
communications using the CMULAs as ULIDs, it is necessary to publish
these CMULAs in the DNS. However, these CMULAs are not globally
routable, so, in order to prevent an external non-shim6 aware node to
try to use the CMULAs as a regular routable address, it is necessary
to store the CMULAs in a different DNS resource record. It is then
proposed the definition of a new ULID RR for storing ULIDs. So, the
DNS of the multihomed site is configured to publish routable
addresses in AAAA records and CMULAs in the new ULID records.
4.2.1. Reverse DNS
The reverse tree of the DNS is used to retrieve the locator set
associated to the CMULAs in case that there is no cached locator
information available. This basically requires that the reverse DNS
tree of the CMULAs is properly populated. So when a reverse DNS
lookup is performed for a CMULA, the FQDN is returned and the locator
information can be included in the additional information field of
the DNS reply.
4.2.2. DNS Application Level Gateway
In the proposed shim6 approach, the goal is that communicating peers
located in different sites communicate using the ULAs as ULIDs. In
order to achieve that, when a (legacy) host located behind the
P-shim6 within the multihomed site performs a DNS query to initiate a
Bagnulo Expires September 5, 2007 [Page 8]
Internet-Draft P-Shim6 March 2007
communication with the remote host that is located behind another
P-shim6 box, the CMULA should be returned in the AAAA record
correspondent to the FQDN queried. However, in the DNS configuration
described in the previous paragraph, the CMULAs are stored in the
ULID RR and the routable addresses are stored in the AAAA records, so
if no additional processing is performed, the hosts behind the
P-shim6 box would use the PA addresses as ULIDs.
The P-shim6 needs a DNS ALG component that transform the DNS reply so
that the CMULA is included in the AAAA RR and the routable addresses
are removed from the reply. In addition, the DNS ALG component
should store the routable addresses associated to the CMULA, so that
they can be used to establish the shim6 context for that (future)
communication.
For intra-site communications, hosts will use CMULAs. So, in this
case, the DNS should also return the CMULAs of the internal hosts in
AAAA records for internal queries. So again, the DNS ALG should
process the DNS reply so that the CMULAs are returned in AAAA
records.
4.3. DHCP server component.
The shim6 security relies on the usage of CGA or HBA [5], [7]
addresses to protect the binding between the ULID and the locator
set. In order to extend the shim6 approach to shim6 proxies, it is
necessary that the addresses configured in the hosts within the
multihomed site are CGAs or HBAs. However, as the hosts themselves
are not involved in the shim6 protocol, the end hosts do not need to
be aware that the address assigned is a CGA or HBA neither they need
to know the associated parameters. So, in the P-shim6 approach, the
CGA and HBA addresses are generated by the proxy (which stores the
correspondent parameters) and then, they are assigned to the end
hosts using the DHCP protocol [2]. This is performed by the DHCP
component of the P-shim6.
4.4. Proxy-shim component
Once that a host behind the P-Shim6 initiates a communication sending
a packet containing an external CMULA as destination address and a
CMULA as source address, the packet is intercepted by the P-shim. At
this moment the P-Shim6 establishes a shim6 context with the shim6
peer or the shim6 proxy of the peer. Once that the context has been
established the packets are translated and locators associated to the
established context are included in the address fields of the packet.
These functions are performed by the Proxy-shim component.
Bagnulo Expires September 5, 2007 [Page 9]
Internet-Draft P-Shim6 March 2007
4.5. Firewall component
In order to provide address portability, it is desired that the
CMULAs are used instead of the routable addresses in the
configuration data on any process that needs to hardcode addresses.
In particular, it is expected that CMULAs are used in filters and ACL
in firewalls. However, in order to do that, the firewall must be
placed behind the P-shim, so that packets carry CMULAs and not
locators. It is possible then to include a firewall component in the
P-shim6 so that packets can be filtered as soon as the locators are
translated into CMULAs.
5. Application scenario
The P-Shim6 approach is used in the following scenario (see figure
1). Consider a multihomed site served by ISP1 and ISP2. Each of the
ISPs delegates a Provider Aggregatable address block to the
multihomed, prefixes PA1 and PA2 respectively. Since addresses are
PA, the address block delegated by ISPA can only be reached through
ISPA and the address block delegated by ISPB can only be reached
through ISPB. Besides, we assume that ISPs are performing ingress
filtering, meaning that packets containing source address belonging
to the address block delegated by ISPA(B) can only exit through
ISPA(B).
In addition, an CMULA block (prefix PU) is delegated to the site so
that they can be used as ULIDs for shim6 communications.
So, each host within the multihomed site has conceptually 3 addresses
i.e. a CMULA from prefix PU and one address per PA prefix available
in the site, prefixes PA1 and PA2.
If HBAs are used, then the HBA set must be generated using the 3
prefixes available for the site. The HBA technology is less
demanding in terms of CPU processing, since it doesn't requires
performing public/private key cryptographic operations. However, the
usage of HBA technology would defeat the goal of portability, since a
change in the prefix set available in the site would result in a
change in the addresses, in particular in the CMULAs assigned to the
hosts. So in order to provide ULID portability, CGA technology needs
to be used.
If CGAs are used, it is necessary to generate the CMULAs assigned to
the hosts within the multihomed site as CGAs. However, because the
shim6 processing will be performed by the P-shim, the CGA Parameter
Data Structure and the associated private key must be known by the
P-shim6 box and not by the end host itself. The proposed approach is
Bagnulo Expires September 5, 2007 [Page 10]
Internet-Draft P-Shim6 March 2007
that the DHCP component of the P-Shim6 generates CMULA CGAs on behalf
of the hosts that are located behind the proxy and it stores the
associated parameters (CGA parameter Data structure and private key).
Once that the CGA CMULA is generated, it is assigned to the host
using the DHCP protocol as a regular address i.e. the host does not
need to be aware that the assigned address is a CGA.
Observations:
a. It is possible for the P-Shim6 to generate all the CMULA CGA
using the same key pair, and only changing the Modifier field of
the CGA Parameter Data Structure. This allows the P-shim6 box to
only have a single key pair for all its shim6 contexts.
b. It is possible to use Multi-key CGA [14] in two cases:
1. When the hosts within the multihomed site need to use CGA for
other protocols, such as SeND [4]. In this case, the CGA
will have two keys, the key of the host to do SeND and the
key of the P- Shim6 to do shim6. Additional mechanisms to
allow the DHCP server to learn the public key of the host and
to allow the DHCP server to convey the CGA Parameter Data
Structure are needed.
2. When there are multiple P-Shim6 and each of them has a
different key pair. In this case, in order to provide fault
tolerance when one of the proxies fails, the CMULA CGAs need
to be generated containing both public addresses.
In addition to the CMULA CGA, the P-shim6 will (virtually) assign one
address from each PA prefix available in the multihomed site to each
host. Such address is not configured in the host itself, since they
only play the role of locator, so they are only used by the P-shim.
Besides, the hosts served by the P-Shim6 need to be configured with
the P-Shim6 as a DNS server (in order to use the DNS ALG) and packets
generated by the hosts served by the P-Shim6 containing a destination
address with a CMULA prefix need to be routed through the P-shim.
Similarly, incoming packets addressed to the PA prefixes used by the
P-Shim6 box are routed to the P-Shim6 box to be processed before
delivery to the end nodes.In general, the P-Shim6 is implemented as a
stand- alone box, and it must inject a route to the CMULA prefix and
a route to the PA prefixes it is using, so that all packets addressed
to CMULAs and to its PA prefixes are sink to the P-shim6 box.
6. Protocol walkthrough
In summary, the P-Shim6 application scenario is the following
(depicted in figure 1):
Bagnulo Expires September 5, 2007 [Page 11]
Internet-Draft P-Shim6 March 2007
o The site has 3 prefixes: PA1, a PA prefix delegated by ISP1 from
its own PA block, PA2, a PA prefix delegated by ISP2 from its own
PA block and PU, a CMULA block, obtained by the site,
independently of its providers.
o The hosts within the site have obtained addresses containing PU
from the DHCP server of the P-shim. The delegated addresses are
CGAs, and the P-Shim6 stores the associated information, including
the key pair and the CGA Parameter Data Structure corresponding to
each delegated address.
o The hosts within the site have configured the P-Shim6 as their DNS
server, so they will forward all DNS queries to it.
o The P-Shim6 box is announcing routes in the IGP towards the
generic prefix of the CMULAs and to the PA prefixes used by the
P-Shim6 approach to generate locators. The first route sinks
outgoing packets containing a CMULA destiantion address and the
second route will sink incoming packets containing locators as
destiantion addresses (instead of ULIDs). We are assuming that
the intra site is announcing more specific routes to the
interanlly used CMULA prefixes, so that internal communications
that use the CMULA assigned prefix will not be sink to the P-Shim6
box.
With this setup, the behaviour of the P-Shim6 solution is the
following:
1. A host H1 behind the P-Shim6 wants to initiate a communication
with a host H2 located outside the multihomed site with FQDN
H2.foo.com. For that, it performs a DNS query to its DNS server
(the P-Shim6 box) for H2.foo.com.
2. The P-Shim6 box performs a DNS query for H2.foo.com. If the
query returns a ULID RR and one or more AAAA/A records, then the
P-Shim6 stores the information about the ULID and the associated
locators and returns a single AAAA RR in the reply containing the
CMULA (PU':H2) to H1. At this point, the P-Shim6 can assume that
H1 will start sending data packets to that destination and it can
initiate the 4-way handshake defined in the shim6 protocol to
establish a shim6 context. The other option is to wait until the
reception of the first data packet addressed to the CMULA.
3. When the host H1 receives the DNS reply containing a CMULA PU':H2
in the AAAA record, it will start sending packet to the received
address. Because of the longest prefix match of the address
selection algorithm defined in RFC3484 [3], host H will choose
the CMULA as source address.
4. The intra site routing will forward packets containing an
external CMULA as destination address to the P-Shim6 box. When a
packet containing a CMULA as a destination address arrives, the
P-Shim6 box performs the following processing:
Bagnulo Expires September 5, 2007 [Page 12]
Internet-Draft P-Shim6 March 2007
A. If a shim6 context exists with the addresses contained in the
packet as ULID pair, then it uses the existing shim6 context
to process the packet (the context may be already in use, or
may be just created when the DNS reply was received).
B. If no shim6 context exists, but there is locator information
associated to the CMULA contained in the destination address
(cached from the DNS reply), it will use that locator
information to initiate the 4-way handshake to create a shim6
context for that ULID pair. Once that the shim6 context is
established, it is used to process the packet.
C. If no shim6 context exits and there is no locator information
associated to the destination CMULA cached, the P-Shim6 box
performs a DNS reverse lookup on the CMULA contained in the
destination address field, and it obtains the locator set
associated to the CMULA. Once that the locator information
is obtained, the 4-way handshake used to establish the shim6
context is performed. Once that the shim6 context is
established, it is used to process the packet.
5. From the H2 (the receiver) perspective, incoming packets are
forwarded to the P-Shim6 box:
A. If the packet is an I1 or an I2 packet of the shim6 protocol,
it will continue with the 4-way handshake for the
establishment of the shim6 context.
B. If the packet is a payload packet and the P-Shim6 box has an
existent context associated with it, it will process the data
packet and replace the locators by the associated identifiers
and the forward the packet to the final destination.
C. If the packet is a payload packet and the P-Shim6 box does
not have an associated shim6 context, it will initiate the
context recovery procedure, sending a R1bis packet back, so
that context can be restored.
6. Once that the shim6 context is established, the communication
continues and both P-Shim6 boxes perform the translation between
ULIDs and locator pairs as needed. In addition the REAP protocol
for failure detection and alternative path exploration is used
when needed, as defined in the shim6 protocol.
7. When the communication is finished, the P-Shim6 boxes will use
some heuristics to discard the shim6 context.
The P-Shim6 box is a stand alone box and we have presented mechanisms
to divert the traffic towards those P-Shim6 boxes. Because of
ingress filters, it may be necessary to route packets containing a
given prefix in the source address through the ISP that has delegated
this prefix. This can be achieved using tunnels from the P-Shim6 box
to the exit routers, and allowing the P-Shim6 box to route packets
containing a given prefix in the source address through the
correspondent ISP.
Bagnulo Expires September 5, 2007 [Page 13]
Internet-Draft P-Shim6 March 2007
6.1. Fault Tolerance.
6.1.1. Path Failures.
The shim6 protocol executed between the P-Shim6 boxes will use the
REAP protocol to detect failure along the communication path and
explore alternative paths. Once a failure is detected and an
alternative path is discovered, the P-Shim6 will divert the existent
context affected by the failure through the new path, using the
associated locator pair.
It should be noted that it is also possible to feed the P-Shim6 box
with additional information that can be used for failure detection.
In particular, the P-Shim6 box can be feed with BGP information from
the different ISPs. In this case, the P-Shim6 box would have access
to routing information and could divert the communication through
alternative ISP in case of a failure. In this case, it is also
possible for the P-Shim6 box to inform the P-Shim6 peer that a given
locator is no longer reachable using the BROKEN flag of the Locator
Preference Option defined in the shim6 protocol
6.1.2. Multiple P-Shim6 support.
Since the main goal of multihoming is fault tolerance, it is critical
to support multiple P-Shim6 boxes in a multihomed site and that
established communications can be preserved in case of a failure in
the P-shim6 box that is being used for that communication. This can
be done using the shim6 context recovery features.
We will next consider the setup required to support multiple P-Shim6
in a single site. The described configuration uses one P-shim6 box
as the primary proxy for the multihomed site and the other P-shim6
box as a backup in case the primary box fails.
The interaction between the P-Shim6 box and the host being served by
it involves the following interactions:
1. Delegation of CGA/HBA CMULA and storing the associated
parameters.
2. The host uses the P-Shim6 as DNS server and the P-Shim6 box
performs as a DNS ALG.
3. All packets generated by the host that are addresses to an
external destination pass through the P-Shim6 box, which
establishes the correspondent shim6 context and then performs the
appropriate ULID-locator translation.
4. All incoming packet for that hosts are processed by the P-Shim6
host, which restores the ULIDs.
It should be noted that all these operations result in state in the
Bagnulo Expires September 5, 2007 [Page 14]
Internet-Draft P-Shim6 March 2007
P-Shim6 box.
With respect to the CGA related information, all the P-Shim6 boxes
within a site must have access to the CGA Parameter Data structure of
each CMULA address assigned to a host within the site. With respect
to the private key information, there are two options: one is that
the same private key is distributed to all the P-Shim6 boxes within a
site. The difficulty with this approach is that private key
distribution always implies security risks. The other option would
be to use multi-key CGAs. In this approach, each P-Shim6 box would
have a key pair, and the CGAs assigned to the hosts within the site
would contain the public key information of all the P-Shim6 boxes,
allowing all of them to establish shim6 contexts on behalf of any of
the nodes.
With respect to the other interaction, the configuration required is
the following:
o With respect to the DNS server component. It is possible to
configure a primary DNS server and a secondary DS server in the
hosts. The primary DNS server would be the primary P-Shim6 box
and the secondary DNS server would be the backup P-Shim6 box. The
hosts will always try with the primary DNS server first, and in
case there is a timeout, they will retry with the secondary one.
o With respect to outgoing data packets, they must be forwarded
through the primary P-Shim6 box as long it is working. This is
achieved by configuring the primary P-Shim6 box to announce a
route towards the generic CMULA prefix with a high priority and
the backup P-Shim6 box to announce a route to the generic CMULA
prefix with a low priority. In case of a failure of the primary
P-Shim6 box, the associated route would disappear and the
alternative routes associated to the backup P-Shim6 box would be
used.
o With respect to incoming packets, the primary P- Shim6 box will
announce a route to the globally routable prefixes used to
generate locators for the hosts within the multihomed site with a
high preference, so that all packets coming from the Internet are
sink to the primary P-Shim6 box. The backup P-Shim6 box also
announce a route to these prefixes, but with a lower preference.
6.1.3. P-Shim6 fault tolerance.
In case the primary P-Shim6 box fails, the ongoing communications
that have been established by the P-Shim6 box need to be preserved.
This can be done by diverting the communications towards the
secondary P-Shim6 box and allowing it to recover the shim6 context
associated with the ongoing communication.
We assume that when a P-Shim6 box fails, the associated routes are no
Bagnulo Expires September 5, 2007 [Page 15]
Internet-Draft P-Shim6 March 2007
longer announced. This implies that the routes to the secondary P-
Shim6 box will become the preferred ones.
So, after the primary P-Shim6 box has failed, the following packets
that belong to an ongoing communication can reach the secondary
P-Shim6 box:
o An incoming packet with a destination address containing the
global prefix of the primary P-Shim6 box and a Payload header with
a context tag (this can be a data packet or a probe packet from
the REAP protocol). The secondary P-Shim6 box will receive the
packet and it will find that there is no existent context for that
packet. The secondary P-Shim6 box will reply with a R1bis packet
and the context recovery mechanism of the shim6 protocol will be
executed. This consists in a 3 way handshake with the other end
which results in the recovery of the lost context.
o An outgoing packet coming from one of the internal hosts is
received. The secondary P-Shim6 box will unsuccessfully look for
an existent shim6 context of for cached locator information
retrieved from the DNS query. Since there is no locator
information associated with the destination identifier, it will
perform a reverse DNS query and it will obtain the locator
information. At this point it will perform the 4 way handshake
and the shim6 context will be re-established.
7. Support for legacy sites and hosts.
In order to allow communication between hosts within the multihomed
site and external non-shim6 hosts that are not served by any P-Shim6
we will need additional tools. In this section we will consider two
approaches to communicate with legacy IPv6 hosts.
A first option would be to configure globally routable addresses from
the prefixes delegated by the ISPs to the nodes within the multihomed
sites. According to the longest prefix match defined in RFC3484,
CMULA source addresses are preferred over PA addresses when the
destination address is also a CMULA and that PA addresses are
preferred as source addresses when the destination address is a
globally routable address. This implies that hosts would select
globally routable addresses when communicating with other globally
routable addresses and the P-Shim6 would not intervene in such
communications. However, it should be noted that allowing the hosts
to have access to global routable addresses enable the host to bypass
the P-Shim6 diminishing the capability of the P-Shim6 to enforce
traffic engineering policies. The configuration of PA addresses in
the hosts also imposes additional renumbering cost when changing ISP,
limiting the benefit of portability. The trade-offs involved in this
scenario are: portability and TE enforcement versus backward
Bagnulo Expires September 5, 2007 [Page 16]
Internet-Draft P-Shim6 March 2007
compatibility and reduced latency.
The other option to support communications with legacy hosts is to
enable the P-Shim6 boxes to behave as a NATv6. In this case, the P-
Shim6 box would simply translate the CMULA to one of the globally
routable addresses. Of course this present some of the limitations
of NAT in IPv4, including that the address is not restored end to
end, and so if addresses are included as application layer
information, they will not match with the address actually contained
in the header. However, since it is possible to perform a stateless
one to many mapping between the CMULA and the global addresses, some
of the limitations of NATs in IPv4 are lifted. In particular, it
would be possible to receive externally initiated communications with
a node behind the NAT without need for NAT traversal mechanisms and
there is no need to use additional tools to keep the NAT state alive.
It is important to note that this is just a mechanism to support
legacy hosts and it is expected to be merely a transition tool. This
approach preserves all the features of the P-Shim6 approach,
including portability and TE enforcement.
8. Compatibility with host based shim6
The proposed approach is compatible with host based shim6. this means
that is possible for a shim6 host to establish a shim6 context with a
proxy shim6 box and use that context to provide multihoming benefits
for the communications established between the shim6 host and the
hosts served by the proxy shim6. However, for this, it is necesary
that the shim6 host has pupulated the DNS reverse tree corresponding
to the ULID that it is using for the shim6 context. This is so,
because the P-Shim6 approach relies on the DNS reverse tree in order
to obtain the locator information associated with the target ULID in
case that one of the P-shim6 boxes fail and the backup P-shim6 needs
to restore the shim6 contexts. In addition, the shim6 hosts should
support the new ULID RR in order to establish the shim6 context with
the unroutable ULIDs used by the hosts served by the P-shim6.
9. Alternative Design Choices
The presented approach provides a set of features and relies on a set
of components. However, it should be noted that it is possible to
provide a subset of the features using a subset of the components and
that some of the components can be sustituted by alternative ones.
In this section we describe which components are needed for which
features and we also describe which other options could be used to
replace some of the selected componenets.
Bagnulo Expires September 5, 2007 [Page 17]
Internet-Draft P-Shim6 March 2007
We will start by identifying which components are required for which
feature.
Centrally Managed Unique Local Addresses
Centrally Managed Unique Local Addresses are used to provide provider
independence i.e. avoid provider lock-in. Using CMULAs allows the
multihomed site to have provider independent identifiers and in the
presented approach, the hosts within the multihomed site are only
configured with CMULAs, greatly reducing the cost of a renumbering
event. PA addresses are only configured in the P-Shim6 boxes, so in
case of a change in one of the ISPs, only the P-Shim6 boxes need to
be reconfigured. It should be noted that it is perfectly possible to
use the P-Shim6 approach presented in this document with regular PA
addresses as identifiers. In this case, the hosts would be
configured with PA addresses and the cost of a renumbering event
would increase increasing also the provider lock-in. In addition it
should be noted that alternative provider independent identifiers
could be used, such a regular PI address space.
DNS Reverse tree
The DNS reverse tree is used in this approach to restore ULID to
locator mapping information in backup P-Shim6 boxes for ongoing
communications in case that the primary shim6 fails. In case that a
single P-Shim6 box is used in a site, there is no need to populate
the reverse DNS tree. In case that alternative fault tolerance
measures are in place (like mirrored P-Shim boxes) there reverse DNS
population is not required. In addition, alternative mechanisms to
distribute ULID to locator mapping information among P-Shim6 boxes
can be used instead of the reverse DNS (more in this below)
ULID RR
ULID RR is used to store information about addresses that are not
globally routable and that are only meant to be used as ULID for
shim6 context and not as locators. Again, this is only needed to
support non routable ULIDs, which are required to provide provider
independence. In the case that routable addresses (PA addresses for
isntance) are used as ULIDs, this new ULID RR would be no longer
needed.
DNS Aplication level Gateway
DNS Application Gateway is used to translate information ontained in
the newly defined ULID RR and presented to legacy hosts in a AAAA
record. This is needed to support unmodified legacy hosts and
provider independence through PI identifiers. In the case that no
Bagnulo Expires September 5, 2007 [Page 18]
Internet-Draft P-Shim6 March 2007
provider independence is needed, and routable addresses are used as
ULIDs, the DNS ALG would be no longer needed. Similarly, if it can
be asumed that the hosts in the multihomed site can understand the
new ULID RR the DNS ALG would be no longer needed.
Dual faced DNS
The current proposal asumes that the DNS server in the multihomed
site will return ULIDs in AAAA RR to internal queries and ULIDs in
ULID RRs to external queries. Again this is needed when non routable
provider independent ULIDs are used. If routable addresses are used
as ULIDs (and no provider independence is required, there would be no
need to dual faced DNS.
Direct DNS population
Direct DNS is used in the same way that it is currently used in non
shim6 setups. It is used in order to allow eternal hosts to initiate
communications with a FQDN. So DNS population is only required for
hosts behaving as servers (i.e. they receive externally initiated
communications). Clients do no need DNS entries.
NATv6
NATv6 is required as a mechanism to comunicate with legacy hosts
outside the multihomed site in the case that non routable ULIDs are
being used i.e. in case provider independence is required. If
provider independence is not required, then is is posible to use the
alternative choice described in the document, which relies in
configurating multiple PA addresses per host, increasing provider
lock in.
Firewall component
Having a firewall component in the P-Shim6 boxes is also required to
provide provider independence. This is so, because in order to
facilitate renumbering we require that firewall rules will be
configured using PI ULIDs rather than PA addresses. If provider
independence is no required and routable addresses can be used as
ULIDs, the regular firewalls can be used unmodified.
CGAs and HBAs
ULIDs must be either CGAs or part of an HBA set. In casethat
provider independence is required, CGA are the only option, since a
modification in one of the acialble prefixes in the site would result
in a change in the ULIDs. So, again, the usage of only CGAs is
required by the provider independence requirement.
Bagnulo Expires September 5, 2007 [Page 19]
Internet-Draft P-Shim6 March 2007
Summarizing
Tools imposed by the Provider Independence requirement
CMULAs or similar
DNS ALG
New ULID RR
NATv6
Firewall component
CGAs and not HBAs
It would be perfectly possible to use the proposed approach wihtout
the aforementioned components if provider independence is not
required
Alternative design choices
In this document, we have made a certain choices in order to present
the details of how a proxy based solution would be.In particular, we
decided to use as much available tools as possible, in order to allow
the reader to grasp in more detail the issues involved. However, it
would perfectly possible to use alternative tools and even create new
tools for providing the required features. In particular, the usage
of the DNS reverse tree to retrieve alternative locator information
could be replaced by alternative mechanism as we discuss below.
The DNS reverse tree is used to retireve locator information
associated with an unroutable ULID. In concrete, it is used in the
following situation: A shim6 context has been established between a
P-shim and a remote shim6 peer (either P-shim6 or a shim6 host). The
P-shim6 that has the shim6 context information fails and the backup
shim6 is used to continue with the communication. In order to do
that, the context information must be restored. In this case, the
backup P-shim6 needs to retrieve the locator information associated
to the ULID of the remote peer. It does so, by performing a DNS
reverse lookup for the CMULA used a ULID.
However, it should be noted that the locator information was already
available in the site, in particular, it was available in the primary
P-shim6. So it would be perfectly possible to create an inter-P-
shim6 protocol to exchange locator-ULID binding information between
the primary and the backup P-shim6 as soon as the the context is
created. This would distribute the locator to ULID binding
Bagnulo Expires September 5, 2007 [Page 20]
Internet-Draft P-Shim6 March 2007
information and there would be no need to retrieve it from the DNS
reverse tree (and there would be no need to require the population of
the reverse DNS tree if such inter-P-shim6 protocol was available.
It must be noted that the reverse tree is never used to retrieve ULID
locator binding information for initial contact, but is only used to
restore information that was once available locally. this is why, it
is perfectly possible to design local mechanisms to substitute the
usage of the reverse DNS in the P-shim6 approach.
10. Other security mechanisms
So far, we have used the security mechanisms currently defined in the
shim6 protocols for P-shim. However, the shim6 protocol can be
extended to support other security mechanisms to protect the binding
between the ULID and the locator set. One possibility would be to
use the DNS. This basically means that the DNS would serve as a
trusted third party that would provide authoritative information
about the binding between a CMULA and its locators. In terms of the
protocol, this means that when the P-Shim6 resolves the FQDN, it will
obtain a ULID RR and several AAAA records. Since this information
comes from the DNS, it is assumed to be trustworthy and can be safely
stored in the shim6 context for that communication. However, the
same procedure needs to be used on the peer side. This basically
means that after performing the 4-way handshake to establish the
shim6 context, the P- Shim6 needs to verify that the presented
locator set is bound to the ULID of the peer. In order to do that,
it will need to perform a reverse DNS lookup and only the locators
contained in the returned AAAA records will be validated for that
context. This approach has a different set of tradeoffs than the one
presented before. In particular, it doesn't require the usage of
CGA/HBA, so there is no need for the DHCP component of the solution.
However, it does require both peers to perform a DNS lookup for
verifying the binding between the ULID and the locator set. In the
case of the initiator, it can be argued that the DNS lookup is needed
in any case, so no additional cost is imposed by this approach.
However, from the receiver point of view, the additional DNS lookup
imposes additional latency before accepting the establishment of the
shim6 context. In any case, both CGA/HBA and DNS security can be
used with the P-Shim6 approach. In addition, such approach presents
additional security issues that arise when two different sites claim
ownership in their DNS of the same ULID. A possible solution for
this is to verify the reverse DNS tree to check who has the
delegation of the reverse tree, but such a solution imposes
additional DNS queries.
Bagnulo Expires September 5, 2007 [Page 21]
Internet-Draft P-Shim6 March 2007
11. Incompatibilities.
The presented approach is incompatible with stateless address
autoconfiguration as described in RFC2462 [1], since the addresses of
the hosts within the multihomed site need to be configured using
DHCP. It could be argued that it would be possible to support
stateless address autoconfiguration if DNS based security is used.
However, this is not so trivial, since it is necessary to configure
the AAAA records of the autoconfigured addresses in the DNS, in order
to enable DNS based security. For that, dynamic DNS configured by
the end nodes is needed, which would impose additional security
mechanisms to protect it.
12. Security Considerations.
The P-Shim6 approach benefits from all the security features of the
shim6 protocol as described in the Security Consideration Section of
[6], including cryptographic protection for the binding between the
ULIDs and the locator set and flooding protection using a probe
before sending packets towards a new locator. In addition, the 4-way
handshake used for establishing the shim6 context provides protection
to the P-Shim6 boxes against DoS attacks.
The main difference in terms of security with respect to the end to
end shim6 protocol is that a trust relationship is assumed between
the hosts within the multihomed site and the P-Shim6 boxes.
The P-Shim6 approach is compatible with IPSec, both end to end IPSec
used by the end nodes and IPSec tunnels used by any two devices along
the path.
13. Acknowledgements.
Most of the ideas presented in the document have been previously
discussed in the shim6 working group. In particular, this document
contains the result from several conversations with Erik Nordmark and
Alberto Garcia Martinez. Some form of shim6 proxy as well as the
usage of the shim6 protocol with ULAs has been proposed in [9]. The
idea of using the DNS as a security mechanism for a multihoming
protocol has been proposed in [13].
Thanks to Erik Nordmark, Brian Carpenter, Alberto Garcia Martinez Sam
Xia, Iljitsch van Beijnum and John Ronan for reviewing and providing
valuable feedback
Conversations with Pekka Nikander helped to understand which
Bagnulo Expires September 5, 2007 [Page 22]
Internet-Draft P-Shim6 March 2007
components are needed for which features.
Marcelo Bagnulo would like to acknowledge the European Commission
support in the co-funding of the IST-RiNG project, where his work is
being developed.
14. Change History
draft-bagnulo-pshim6-00: Extended Alternative design choices to
describe which component corresponds to which feature supported
15. References
15.1. Normative References
[1] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
[3] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003.
[4] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[5] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[6] Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim
protocol", draft-ietf-shim6-proto-06 (work in progress),
October 2006.
[7] Bagnulo, M., "Hash Based Addresses (HBA)",
draft-ietf-shim6-hba-02 (work in progress), October 2006.
[8] Arkko, J. and I. van Beijnum, "Failure Detection and Locator
Pair Exploration Protocol for IPv6 Multihoming",
draft-ietf-shim6-failure-detection-06 (work in progress),
September 2006.
Bagnulo Expires September 5, 2007 [Page 23]
Internet-Draft P-Shim6 March 2007
15.2. Informative References
[9] Nordmark, E., "Extended Shim6 Design for ID/loc split and
Traffic Engineering", draft-nordmark-shim6-esd-00 (work in
progress), February 2006.
[10] Baker, F. and M. Azinger, "Multihomed IPv6 prefix delegation,
aggregation, and distribution",
draft-baker-v6ops-l3-multihoming-analysis-00 (work in
progress), October 2006.
[11] Huston, G., "Architectural Commentary on Site Multi-homing
using a Level 3 Shim", draft-ietf-shim6-arch-00 (work in
progress), July 2005.
[12] Hinden, R. and B. Haberman, "Centrally Assigned Unique Local
IPv6 Unicast Addresses", draft-ietf-ipv6-ula-central-01 (work
in progress), February 2005.
[13] Nordmark, E., "Multihoming without IP Identifiers",
draft-nordmark-multi6-noid-02 (work in progress), July 2004.
[14] Kempf, J., Wood, J., Ramzan, Z., and C. Gentry, "IP Address
Authorization for Secure Address Proxying using Multi-key CGAs
and Ring Signatures", IWSEC06, August 2006.
Author's Address
Marcelo Bagnulo
Huawei Lab at UC3M
Av. Universidad 30
Leganes, Madrid 28911
SPAIN
Phone: 34 91 6249500
Email: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es
Bagnulo Expires September 5, 2007 [Page 24]
Internet-Draft P-Shim6 March 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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, THE IETF TRUST 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 provided by the IETF
Administrative Support Activity (IASA).
Bagnulo Expires September 5, 2007 [Page 25]