Short version: Why I think CEE (Locator / Identifier Separation)
is inferior in general to CES - and in particular
why CEE cannot provide mobility in an acceptable
manner, while CES with TTR Mobility can.
CES continues the current pattern of the routing
system providing significant services to the hosts.
CEE requires the routing system to do less work,
and hosts to do more, including sending and
receiving more packets, holding more state,
running more complex software - and suffering
more delays and sensitivity to packet loss.
This is unacceptable in general, and is
particularly unacceptable for battery powered
hosts hanging on via slow and potentially
unreliable 3G etc. radio links.
Hi Toni,
You wrote:
> ILNP: The Routing RG has had remarkably little consensus on
> anything, so virtually all Routing RG outputs are considered
> controversial.
>
> I was surprised to know that Robin is against location/identity
> separation. Are you not, Robin?
Yes, I am opposed to altering the current host protocols in which the
IP address performs the role of both Identifier and Locator.
(Actually, its not the host which these apply to, but a particular
interface of the host. Each interface can have one or more IP
addresses, but an IP address can't be on more than one interface.)
With the current arrangement, the routing system (that is, everything
outside the host) takes responsibility for getting the packet to the
host interface which has the IP address matching that in the packet's
destination field - otherwise, the packet will be dropped. This means
the routing system ensures that a packet addressed to a host with IP
address XYZ will not be delivered to any host which does not have the
address XYZ. (Normally there is only one host with the IP address
XYZ, but with anycast there are multiple hosts with the same IP address.)
In this way, the routing system provides an extremely valuable service
to the host. This means a host BBB can respond to a packet which is
supposedly from host AAA (that is, the packet has AAA's IP address in
the source field) by sending a reply packet addressed to AAA's IP address.
It is possible that the initial packet was actually sent by malicious
host MMM, so there can be confusion and disruption. However, TCP and
application problems have little or no problem coping with this sort
of attack.
In the usual case, the initial packet did come from AAA. BBB
tentatively assumes this is the case, generates a reply and generates
a reply packet with the IP address AAA in the destination field. This
way, it can send information to AAA knowing that the routing system
will not allow it to be delivered to any host other than one with
AAA's IP address - which means AAA itself, or in anycast, one of the
hosts which has the AAA IP address.
With this arrangement, BBB's stack and applications can take the
initial packet on face value, for the purposes of initiating a
communication session, without needing to do any DNS or other lookups.
If there is to be a session, and BBB receives a valid response to its
reply, then it can continue the session without any further checks -
because it can reliably assume the session is with the host whose IP
address is AAA.
Locator / Identifier Separation is a conceptually attractive
arrangement in which hosts have one or more IP addresses (or some
other form of network address which acts as the Locator), but the host
stacks and applications do not consider these to be important, fixed
or to indicate anything persistently about the identity of themselves
or other hosts.
It would be possible to run a global network, including an Internet,
or modified versions of the IPv4 and IPv6 Internets, using Locator /
Identity Separation.
HIP, ILNP, Name Based Sockets, GLI Split and RANGI are some of the
architectures which do this. These are all "Core Edge Elimination"
(CEE) architectures - so I regard "CEE" as meaning the same thing as
"Locator / Identifier Separation".
LISP, despite its name, does not implement Locator / Identifier
Separation. It is a Core Edge Separation (CES) architecture - like
Ivip, TIDR and IRON. See:
LISP does not implement Locator / Identity Separation
http://www.ietf.org/mail-archive/web/rrg/current/msg06190.html
(2010-03-08)
CES involves no alterations to host functionality. The routing system
still behaves the same way to each host, so it continues to support
the current "overloading" of both Identifier and Locator functions on
the IP address.
A CES architecture involves adding to the routing system some new
things, such as ITRs, ETRs and various things to support them, in
order that the routing system can scalably provide portability,
multihoming, inbound traffic engineering (TE) and ideally mobility.
Hosts continue to benefit from the Locator and Identifier
"overloading" of IP addresses.
An attempt at a concise description of the distinctions between CES
and CEE architectures is in section 17.3.3 of my proposed
Recommendation text: msg06219. A more detailed version is: msg06250
and msg05865.
As I wrote here:
"Overloading" of Loc & ID functions is good for hosts and should be
maintained
http://www.ietf.org/mail-archive/web/rrg/current/msg07017.html
(2010-06-22.)
adoption of Locator / Identity Separation (CEE) would mean that BBB in
our previous example would typically need to do a mapping lookup
before it could reply to a packet from AAA. Also, CEE architectures
often involve longer packets (at least for the first few packets of an
exchange) and/or more packet to and from the hosts in order to make
the system work.
If BBB was a DNS server it wouldn't care about the identity of the
host it is sending a reply to. So in this instance, CEE would be no
slower or more burdensome for BBB than the current "overloaded"
arrangements (or with a CES architecture). In this instance, BBB
would simply send its reply to whatever IP address (or whatever it is
in the initial packet which specifies the Locator of the host which
ostensibly sent this packet) of the requesting host. There would be
no need for any mapping lookups - and so no problem with delays etc.
However, in many or most communications, including setting up a TCP
session and many application protocol sessions, BBB sends a reply
packet on the basis that the reply will only go to the host whose
Identifier is in the source field of the initial packet.
With Loc / ID Separation, the only way BBB can do this is by
performing a lookup on that Identifier, to obtain a list of that
host's one or more current Locators. Only then can BBB choose a
Locator with which to send the reply packet.
This means BBB can't send a reply packet until it has queried and
received a response from a secure global mapping system (perhaps an
extension of the current DNS system) to obtain the one or more
currently valid Locators for the host which ostensibly sent the
initial packet. This might only take a few tens of milliseconds.
However, if the request and response needs to traverse continents and
oceans, and especially if the request needs to be redirected towards
the one or more authoritative mapping servers for this particular
Identifier, then it will often take a second or two. This represents
a significant extra burden on BBB, and a significant delay in
completing this initial (and perhaps only) phase of the communication.
Let's say a malicious host has the Identifier MMM and Locator mmm. (It
could have multiple Locators, but one is enough for this example.
Hosts can also have multiple Identifiers, I think.)
The malicious host launches an attack on two hosts:
1 - Host with Identifier AAA and Locator aaa.
2 - Host with Identifier BBB and Locator bbb.
It sends a packet to BBB:
Source ID: AAA Source Loc: mmm
Dest ID: BBB Dest Loc: bbb
If BBB doesn't implement the mapping lookup I just described, then it
has to assume that this packet really is from the host with Identifier
AAA, and that one of its current Locators is mmm.
So, without BBB performing the mapping lookup, it will reply, with the
reply packet being:
Source ID: BBB Source Loc: bbb
Dest ID: AAA Dest Loc: mmm
The malicious host has now obtained an answer from BBB with BBB
behaving as if it was replying to a request from AAA. Furthermore,
the malicious host can now continue a session and impersonate AAA.
This is intolerable for many or most application protocols. So either
before BBB replies at all, or at least before any meaningful
communication can occur, BBB must perform a mapping lookup to securely
determine whether this Locator mmm is really a valid Locator for the
host AAA.
Therefore, Loc / ID Separation requires all or almost all hosts (with
possible exceptions such as DNS servers) to do more work, send and
receive more packets, delay their initial or at least their meaningful
responses and to store more state, than in the current "overloaded"
arrangement.
There are other problems with the idea of changing the current
Internets to operate with Loc/ID Separation. For instance, the
scaling benefits and the benefits to each adopter of the new system
only really exist once all, or almost all, hosts and networks adopt
the new scheme. So it would be difficult or impossible to introduce
this successfully:
http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/
But even if we could choose to redesign the Net without concern about
adoption, backwards compatibility etc. I would still argue against
Loc/ID Separation.
Conceptually, it is nice and clean - with the routing system simply
working with Locators, and the hosts themselves fussing over the
concept of their own Identity. This would make the routing system
simpler. In particular, it would do away with the problems of
scalability we currently have, by making it possible for all hosts to
use purely PA addresses from their one or more ISPs. Assuming there
was a Loc/ID (CEE) architecture which could reliably and efficiently
perform multihoming, TE and mobility, then this would be a good
outcome in some ways: the routing system could remain as it is, since
the interdomain routing system would only needs to handle as many
prefixes as are needed by the world's ISPs. I think we all agree
that the BGP system can cope with this. I think we all agree that the
BGP system can't cope with there being millions of separately
advertised prefixes, which is what would be required to use the
current BGP-based techniques for portability and multihoming, for the
millions of non-mobile end-user networks which want or need these.
Also, there's no way of making the BGP system adapt fast enough to
provide mobility - and we need global mobility for billions of
hand-held devices.
The current, architecturally "impure", "overloaded" arrangements means
the routing system provides a significant service to hosts: delivering
packets in a manner that the packet will never be sent to a host with
an IP address other than the one in the destination field.
I think this should be retained.
I think the BGP system is a good and arguably excellent system for the
interdomain routing system, as long as it is not expected to cope with
as many prefixes as there are non-mobile end-user networks which want
or need portability, multihoming and TE. I support CES architectural
enhancements to the routing system, so hosts can continue to do what
they do today, and so the BGP system can continue as it does today -
ideally with fewer or no prefixes of end-user networks.
LISP and Ivip on their own don't provide mobility. The TTR Mobility
approach could be applied to either of them, and would provide global
mobility, from any access network (including behind multiple layers of
NAT and on TTR Mobile addresses) - with generally optimal path
lengths. This is for both IPv4 and IPv6 without any alterations to
host stack or application protocols (other than adding a tunneling
system to mobile hosts so they can make two-way tunnels to typically
nearby TTRs).
I haven't read the latest IRON drafts, but I understand IRON now
implements something similar to, or at least inspired by, TTR
Mobility. TIDR is the other CES architecture too, but unfortunately
doesn't provide scaling benefits.
I think this CES architectural enhancement - making some new parts of
the routing system do extra work, while retaining the existing level
of service with the "overloaded" functions of IP addresses - is the
right division of labor.
CEE (Loc/ID Separation) proponents want all hosts to do a lot more
work, including delaying initial communications while they look up
mapping, all for the benefits of enabling the interdomain routing
system to continue as it is today, without any additions to the
routing system at all - though a highly reliable and substantial
mapping system needs to be added.
I think CEE is attractive in a general sense, since it continues the
Internet's well regarded tradition of keeping the network simple and
expecting the end-user devices (hosts) to implement the rest of the
entire system's required functionality. This is in stark contrast to
the POTS telephone system, where the handsets are very simple and the
network has to be formidably complex. (Cell-phones are complex, but
only for the purposes of talking to base-stations - still, the network
provides all the functionality of handling calls, voice mail etc.)
There is understandable reluctance to introducing any new
functionality or complexity into the network - into the routing
system. Generally, hosts are inexpensive and have lots of CPU power -
so it is tempting to get them to do more work so we can retain a
simple routing system.
The average PC has heaps of CPU power and memory to implement the
additional functionality required by CEE. However this is not so
clearly the case with battery operated hand-held devices, such as
cell-phones - and we should plan for every human having such a device,
with each one having global mobility via the Internet, presumably most
of them on an Internet other than IPv4.
Even if it could be argued that the CPU and RAM burden was not a
problem for cell-phones or any other hosts in the future (including
IPv6 light switches, and various other miniature wireless battery
operated devices which are imagined for the future . . . Hmmm, its
dark - does the light-switch needs a software update, a reboot or a
virus scan?), there is still at least four fundamental objections to
CEE Loc/ID Separation compared to implementing CES instead, and so
preserving the current "overloaded" arrangements of:
IP address = Identifier = Locator
These are the four major objections - not counting CPU, RAM, software
complexity etc. required on all hosts.
1 - CEE involves extra packets being sent and received by all
hosts. This is for the mapping lookups hosts typically need
to do when replying to an incoming packet. The initiating
host starts with an Identifier, and has to do a mapping lookup
to find the current Locator(s) of the destination host, but
the current arrangements often involve an equivalent lookup:
looking up an FQDN to get one or more IP addresses. So the
initiator doesn't always have do do more work than today - but
the responder typically does.
With the current arrangements, many initiating hosts can start
with an IP address, from a referral, a config file or even
hard-wired into the application program and don't need to do
any DNS lookup before sending the initial packet to the
respondent host. This is not possible with CEE, because a
host's Locator(s) could change at any time - requiring a
mapping lookup before every new communication.
2 - CEE typically involves extra and/or longer packets being
exchanged between the hosts, at least at the start of a session.
This is for purposes such as enabling each host to get a nonce
from the other. The nonce sent by AAA to BBB will be used by
BBB whenever it gets a new Locator ggg. Then BBB will send AAA
a packet from Locator ggg, with the nonce, and a message to the
effect: "This is really the BBB host, but with this new Locator.
Please sent further packets to ggg, rather than the Locator
BBB was previously known to be using."
3 - CEE involves extra delays in establishing most communication
sessions, as noted above, due to the need for the replying host
to do a mapping lookup before sending a reply, or at least
before sending a reply which should only be sent to the host
whose Identity was in the initial packet.
4 - So far, no-one has developed a way that CEE can provide Mobility
in an adequate way. The basic CEE mechanism means every host
can operate from any Locator, at any time, so in principle it
looks like Mobility is already part of the system.
If we assume AAA is not mobile and that its Locator(s) are
stable, then it is OK for BBB to be mobile. BBB can send
a packet to AAA, with the nonce it sent during the initial
session set-up, to tell AAA it has a new Locator. However,
this has several major problems:
A - BBB has to do this for all its correspondent hosts
every time it gains a new Locator. In practice, CEE
adaptations of IPv6 involve the Locator being much
the same as, or exactly, an IPv6 address. BBB will
get a new Locator every time it switches from one
access network to another, such as from 3G to WiFi,
or from either of these to a cabled Ethernet
connection.
Furthermore, even on 3G, even without moving, BBB
could get a new Locator, since the vagaries of the
wireless network could mean it is now served by
a different base-station, which uses a different
IP gateway.
Locator changes could happen every second or two.
With CEE, every change of Locator would mean BBB
needs to send nonce-equipped Locator Update messages
to all its correspondent hosts. This will burden
all those hosts with extra packets, extra work etc.
These updates need to be acknowledged, so BBB can
resend if the first one is lost - so each such
update involves at least two packets.
The physical transmission of these packets over
BBB's radio links, every time there is a new radio
link, or change in access network, such as by
driving into a tunnel or going into a train (losing
the 3G and gaining a WiFi link) is an intolerable
burden. Even if the list of "currently active
correspondent hosts" was pruned with a 1 minute
time-out, this would be prohibitively onerous for
mobile hand-held devices. (To do so would require
all hosts, or at least all hosts which somehow
ascertain they are communicating with a mobile host,
to perform a fresh mapping lookup every minute for
each such mobile host. This is highly inefficient,
and would involve further unacceptable burdens on
any hand-held mobile host which was doing this
because it was communicating with other mobile
hosts.)
B - Along with each such Locator Update message, the
mobile host needs to update its Locator information
in the global mapping system. That needs to be
done rapidly and securely, so there will be at
least one packet to the system and one ACK in
return - assuming a nonce or some other crypto
arrangement to secure this. The mapping system
may then have more work to do.
If the mapping system involves a single
authoritative server, for a given host's ID->Loc
mapping, then there's no need to propagate the
changed Locator information. However, such an
arrangement would not be robust, and would involve
the most onerous approach to mapping lookup:
no caching and all requests being forwarded via
several levels of servers to this single mapping
server.
If the mapping system involves multiple authoritative
mapping servers for a given host, then every time the
mobile host changes its mapping, these servers need to
exchange packets and do work so they are all updated.
Such a system would be more robust and potentially
faster than relying on a single authoritative mapping
server - but it involves higher overheads for every
change of Locator.
C - This nonce-equipped "Locator Update" message
approach will not work if both hosts change their
Locators at the same time. Since many communications
will be between mobile hosts, this is an unacceptable
arrangement. The attempt to send the update message
would go from BBB to AAA's previous, but no longer
valid, Locator, while a similar message from AAA would
go to BBB's previous Locator.
Perhaps each host could detect this failure via
ICMP destination unreachable messages. However,
these would have to be accepted only on a highly
secure basis. Otherwise the failure would need
to be inferred by each host at a TCP or application
level - but not all applications could do this
promptly or at all.
The only way the hosts have of retaining their
session(s) is to start again with a mapping
lookup, to find the current one or more Locators.
AAA and BBB would both do this, which could take
half a second, a second or whatever - longer if
there is a single mapping server, which happens
to be on the other side of the Earth, especially
if a request or response packet is lost.
This sort of delay is unacceptable, since we
expect mobile hand-held devices to support VoIP
without disruption, as long as it has at least
one active method of connecting to the Net.
TTR (Translating Tunnel Router) Mobility:
http://www.firstpr.com.au/ip/ivip/#mobile
involves none of these problems. When the MN (Mobile Node)
gets a new IP address, it establishes a new two-way tunnel
to its current TTR (there may be more than one TTR, but
typically there will be just one). This TTR is typically,
but not necessarily, nearby - such as within 1000km. This
can typically be done in a few tens of milliseconds, since
the MN and TTR have already exchanged nonces or other crypto
tokens and the TTR can therefore authenticate a suitable
message from the MN, no matter what IP address the MN is now
on.
The MN using TTR-Mobility can still use tunnels to its TTR
from any other IP addresses it still has, so there need be
no break in communications due to getting a new IP address
in a new access network, while other IP addresses are still
active from other access networks.
With TTR Mobility, there can be any number of correspondent
hosts. They don't need to know anything about mobility.
There's no need for a mapping change when the MN gets a new
IP address since the current TTR remains the ETR for the MN's
EID prefix (LISP terminology) or micronet (Ivip). The only
time the mapping is changed is if a new TTR is used - and that
would be a good idea if the MN moves more than about 1000km
from the current TTR. It will still work OK if the MN is
on the other side of the Earth from the current TTR, but
the path lengths would be long, so it is best to use a
closer TTR. Changing TTRs involves no loss of connectivity,
even if there are minutes or perhaps an hour or so of delays
in getting mapping to all the ITRs which need it (as might be
the case with LISP). This is because the MN will retain its
tunnel(s) to the previous TTR and so will get any packets
sent to that TTR, due to the original state of the mapping.
CEE assumes that each host has a global unicast address
- which may be OK if IPv6 or whatever develops without NAT.
However, IPv4 is full of NATs, and most hosts other than
servers can only get connections behind at least one level
of NAT.
TTR Mobility works fine with the MN's "care-of address" on a
global unicast address or behind one or more layers of NAT -
with the NAT box's public address being either Ivip/LISP
mapped or ordinary (LISP: RLOC) address space.
It will also work fine if the MN's care-of address is itself
on an address provided by TTR Mobility. (This means nested
MN <==> TTR tunnels - it does not mean nested ITR --> ETR/TTR
tunnels.)
So even if we were designing the Net from scratch, I would argue
against Loc / Id Separation and in favour of the current "overloading"
of both Identifier and Locator functions on the IP address.
> Distinction between a node's identity and topological location is
> natural, because the same node can be attached to the general
> network at different points. So, to name the node independently of
> its point of attachment, we need an identifier assigned to the
> node. And we also need a locator to represent the node's
> topological position.
I agree it is architecturally more "elegant" to uniquely identify each
node, and then to allow the node to use all of its potentially
multiple interfaces, each with potentially multiple Locators, for
communicating with other nodes.
But so far, no-one has figured out how to create a CEE architecture
which works as well as CES would. So I think it is worth adding the
CES stuff to the routing system. This can be done without altering
hosts (mobile hosts need tunneling software to their chosen commercial
TTR service) and without altering the interdomain routing system.
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
