[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Happiness; lack thereof
Hi Iljitch, thanks for a great post, I think it's really important we
bring our discussion back up to higher-level issues like this if we're
going to make progress. See my comments below.
Iljitsch van Beijnum wrote:
After a hiatus in reviewing drafts/proposals, I've been reading the
LISP-APT draft.
I think you mean LISP-ALT. :-D
Implicit mapping requests should be considered harmful. Don't hide
relevant information. The correlation between the need to send packets
over the third infrastructure and lack of mapping state is not equal to
1, so treating the result of one as the other is a bad idea. ITRs know
when they need to send mapping requests, so they should do so
explicitly. This way, the mapping database doesn't have to do
unnecessary work and a modicum of data and control plane separation is
maintained.
This is worth exploring, but, in APT at least, there is no time that an
ITR requests a mapping from a default mapper without also requesting a
packet to be forwarded on its behalf. So it seems unnecessary.
Depending on return packets to indicate problems, such as the address
for an ETR becoming unreachable, an ETR becoming unreachable or a
destination "behind" and ETR becoming unreachable is way too dangerous.
Path MTU discovery does this and it works quite poorly in practice. At a
minimum, unreachables will be rate limited. They may also fail to be
generated, be filtered or spoofed.
Though APT relies on return packets to indicate problems, I think we've
addressed a number of these issues. First of all, we use normal IP
packets for this purpose, so filtering is unlikely. The destination
address for such packets comes from the mapping database, and the sender
cryptographically signs these packets. The info that went into the
mapping database was also cryptographically verified. So spoofing should
be very difficult. Since it's part of the APT protocol, I don't see why
these packets are any less likely to be generated than a BGP withdrawal
today.
-Michael
--
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