[RRG] Comments on draft-lewis-lisp-interworking

[Jari Arkko <jari.arkko@piuha.net>]

I read this draft a couple of weeks ago and had a few comments.

First of all, as I have stated before, having this document has been a
big improvement. We need to talk about the way legacy and new networks
communicate, we need to talk about the incentives and deployment
scenarios. Thanks for writing it!

>    In case 3 (LISP site to Non-LISP site), a LISP site can send packets
>    to a non-LISP site because the non-LISP site prefixes are routable.
>    The non-LISP site need not do anything new to receive packets.  The
>    only action the LISP site needs to take is to know when not to LISP-
>    encapsulate packets.

Hmm. But aren't there other things involved, too? If you do not
LISP-encapsulate, you must be performing some kind of NAT translation to
the transit address space, right? You describe that later in the
document, but the above text excerpt does not recognize that you have to
do more than just send packets...

Observation on Section 4.3: limiting the impact of routable EIDs is not
enough, we have to create an incentive to do so. Since we cannot block
people from advertising things in BGP, pretty much the only remaining
option is to make some other approach more desirable: better, cheaper,
faster, etc. Can you say something about what

Comment on Section 5: The document should talk about what is the
motivation for deploying PTRs.

Comment on Section 5: I don't understand how we distinguish advertising
the EIDs vs. larger prefixes. Given the non-aggregability of EIDs, can
you even have larger ones, other than "all EIDs"? The business
implications seem severe, because you cannot have contracts for specific
service.

Section 5.2: it seems that the MTU implications of PTRs are different
from pure LISP. In pure LISP, you have the ability to locally configure
your network with an MTU that fits in 1500 bytes even if a LISP header
is added to it. With PTRs, the encapsulation is happening without the
knowledge of the legacy endsite. This means that either we must require
the legacy endsites (and paths to them) to be able to deal with PMTU
discovery or the PTR - LISP site tunneling mechanisms need to be able to
carry 1500 byte payload packets. Some discussion of this might be useful
in the document.

Section 5.3, scaling. It seems that we hit the worst point when 50% of
the Internet is LISP capable and 50% not. Assuming equal traffic
distribution, 25% of traffic in the Internet would have to go through a
PTR, right? It would be interesting to see some discussion of the
anycast routing properties in this situation. For instance, do we expect
that only "all EIDs" can be advertised? If so, how stable can we expect
the anycast routing to stay? Can we expect sudden switching to other
PTRs, which with these traffic amounts would obviously be a pretty
significant event? I'm sure we have some data on this from DNS anycast
already...

Section 7, security considerations. There is the obvious vulnerability
that you can advertise someone else's EID space as a PTR, and you get to
see their traffic. But the interesting question is if this is any
different from you doing the same thing in regular BGP. I think there is
one difference -- in BGP you are limited with what you can do for the
attacker - victim site path, because you need to simultaneously attract
the victim's packets to you but also be able to forward them to the
victim after taking a peek into them. With LISP encapsulation, this is
not an issue and you can do it from any location.

In any case, I'd like to see some discussion of this draft and the above
topics in the meeting!

Jari


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