Re: [RRG] Separation vs. Elimination

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

Hi Dan and Colleagues,

Here is some feedback on your paper:

  Towards A New Internet Routing Architecture:
  Arguments for Separating Edges from Transit Core

  http://conferences.sigcomm.org/hotnets/2008/papers/18.pdf

I agree with your basic premise that a separation scheme is
preferable to an elimination scheme.  My main suggestion is that it
would have been better if you mentioned Ivip, which is a significant
example of a core-edge separation scheme.  Some of the
characteristics you ascribe to separation schemes do apply to
non-Ivip separation schemes, but not to Ivip.

Elimination schemes are a retreat from the current responsibilities
of the routing system - to give each host a stable IP address.  They
involve host changes, including to applications which do referrals -
and probably in the way applications find the one address of
multiple addresses which they should be using.  They involve each
host in some highly complex tasks which I think belong in the network.

Elimination schemes involve scaling problems with tens of thousands
of sending hosts trying each to do their own reachability testing to
some host or network they are all communicating with.  I think it is
better to centralise the control of multihoming service restoration
as Ivip does, rather than devolve it to sending hosts (SHIM6) or to
ITRs (non-Ivip core-edge separation schemes).

Elimination schemes are hard or impossible to introduce because they
involve host changes and only provide benefits when both hosts in a
communication are upgraded.  They do not provide portability.

However, only Ivip with OITRDs (Open ITRs in the DFZ) and LISP with
PTRs (Proxy Tunnel Routers) are clearly able to support packets sent
by non-upgraded hosts.  There is a business plan for OITRDs, but not
yet for LISP PTRs.

  http://psg.com/lists/rrg/2008/msg02021.html

APT can support packets from non-upgraded networks, but for IPv4, as
long as there are separate APT islands, and as long as the current
/24 filtering of BGP prefixes prevails, then there is no robust way
of supporting such packets sent to EID prefixes longer than /24.
This significantly limits the usefulness of the system, since many
networks would be happy to use one or a few IP addresses, rather
than 256.

TRRP has an approach to support of packets from non-upgraded
networks, but I recall that it involves various carrots and sticks.

Six/One Router doesn't work for IPv4 and doesn't support packets
from non-upgraded networks.  I think your paper states or implies
that separation schemes support packets (for multihoming and
portability) from non-upgraded networks whereas elimination schemes
don't.  I think this is not true of all separation schemes.


I think your use of "ER" and "DR" in place of "ITR" and "ETR"
doesn't achieve anything useful - and that if you use such new
terms, you should mention their equivalents in the terminology used
in LISP, APT, Ivip and TRRP.



Page 2 col 1 para 1

   Solutions in the elimination category require that edge
   networks take address assignments from their providers;
   as a result a multihomed edge network will use multiple
   PA addresses internally and must modify end hosts
   to support multihoming.

It seems that all elimination schemes involve host-changes.

None of them propose that the end-user network have some new router
functions to support elimination, with the hosts unaffected.  (NAT
is an example of this, but it doesn't provide hosts with public
addresses.)

Also, the elimination schemes do not provide portability, or the
possibility of IP address referrals AFAIK.  My recent message to
Iljitsch (Re: Elegance and the rejection of SHIM6 host-based
multihoming) discusses how SHIM6 would require host changes to do
referrals, since I think it would require using two or more IP
addresses.


Page 2 col 2 para 3

You mention LISP, APT, TRRP and Six/One Router, but not Ivip.

You describe Six/One Router as using "address rewriting".
"Translation" is another term for this - perhaps the preferred term.

You might also have referred to:

  http://www.firstpr.com.au/ip/ivip/comp/

which compares LISP, APT, TRRP and Ivip.


Page 2 col 2 last para - continuing to page 3

Your discussion of mapping systems for separation schemes applies
only to the non-Ivip schemes.  You assume that the mapping system
does not get information to the ITRs in "real-time" and that
therefore it contains two or more ETR addresses for every EID prefix
("micronet" for Ivip).  Because of this, and because you assume that
the preferences for multihoming service restoration would not change
often, you assume that there would only be a mapping change every
month or so.

Ivip works on completely different assumptions.  Mapping changes are
done in real-time, giving the end-user network direct control over
the world's ITRs.  This means the ITRs and ETRs are not involved in
reachability detection or in deciding how to restore service via
another ETR.  Each mapping update pays its way - the user pays for
mapping updates.


Your description:

   LISP-CONS and LISP-ALT build a DNS-like hierarchical overlay to
   retrieve mapping data when needed.

strikes me as wrong.  Neither has much resemblance to DNS.  ALT is a
completely separate network, with its own BGP instance, using a
different but parallel address space, for sending mapping queries,
which are typically actually traffic packets.  The responses
typically come back via the ordinary Internet, rather then the ALT
network.  LISP-CONS is no longer being developed, as far as I know.


Page 3 col 1 last para

Elimination schemes do away with the concept of a host having a
single IP address.  So the DNS needs to return multiple IP
addresses.  Also, the DNS entries for all hosts need to be changed
every time a new ISP is chosen.  Sending hosts need to try one
address and then the next, unless the DNS response has some new way
of stating priorities for which address to try first.

