Re: [RRG] Happiness; lack thereof

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 7 mrt 2008, at 0:30, Michael Meisel wrote:

> 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

No, this one:

D. Jen, M. Meisel, D. Massey, L. Wang, B. Zhang and L. Zhang, APT: A  
practical tunneling architecture for routing scalability, February  
2008, http://www.cs.ucla.edu/~meisel/apt-rrg.pdf

See my message from january 28 for my ALT critique.  8-)

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

Hm, what about the case where a host sends packet p1 to destination d,  
and the local ITR doesn't have mapping for d so it sends the packet  
down the third infrastructure and waits for a mapping reply. But  
before that mapping reply comes back, the host sends packet p2 also to  
d. The mapping server now gets packet p1 which requires a mapping  
reply, but it also gets packet p2, which doesn't really need to  
generate a mapping reply because the mapping reply to p1 will get  
there before the mapping reply for p2 anyway.

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

Well, we can have a discussion on the practical issues, which can of  
course be addressed one by one to varying degrees of satisfaction. But  
in my opinion, it's architecturally undesirable to depend on the  
behavior of a third party system for the communication to work. (I  
mean third party as in managed by a third party, obviously routers and  
DNS servers are generally required in addition to the end hosts.) When  
problems arise, you don't have much recourse. If the source is able to  
detect failures on its own, this is fundamentally more robust.

(There is of course the issue that the source has easy access to this  
knowledge because it's a byproduct of transport protocol activity. But  
systems in the middle, such as ITRs, don't have easy access to this  
information.)

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