[RRG] Re: [RAM] LISP NERD/CONS, eFIT-APT & Ivip compared

[Michael R Meisel <meisel@cs.ucla.edu>]

Hi Robin, here is a long-overdue response to a message you sent in late 
July. As I mentioned in my previous post, Dan and I were both working 
away from UCLA this summer. Sorry for the delay.

Robin Whittle wrote:
> This means that all three other proposals - LISP-NERD, LISP-CONS
> and eFIT-APT rely on short caching times to achieve rapid
> multihoming service restorations.  This means the enquiry and
> response traffic (LISP-CONS and eFIT-APT) or the polling traffic
> for database update files (LISP-NERD) rises dramatically as the
> caching time is shortened in an attempt to speed service
> restoration times.

I don't feel it's my place to speak to the other proposals, but APT does 
not rely on the caching time to detect failures. See section 5.1 in our 
draft. We discuss the various scenarios that could cause reachability 
failures and how each one is handled. We put a particularly strong 
emphasis on avoiding packet loss whenever possible. As soon as a failure 
is detected, the ITR will immediately query its default mapper for a 
different mapping entry, regardless of the remaining time before the 
cache entry expires.

> > In regards to their security, we discuss this in section 7.2 of our
> > draft. ICMP mapping packets never need to travel between ASes, so
> > we insist that they always be dropped at the border routers within
> > transit space. This means that they can only be spoofed in any
> > given AS by a device within that AS. I suppose we could sign them,
> > but we didn't really see a need.
>
> I think this places a considerable burden on the border routers of 
> the AS, since they need to do deep packet inspection on every ICMP 
> packet which comes in.

This could be the case. We plan to discuss this (and other 
implementation issues) with some of the router vendors, and security is 
certainly one the main areas we are seeking to improve upon.

> What sort of encapsulation do you use?

This is purposely left ambiguous, as we intended APT to work for 
multiple architectures. Furthermore, we are mainly designing APT for use 
with the eFIT architecture, for which I see this as an open issue.

> Is the SA (Source Address) of the outer header that of the ITR or
> of the sending host?

The ITR, or in some cases its default mapper. End-host addresses are not 
and should not be routable inside transit space. The *inner* header will 
have the originating host's address as the SA. This also means that 
end-user networks can use any addressing scheme that they and their 
destination user network both support, independent of the addressing 
scheme used in transit space. This is one of the goals of eFIT, see the 
references in our draft.


> > It's the customer that is ultimately authoritative for their own 
> > mapping, even though their transit-space addresses are 
> > provider-assigned. We expect that ALL of a customer's providers
> > will announce the same mapping information on their behalf. All of
> > these mappings should be completely identical (and contain all of
> > the customer's ETR addresses at all of their providers). One thing
> > we have discussed (which is not in the draft) to ensure that they
> > are indeed identical is to allow customers to cryptographically
> > sign their mappings. In combination with the misconfiguration
> > detection scheme we discuss in section 7.1, this should prevent
> > providers from being able to affect the global mapping table with a
> > mismatched mapping.
>
> OK - I have a rough idea of what you are proposing. I have quoted 
> this in the comparison page. I understand from this that the end-user
> needs to have their own server, or secure messaging system, to 
> control the mapping data for their prefix which multiple Default 
> Mappers in multiple provider networks advertise via new BGP 
> messages.

The transfer would only have to occur once per provider per mapping 
change, which should be quite rare. We were envisioning something quite 
simple that doesn't involve any new servers, and maybe not even any new 
protocols.

> Is this a transition arrangement or a permanent one?  An end-user
> leaves ISP-X for ISP-Y and ISP-Z - then all three could be
> advertising the same mapping information for a while, until the
> end-user no-longer needs ISP-X?

In this case, ISP-Y and ISP-Z would announce the new mappings, which, if 
properly signed, would replace the old mapping from ISP-X.

> I would really appreciate you writing more on incremental
> adoption, because the best I can imagine for eFIT-APT results in
> my critique:
>
>    With eFIT-APT, there would be no benefit for early
>    adopters (no portability without grave loss of reachability -
>    and TE only for packets from upgraded networks) and no
>    benefit for the whole network (removal of prefixes from the
>    BGP routing table) until virtually all networks had upgraded.

This is one issue we will certainly be putting a lot of thought into 
over the next couple months. Stay tuned.

> I think that the complex communications which LISP and eFIT-ETR
> ITRs engage in, handling ICMP messages etc. - makes them hard to
> implement on on ordinary router, because these are bound to
> involve the router's main CPU (as far as I know) and that is busy
> enough as it is.
>
> For Ivip, I can imagine a plain server with suitable software
> being a full database ITRD, doing up to half a gigabit of ITR
> encapsulation, because there are no decisions to make about which
> address to tunnel to, no ICMP messages to take notice of etc.

APT TRs never have to make a decision about which address to tunnel to, 
this decision is made by the default mapper when it provides a mapping 
entry to a TR. The only extra functionality TRs require is 
encapsulation, decapsulation, and storing, retrieving, and invalidating 
cache entries. I believe LISP has this requirement of their ITRs as 
well. In any case, this is another issue to bring up with the hardware 
vendors.

> With the current definition of eFIT-APT, it would not be practical
> to use servers at all for ITR functions, because you locate the
> ITR functions exactly in the CE routers, which have to be real
> routers with hardware FIBs, multiple interfaces etc.
>
> A server can't do all the things a CE router must do, but it could
> do an Ivip-style ITR function.  A server could probably also be
> used to do the more complex ITR functions of LISP or APT, but not
> if these functions had to be in a conventional router.

Actually, we intend ITR and ETR functionality to be located at PE 
routers. TRs are the devices that really need to push large amounts of 
data, and we have therefore kept their functionality as simple as 
possible. The default mappers are making more complex decisions, but do 
not need as much raw speed since they are only used transiently and 
intermittently. Therefore, a default mapper could perhaps be implemented 
in a server.

> My aim with Ivip is to keep the ITR and ETR functions simple, with
> no communication, no reception of ICMP messages etc. other than
> the communication required for an ITRD to get its full database
> feed or for an ITRC or ITFH to query a QSD/QSC query server, and
> receive "Notify" messages pushed from the QSD/QSC to it when
> mapping changes for some range of addresses for which the ITR is
> currently caching mapping.

We have the same goal of simplicity in TRs. I don't see how our TRs are 
more complex than Ivip ITRCs, in fact they do very similar things. We 
only require a mapping *entry* cache (no decisions required, only 
lookups) and, like your Notify messages, our ICMP packets can only serve 
to add or invalidate cache entries.

-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