As just mentioned, elimination schemes do not provide portability or
straightforward IP address referrals.

This lack of a single stable IP address leads to complications in
other networks.  Suppose network A has an ACL for its VPN, and the
aim is to allow a particular host in, according to its IP address.
That is simple now, and would remain simple with a separation
scheme.  However, with elimination, the ACL would need to have
multiple IP addresses for this one host, and those addresses would
need to be changed whenever the remote host's network started using
another ISP.

Elimination approaches do not support mobility, but separation
approaches could, via the TTR approach, as I wrote recently:

  http://psg.com/lists/rrg/2008/msg02549.html


Page 3 col 2 paras 2 and 3


I am not sure how valuable multipath transport will be, unless there
are fancy features built into DFZ routers, which would be costly,
hard to debug and manage, and which would only be useful once most
or all DFZ routers were upgraded.

If there was a host in the UK in a network with two separate ISPs,
and therefore two separate addresses via SHIM6, the multipath
approach would probably only affect the path taken by packets within
the UK.  The Australian end of the paths would probably be identical
- and likewise the the paths across the Pacific and the USA.

I think what you wrote about failure detection is pertinent:

   Being able to effectively gauge the status of
   multiple paths requires transmitting a large quantity of
   data and sophisticated subflow control; not all applications
   can continuously send large quantities of data (e.g.,
   VoIP connections), and not all end points are suited to
   perform complex control (e.g., small sensors).

This critique also applies to ITRs trying to do reachability
detection in the non-Ivip core-edge separation schemes.  I discussed
this in my recent message to Iljitsch.


Page 4 col 2 para 2

   Separating edges from the transit core provides additional
   features that are sorely missing in today’s Internet.
   With separation, an end host can send packets through
   the transit core, but can no longer address a packet to
   any specific device inside the transit core.

This may be true of the intention with APT to achieve 100% adoption
and then to physically prevent any end-user networks' hosts from
being able to send packets to any address which is not an end-user
network.  However it does not apply at all to Ivip - or I think to
the other core-edge separation schemes.

I think APT's aim in doing this is interesting, but I doubt it could
ever be achieved with sufficient robustness to provide any real
security benefit.


Page 4 co 2 para 4

I think that this discussion of using the core-edge separation
scheme to introduce fundamentally new protocols, with new addressing
schemes, is important.  Although it would involve an upgrade to all
ITRs, and to the mapping system, it would enable the new protocol to
be widely and reliably used, provided edge networks at both ends
supported it - but without requiring an upgrade to the DFZ routers.


Page 5 col 1 para 2

I was unable to find any CIRL references - Google equated this with
"circle".

What you wrote here:

  The encapsulation of end-user packets makes it easy to trace
  attack packets back to the ER, even if they have spoofed source
  addresses, since the encapsulation header records the addresses of
  the ER and DR.

does not apply to Ivip's encapsulation approach.  Ivip uses the
sending host's address as the source address in the encapsulation
header.

Also, Ivip has two forwarding approaches which do not involve
encapsulation at all:

  ETR Address Forwarding (EAF) - for IPv4
  http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw

  Prefix Label Forwarding (PLF) - for IPv6
  http://www.firstpr.com.au/ip/ivip/ivip6/

There is no trace of the ITR's address in the packets forwarded in
these systems.


For the non-Ivip encapsulation core-edge separation systems, any
system which relies on the source address in an encapsulated packet
is not going to be much use for security purposes.  Indeed it could
be a source of further trouble.  Just because ordinary traffic goes
through an ITR (and by the way, Ivip allows ITR functions in sending
hosts, but not behind NAT) doesn't mean that an attacker would use
an ITR.

Attackers can get mapping information and send an encapsulated
packet to the target, with the source address in the outer header
set to whatever they like.  The packet is encapsulated at the
attacker's host - it hasn't been through an ITR.  If you have a
security system which tries to talk to an ITR and tells it to back
off in some way, then this cannot be done securely due to the ease
with which any attacker can spoof encapsulated packets with some
ITR's address in the outer header.


Page 5 col 1 para 4

This description of mapping information expressing preferences for
which ETR to use when sending packets to a host in Site2 does not
apply to Ivip.  Ivip mapping specifies a single ETR address.
Site2's administrators can change the mapping to some other ETR and
can load-share over multiple ISP links by mapping some micronets to
one ETR and other micronets to another ETR.  This will work fine as
long as the incoming traffic is spread over IP addresses in separate
micronets, which should be easy to do.  If all the traffic was for
one host, the host cold be given two IP addresses in two separate
micronets, and the DNS can supply those two addresses.

In Ivip, an ITR in Site1 can encapsulate packets intended for the
Site2 host to whatever address it likes, but it would be at odds
with the intention of Ivip and it wouldn't make much sense to send
it to any address other than the one nominated in the most recent
mapping update.


I haven't thought much about multipath transport, but my impression
is that it only makes sense when most or all DFZ routers are
upgraded to do this necessarily complex task.  I am not convinced
this will ever happen, or that it would make a huge amount of
difference to the performance of the Net.


  - Robin


--
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