One document matched: draft-nikander-ram-pash-00.txt
Network Working Group P. Nikander
Internet-Draft K. Slavov
Intended status: Informational Ericsson Research Nomadic Lab
Expires: August 30, 2007 February 26, 2007
Proxying Approach to SHIM6 and HIP (PASH)
draft-nikander-ram-pash-00
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 August 30, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document describes an incremental, network-based method for
deploying SHIM6 or HIP based identifier / locator separation, called
Proxying Approach to SHIM6 and HIP (PASH). This mechanism requires
no changes to host stacks and, when deployed with routable Endpoint
IDentifiers (EID), no changes to existing database infrastructures.
The proposed protocol can be implemented in a relatively small number
of routers, and deployed independently by ISPs. At the same time, it
allows the network to gradually evolve towards full, host-based SHIM6
Nikander & Slavov Expires August 30, 2007 [Page 1]
Internet-Draft PASH February 2007
and/or HIP support, thereby making possible the larger architectural
benefits that the network-based "jack-up" approaches provide.
This proposal has been on the mental roadmaps within the HIP
community for a number of years, but is properly documented only now
as a result of the problem statement effort at the Amsterdam IAB
Routing and Addressing Workshop (RAWS).
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Basic idea . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Transition roadmap . . . . . . . . . . . . . . . . . . . . . 5
4. Packet flow sequences . . . . . . . . . . . . . . . . . . . 6
4.1. SHIM6-based proxied packet flow . . . . . . . . . . . . . . 6
4.2. HIP-based proxied packet flow . . . . . . . . . . . . . . . 7
5. Packet formats . . . . . . . . . . . . . . . . . . . . . . . 9
6. Handling legacy sites . . . . . . . . . . . . . . . . . . . 9
6.1. Legacy sites with PASH 1 . . . . . . . . . . . . . . . . . . 9
6.2. Legacy sites with PASH 1.5 . . . . . . . . . . . . . . . . . 9
6.3. Legacy sites with PASH 2 and 3 . . . . . . . . . . . . . . . 10
7. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. Security considerations . . . . . . . . . . . . . . . . . . 10
10. IANA considerations . . . . . . . . . . . . . . . . . . . . 10
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 11
12. Informative references . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . 13
Nikander & Slavov Expires August 30, 2007 [Page 2]
Internet-Draft PASH February 2007
1. Introduction
As outlined in [4], it is possible to implement almost any host-stack
based identifier / locator split mechanism in the network side by
deploying suitable proxies. Such an approach does not require any
changes to the hosts, and depending on the exact nature of the
identifiers used, may be deployed at different points in the network,
including Tier 1 ISPs.
In this document, our attempt is to illustrate how host-based
mechanisms, such as SHIM6 and HIP, can be implemented in the network
side, bringing forth deployment benefits similar to the proposed
Locator/ID Separation Protocol (LISP) [5]. Consequently, we do not
repeat the argumentation therein but, when discussing the properties
of the present proposal, merely point to the similarities and
differences between the present proposal and the LISP one. In
particular, in this document we aim towards the same design goals as
LISP, as outlined in Section 2 thereof.
At the same time, we strongly emphasis that, in our opinion, host-
based identifier / locator separation approaches potentially provide
benefits far beyond what network-based ones can provide. From that
point of view, we are tempted to claim that the LISP proposal, at
least in its current state, does not actually implement the
identifier / locator separation in the sense the term has
traditionally been used [9]. However, that discussion we defer to a
separate document [8].
In addition to the design goals, we also adopt the topological
dependencies from LISP, i.e., the notion of deployment genres: PASH
1, PASH 1.5, PASH 2, and PASH 3.
2. Basic idea
The basic idea of this proposal is support network structures where
some hosts have been upgraded to support SHIM6 or HIP while others
work the same way as today. As in LISP, the routers continue to work
as today. To support legacy hosts, we introduce SHIM6 or HIP proxies
to the network. Depending on the deployment genre, the proxies may
either be located relatively freely within the network, including
individual ISPs (PASH 1 or 1.5), or need to be deployed at each edge
or site accomodating legacy hosts (PASH 2 or 3).
With these arrangements, we archieve the following properties:
o SHIM6 ULIDs or HIP HITs are the only globally routable "IP
addresses" assigned to legacy hosts.
Nikander & Slavov Expires August 30, 2007 [Page 3]
Internet-Draft PASH February 2007
o In theory, routers need no information about SHIM6 ULIDs or HIP
HITs. However, since in PASH 1 and 1.5 the identifier and locator
spaces overlap, under those deployment genres the routers do know
about the ULIDs or HITs. However, they do not necessarily place
any new burden to the routing or forwarding tables, depending on
the ULID or HIT name space design.
o ULIDs or HITs can be used for end-to-end communication within
individual all-legacy networks. Note that in PASH 1 the whole
Internet can initially be considered as one huge legacy network.
However, end-to-end communication between separated legacy
network, or between legacy networks and completely upgraded hosts
(that are no longer able to communicate in the legacy manner),
requires proxies. Structurally, this is similar to the LISP use
of Tunneling Routers.
o For PASH 1 and 1.5, it is preferable to have organizationally
structured end-point identifiers. For SHIM6 ULIDs, this might
require allocation of a new fraction of the IPv6 address space.
For HIP, this would require changes to the ORCHID format [3],
perhaps along the way J. Rajahalme argued during the ORCHID
draft's IETF last call.
o Depending on the usage scenarios, the actual data packets either
need no extra headers or carry the SHIM6 context tag header, or a
header similar to it.
o The network is free to rewrite the source and destination
addresses of packets, as long as the packet will eventually reach
its final destination.
As proxies handle only packets that either contain EID in their
destination address field, carry a control message (SHIM6 extension
or HIP control message), or are identified as proxied traffic by the
means of a context tag or ESP SPI, having multiple proxies on the
packet path is not a problem. This also means that proxies may act
in a way transparent to the upgraded hosts.
Nikander & Slavov Expires August 30, 2007 [Page 4]
Internet-Draft PASH February 2007
An illustration of an example network
2001:001a:5131::2/28 HIP
| |
-------- | ---------- v
| Host A |+---[2001:10::/28]---+| Proxy PA |+========[Internet...
-------- ---------- |
|
2001:0014:aaaa::1/28
2001:0020::8/28
|
| ---------- --------
...Internet]=======+| Proxy PB |+---[2001:20::/28]---+| Host B |
---------- | --------
|
2001:002f::9/28
The figure depicts a PASH 1 like situation where both hosts A and B
are legacy (i.e. not SHIM6/HIP aware). Both proxies PA and PB store
the host identities of A and B, enabling them to perform the SHIM6
handshake or HIP base exchange on behalf of the legacy hosts.
3. Transition roadmap
In this section, we briefly outline how the described mechansism
could be deployed in an incremental fashion.
Similar to LISP 1, individual ISPs or ISP coalitions are able to
start using PASH 1 immediately, without their customers or peers
concent. In such a case, the only differences with LISP 1 are the
mechanisms used between the proxies (respectively LISP tunnel
routers) to establish the necessary identifier-to-locator mapping
state, reflecting the underlying differences between trust and
security models.
Moving forward, once large fractions of the Internet are using this
mechanism, it will pay off to connect such islands. That would bring
forth routing benefits, provided that the providers also move to the
PASH 1.5 deployment genre, reducing the need to continue supporting
legacy identifier-based routing.
Once the Internet core (all Tier 1 ISPs) have done the transition,
deployment can gradually move towards the PASH 2 and/or 3 genres,
where the identifiers are no longer routable through the core
Internet. This will provide an incentive for sites to upgrade the
Nikander & Slavov Expires August 30, 2007 [Page 5]
Internet-Draft PASH February 2007
hosts or implement the proxying themselves, instead of relying on
their ISPs doing it.
4. Packet flow sequences
In this section, we describe packet flow sequences for both SHIM6 and
HIP based fully proxied scenarios, using notation similar to Section
4.1. of [5].
4.1. SHIM6-based proxied packet flow
o Source host "host1.abc.com" is sending an initial packet to
destination host "host2.xyz.com", or to the EID of the destination
host, known a priori.
o Both sites are multi-homed and use SHIM6 proxies at the site-
borders. The proxies are directly deployed at the sites.
1. host1.abc.com wants to open a TCP connection or send an UDP
packet to host2.xyz.com, or the corresponding EID. If host1
doesn't have the EID yet, it performs a DNS lookup and received
the EID as a AAAA record. It builds an IP packet with src=EID1
and dst=EID2.
2. The packet arrives at the site-exit SHIM6 proxy, since all (non-
local) EIDs are locally routed to it. [If there are multiple
proxies, there can be multiple parallel local routes.]
3. The site-exit SHIM6 proxy attempts to determine the locator
corresponding to EID2. If it does not find such a locator in its
cache, the next step depends on the deployment genre:
A. In PASH 1, the packet is sent as such. In this scenario it
will reach the site-entry SHIM6 proxy of host2, but it the
case there is no such proxy, it could also reach host2
directly, as such.
B. In PASH 1.5, the packet is routed on a different routing
infrastructure (perhaps an overlay), but it may exit
untouched to a "legacy Internet" and reach host2 as such.
C. In PASH 2 or 3, the destination of the packet is resolved or
routed over an overlay, but the ability to support legacy
hosts without proxying is lost.
Here we consider only the cases where the packet reaches the
site-entry SHIM6 proxy. In the PASH 1 and 1.5 cases the SHIM6 I1
Nikander & Slavov Expires August 30, 2007 [Page 6]
Internet-Draft PASH February 2007
extension message MAY be added to the packet. Alternatively,
either of the SHIM6 proxies may decide to initiate the SHIM6
protocol at any later stage. For PASH 2 and 3, it appears
necessary to initiate the SHIM6 exchange immediately.
4. When the packet reaches the site-entry SHIM6 proxy for host2, the
proxy checks the packet for any SHIM6 extensions. If the packet
carries the SHIM6 I1 extension, it initiates full SHIM6 exchange.
It can either piggyback it on further messages between host1 and
host2 (which may be hard to implement) or use plain IP packets
that carry only the SHIM6 extension and no upper layer payload.
5. Once the SHIM6 protocol has been completed, both proxies cache
the SHIM6 state that allows them to rewrite the IP address fields
in the packets; when they do so, they also add/remove the SHIM6
context tag extension.
4.2. HIP-based proxied packet flow
Since both HIP and SHIM6 protocols share the same ideology for the
most parts, the HIP-based proxied packet flow does not provide
notable changes compared to the SHIM6 packet flow. For lazy readers
the major changes are:
o Under current HIP design, the proxies have to establish the
rewriting state immediately, even under PASH 1 and 1.5. Delayed
setup a ala SHIM6 is not possible.
o Under PASH 1 and 1.5, HIP will need routable HITs.
o Temporary host identities of legacy peers would be stored in the
proxies, enabling them to run HIP base exchange on behalf of the
legacy host.
o Source host "host1.abc.com" is sending an initial packet to
destination host "host2.xyz.com", or to the HIT of the destination
host, known a priori.
o Both sites may be multi-homed and use HIP proxies at the site-
borders. The proxies are directly deployed at the sites.
1. In PASH 1 and 1.5, host1.abc.com wants to open a TCP connection
or send an UDP packet to host2.xyz.com, or to the corresponding
HIT. If host1 doesn't have the HIT yet, it performs a DNS lookup
and receives the HIT as an AAAA record, passing the HIT to the
application. If there is a HIP RR, it is ignored by the legacy
host. It builds an IP packet with src=HIT1 and dst=HIT2. In
contrast to what HIP base specification defines, the HITs in PASH
Nikander & Slavov Expires August 30, 2007 [Page 7]
Internet-Draft PASH February 2007
1 and 1.5 would be routable. For example, they could be CGAs in
PASH 1.
2. In PASH 2 and 3 the resolver lookup would yield the destination
HIT in the HIP RR and a set of locators in AAAA or A RRs. There,
either the IP packet would be built with src=locator1
dst=locator2 resulting in legacy operation, or the proxy would
need to handle also the DNS queries.
3. The packet arrives at the site-exit HIP proxy, since all (non-
local) HITs are locally routed to it. [If there are multiple
proxies, there can be multiple parallel local routes.]
4. The site-exit HIP proxy attempts to determine the locator
corresponding to HIT2. If it does not find such a locator in its
cache, the next step depends on the deployment genre:
A. In PASH 1, the packet is sent as such. In parallel, the
proxy initiates HIP base exchange with the destination, using
HIT2 as the destination locator. In this scenario, both
packets will reach the site-entry HIP proxy of host2, but in
the case there is no such proxy, they could also reach host2
directly; in that case the HIP I1 packet would get ignored.
B. In PASH 1.5, the packet and HIP I1 are both routed on a
different routing infrastructure, but they may exit untouched
to a "legacy Internet" and reach host2 as such, just as
above.
C. In PASH 2 or 3, the destination of the packet needs to be
resolved or overlay routed. In these cases it may make sense
to delay or drop the initial packet and wait for the HIP base
exchange to complete before continuing.
Here we only consider the cases where the packet reaches the
site-entry HIP proxy. As stated, in the PASH 1 and 1.5 cases,
the HIP base exchange takes place in parallel. This may be
implemented either as a separate I1 message, as described above,
or the HIP I1 message may be added to the packet, e.g. as TCP
option as defined in [7]. For PASH 2 and 3, it appears necessary
to initiate the HIP exchange immediately.
5. When the packet reaches the site-entry HIP proxy for host2, the
proxy checks if the packet is or contains any HIP control
messages. If the packet carries the HIP I1 message, the HIP
proxy replies with the HIP R1, continuing the HIP base exchange.
It seems sensible to use plain IP packets that carry only the HIP
control messages and no upper layer payload.
Nikander & Slavov Expires August 30, 2007 [Page 8]
Internet-Draft PASH February 2007
6. Once the HIP base exchange is completed, both proxies cache the
HIP state that allows them to rewrite the IP address fields in
the packets.
7. For cases where the packet reaches the end host instead of any
site-entry HIP proxies, the data flow does not change notably.
For PASH 1 and 1.5:
A. If both hosts are HIP-enabled, accoring to the HIP
specification, the HIP base exchange will be executed before
any payload traffic will be sent. To detect this the hosts
may use the same techniques as described above.
B. If only one of the hosts is HIP-enabled, the data connection
will fallback to an ordinary IP connection. This case is
valid also if neither of the hosts understand HIP.
For PASH 2 and 3, legacy hosts cannot directly connect beyond
their local legacy network, and proxies are always required.
5. Packet formats
There is no need to make any changes to the SHIM6 or HIP packet
formats.
6. Handling legacy sites
Handling of legacy sites (with no or few upgraded hosts) depends on
the deployment genre.
6.1. Legacy sites with PASH 1
Under PASH 1, legacy sites can decide whether they want to do a site-
wide upgrade or not. A site upgrades by adding proxies at their
site-border routers. Once they have done that, they assign one of
their existing prefixes as SHIM6 ULIDs. For the HIP case, some more
design is needed. One option is to allow CGAs to be used with HIP;
in that case, existing prefixes can used, just like with SHIM6.
6.2. Legacy sites with PASH 1.5
Under PASH 1, legacy sites can decide whether they want to upgrade,
provided that they ISP provides a route for EIDs. More details are
to be written once we understand better how LISP 1.5 is meant to
work.
Nikander & Slavov Expires August 30, 2007 [Page 9]
Internet-Draft PASH February 2007
6.3. Legacy sites with PASH 2 and 3
Under PASH 2 and 3, the site entry/exit proxies will provide
temporary identifiers for the legacy hosts. The proxies will also
act as a termination point for the identifier-bound connections. The
actual payload will be forwarded to the legacy host using the
available legacy mechanisms.
7. Open issues
o Co-ordination between multiple site-border routers.
o TE co-ordination between sites and ISPs and between ISPs.
o Using routable identifiers (e.g. CGAs) with HIP.
8. Discussion
In this document, we have outlined how two host-based identity /
locator split mechansims, SHIM6 and HIP, can be implemented in
separate boxes in the network. The approach is meant to act as a
transition tool.
The main message of this document is to show that it is indeed
possible to adopt host-based mechanisms to be implemented at the
network side; a discussion which we started in [4]. Consequently, we
strongly feel that there is no need to rush adopting a network-based,
"jack up" solution to the current routing scalability problem.
Instead, we urge the community to keep the various options open,
remembering that host-based solutions not only bring forth a number
of advantages compared to network-based solutions but can, as a
transition mechanism, be implemented within the network in order to
provide support and most benefits even for legacy hosts.
9. Security considerations
At this stage, we haven't worked out the security details related to
proxying. However, we don't expect there to be any major problems
and expert to rely on existing SHIM6 and HIP security work.
10. IANA considerations
This document has no actions for IANA.
Nikander & Slavov Expires August 30, 2007 [Page 10]
Internet-Draft PASH February 2007
11. Acknowledgments
12. Informative references
[1] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP)
Architecture", RFC 4423, May 2006.
[2] Lear, E. and R. Droms, "What's In A Name:Thoughts from the
NSRG", draft-irtf-nsrg-report-10 (work in progress),
September 2003.
[3] Nikander, P., "An IPv6 Prefix for Overlay Routable Cryptographic
Hash Identifiers (ORCHID)", draft-laganier-ipv6-khi-05 (work in
progress), September 2006.
[4] Nikander, P., "Generic Proxying as a Deployment Tool (GEPROD)",
draft-nikander-ram-generix-proxying-00 (work in progress),
January 2007.
[5] Farinacci, D., "Locator/ID Separation Protocol (LISP)",
draft-farinacci-lisp-00 (work in progress), January 2007.
[6] Lindqvist, J., "Establishing Host Identity Protocol
Opportunistic Mode with TCP Option",
draft-lindqvist-hip-opportunistic-01 (work in progress),
March 2006.
[7] Lindqvist, J., "Piggybacking TCP to Host Identity Protocol",
draft-lindqvist-hip-tcp-piggybacking-00 (work in progress),
July 2006.
[8] Nikander, P., "Identifier / Locator Separation: Exploration of
the Design Space", draft-nikander-ram-ilse-00 (work in
progress), February 2007.
[9] Chiappa, J., "Endpoints and Endpoint Names: A Proposed
Enhancement to the Internet Architecture",
URL http://www.chiappa.net/~jnc/tech/endpoints.txt, 1999.
Nikander & Slavov Expires August 30, 2007 [Page 11]
Internet-Draft PASH February 2007
Authors' Addresses
Pekka Nikander
Ericsson Research Nomadic Lab
JORVAS FIN-02420
FINLAND
Phone: +358 9 299 1
Email: pekka.nikander@nomadiclab.com
Kristian Slavov
Ericsson Research Nomadic Lab
JORVAS FIN-02420
FINLAND
Phone: +358 9 299 1
Email: kristian.slavov@nomadiclab.com
Nikander & Slavov Expires August 30, 2007 [Page 12]
Internet-Draft PASH February 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).
Nikander & Slavov Expires August 30, 2007 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-24 08:20:32 |