[RRG] Consensus? Router-based Translation schemes can only work with duplicate address space

[Robin Whittle <rw@firstpr.com.au>]

Here is another thing I think we should agree on.  This only applies
to translation schemes where the translation is done by a router,
rather than be upgraded facilities in the hosts themselves (such as
SHIM6 or Six/One - not Six/One Router).  In other messages I argue
that trying to solve the routing scaling problem with host upgrades
is never going to work, not least due to the difficulty or
impossibility of upgrading all hosts and to the difficulty of
securely managing their behavior in the centralised manner that most
end-user networks would require.

Map-encap systems add extra data to each packet in order to
transport it across the DFZ without routing scaling problems, and so
that the receiving router (the ETR) can figure out how to handle the
packet.  This is done by the full packet being sent verbatim, and
the outer header existing purely to get the inner packet to the ETR.

A translation scheme does not make packets any longer, which might
avoid some nasty problems map-encap schemes face with Path MTU
Discovery, overly large packets getting dropped or fragmented in the
tunnel etc.

A translation scheme involves one router (R1 in what follows)
changing the destination address of the packet so that it can be
transported across the DFZ, without routing scaling problems, to a
second router (R2), near the real destination host.  R2 then has the
task of figuring out the proper destination address of this packet,
so it can forward it correctly.

For multihoming (portability as well?) one way of doing this for an
address space X is to have two or more address spaces Y and Z of the
same length as X, and have R2 receive all packets addressed to those
Y and Z spaces.  When the sending host (near R1) generates a packet
addressed to some destination host at (X + N), R1 rewrites the
address to (Y + N) or (Z + N).  Then R2 has no difficulty
reconstituting the original packet by altering its destination
address to (X + N).

This may be a practical approach in IPv6, since there is plenty of
address space.

However, in the context of the IPv4 address shortage, it is
completely impractical in IPv4.

For a router-based address translation scheme (such as Six/One
Router) to work without duplicate address ranges, there needs to be
a practical method of R2 reconstituting the packet it receives.

Without duplicate address spaces, R1 will send all packets to R2's
hosts by changing the destination address to that of R2.

There is no "N" in this, so R2 has no way of knowing from the packet
itself which host it needs to be forwarded to.

The following scenario exemplifies the problem which such a scheme
faces.

   Host A in R1's network sends a packet to host B and an
   identical packet to host C.  Both B and C are in R2's network.

   R1 rewrites the destination address of both packets to R2's
   address.  What would the scheme have to do in order to enable R2
   to know how to reconstitute the destination address?  All the
   options seem so onerous and troublesome that I argue that this is
   completely impractical.

   For instance, R1 could send a separate "info" packet for each of
   these traffic packets, telling R2 the B or C address, and somehow
   enabling R2 to unambiguously identify which incoming packet the
   information applies to.

   This raises problems of reliability and packet loss/delay.  It
   also raises some security problems, since an attacker could spoof
   the info packet, making it get to R2 before the real info packet
   from R1.  To prevent this, there would have to be some fancy
   authentication  arrangements - but how could this be done without
   PKI or without  multi-packet exchanges of nonces etc.?  Such
   arrangements would also delay initial packets in a new
   communication flow, and further contribute to  vulnerability of
   the system to packet loss.

   This approach and its required authentication arrangements also
   involves R2 storing a large amount of state and doing many
   complex operations.


This looks like a robust theoretical argument why a router-based
translation scheme can never be efficient or robust unless it uses
duplicate address space - which means such an approach cannot be
practical for IPv4.

  - Robin                http://www.firstpr.com.au/ip/ivip/



--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg