[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Separation vs. Elimination
Robin Whittle wrote:
> Hi Dan and Colleagues,
Hi Robin,
> 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.
This is exactly why we omitted it -- it was a short paper, and Ivip's
mapping system doesn't quite fit our definition of separation.
> 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.
In defense of APT, I think you are making a *lot* of assumptions about
the present and future here which may not hold true. However, that's
beside the point and I'd like to keep this discussion at a higher level...
> 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.
In the four paragraphs you wrote above, I think you are focusing on
specific methods and implementations, whereas our paper is trying to
argue for the broader idea of separation. Of course, only a properly
designed realization of separation can achieve all of its benefits.
>
> 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.
We are using our own terminology because we find the LISP terminology
confusing. A lot of people we've talked to (outside of the RRG)
misunderstand APT because they see that TR stands for Tunneling Router,
and they understand "tunneling" as the use of a pre-configured tunnel,
like an ssh tunnel. We felt "encapsulating router" and "decapsulating
router" were much clearer.
>
> 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.
As I mentioned above, Ivip's mapping service does not fit the definition
we have in the paper for a mapping system in a separation approach, so
we felt it would be misleading/confusing to include it. We meant no
disrespect. =)
>
> 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.
Yes, our philosophies differ significantly here. I think we've discussed
this before, but I don't believe in solving a technical problem (a
scalable number of updates in the mapping system) with an economic
solution (pay per update). But that's a whole other can of worms.
> 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.
Protocols aside, they seem quite similar to me -- in both cases, you
query a hierarchy of servers, eventually getting the information you
requested directly from the authoritative source. The major difference
is that DNS queries start at the root of the tree directly, whereas
LISP-ALT queries start at a leaf before ascending to the root.
> 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.
I don't see why DFZ routers need to be involved -- isn't the whole point
that they don't?
> 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.
If that were true, it would be due to the lack of diversity in the
physical, inter-continental wires, which we can't do anything about in
software, as hard as we might try. =)
> 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.
I'm not sure what your basis is for this claim -- in APT, for example,
one data packet from one ER (a.k.a. ITR) to a failed DR (a.k.a. ETR) is
generally sufficient to discover the failure.
> 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".
Ah, it seems the URL was accidentally left out of the bibliography. Here
it is:
http://read.cs.ucla.edu/~frost/cirl/
Note that this is very much a WiP. We just cited it as a proof-of-concept.
> 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.
Good point, this is definitely something that should be in a threat
model in future work on blocking bad traffic at ERs/ITRs. But I don't
see it as necessarily unavoidable.
>
> 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.
I think you may be misunderstanding the multipath transport proposal. Of
course, I'm no expert on the subject, but I'm certain that one of its
basic assumptions is that changes need only be made in end hosts.
-Michael
> - 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
--
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