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 [EMAIL PROTECTED] 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
