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

Robin, thank you for putting so much work into this! Michael and I think
you've done an excellent job analyzing APT, but there are a few
inaccuracies and misunderstandings we wanted to respond to. See below.

Robin Whittle wrote:
  > LISP-APT  (APT is only intended for eFIT.)

The wording is too strict. While APT was intended for eFIT, its main 
design concepts are generalizable towards any similar routing 
architecture. With a few modifications, we expect that APT can be made to 
work with LISP. In your post, you choose not to "consider how LISP might 
work with APT", which is fine. We are just pointing out that APT is not 
limited to ONLY working with eFIT.

  > the same concept in eFIT-APT: "updated mapping entry" - which are
  > real-time, local, push messages directed to the caching ITRs (and
  > for Ivip, the caching Query Servers) which they query.

This is inaccurate. Default mappers never push unsolicited mapping
entry updates to their tunnel routers. A default mapper will only send 
mapping entry information to a TR when the TR requests this information 
(by forwarding a data packet to the default mapper). Thus local mapping 
entry updates are strictly pull messages. Mapping entry TTLs within a TR 
cache ensure that tunnel routers pull updated mapping entry info as frequently as desired.

Perhaps our paper was unclear on this point. We will try to rectify this 
in future drafts.

  >   Each transit network is expected to run at least one "Default
  >   Mapper", which may be router (at least it can encapsulate
  >   packets, even if it only has one interface), and which has a
  >   real-time updated copy of the entire eFIT-APT mapping
  >   database. (Except in the future for IPv6 - section 7.4.)

Actually, it's likely to be the case with IPv6 that every default mapper 
still stores the full table. We meant section 7.4 as a contingency plan, 
just in case the global mapping table actually approaches its theoretical 
maximum size under IPv6. Note that 10^18 is eight orders of magnitude 
greater than the human population of the earth, so we aren't likely to
actually use all of those prefixes any time soon.

  >   Default Mappers also have the equivalent of an Ivip "Notify":
  >   "M1 can respond with an updated mapping entry". There's
  >   no mention of the ITR having to acknowledge this - and even
  >   if it did, if anycast is used, it would be difficult to ensure
  >   that the ack would go to the correct Default Mapper. Both
  >   Ivip and APT should have a way of ensuring the updated mapping
  >   information really has been received by the ITR (APT) or QSC,
  >   ITRC or ITFH (Ivip) it was sent to.

We're not sure what you're referring to here. We don't have any push 
messages from the default mapper, and, as you mentioned before, the worst 
thing that can happen if an ICMP mapping response packet is lost is that 
the next packet goes through the default mapper
as well.

  >   Devolving the multihoming link selection problem, and the TE
  >   functions, to the Default Mapper is a good idea, I think, but
  >   involves more ICMP packets to ITRs with "updated mapping
  >   entry" information. As noted above, I don't see any provision
  >   in APT for this to be delivered in a reliable manner. There
  >   also needs to be some crypto or protection against an attacker
  >   spoofing packets with the Default Mapper's address, to ensure
  >   the ITR's cache is not corrupted by someone who wants to steer
  >   packets to their own address.

We think perhaps you misunderstood our use of TTLs. The TTL is in theITR, 
not the default mapper. The default mapper only tells the ITR whatvalue to 
use. When a TTL expires, the ITR invalidates its corresponding cache entry 
completely. As you mentioned, the worst thing that happens in the case of 
a lost ICMP mapping reply packet is that the next packet gets
sent to the default mapper as well.

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.

  > eFIT-APT: Not documented, but APT mentions an ICMP Destination
  > Unreachable message being generated if the encapsulated packet
  > does not reach an ETR, so I guess this means UDP encapsulation
  > with outer SA = ITR (or Default Mapper) address, similar to that
  > described in LISP-01's description of LISP 1 / 1.5.

Not sure if this is correct. It sounds like you believe that Destination
Unreachable ICMP packets are generated whenever encapsulated packets are 
lost.
Is this your thought? Is this why you also believe that we expect UDP
encapsulation?

Destination Unreachable ICMP packets in APT are used in the same way
that they are used today. The messages are only generated when the 
destination router cannot be reached due to a malfunction of some subset 
of routers.

Again, we are not sure if there is a misunderstanding here.

  > If an end user is with provider X, using some of their PA
  > addresses, could they go to another provider Y for connectivity,
  > or X and Y or Y and Z for multihoming, and still have to rely on X
  > to to the mapping the way they want?
  >
  > What if an AS-end-user with their own PI space is currently
  > connecting with provider X. If they want to move to provider Y,
  > does this means that X's Default Mapper no longer is
  > authoritative, and that Y's is? I am confused about exactly how
  > eFIT-APT works.

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.

  > With LISP and Ivip, ETR and ITR functions may often be in the same
  > device. ETR and ITRs always being in the one device is enforced
  > by the current definition of eFIT-APT - but I don't see why the
  > system needs to be so inflexible.

You're right, there isn't any good reason.

  > Having the ITR and ETR functions fixed at
  > these routers - Provider Edge routers I think - seems likely to
  > produce a bottleneck and burden these routers with even greater
  > workloads. This may also preclude doing ETR or ITR functions in
  > servers, which may be more cost effective than routers with all
  > the new functionality.

We aren't sure we understand -- are you trying to say that the TRs'
functionality is too complex for routers but requires too much speed for
servers? We believe that this functionality should be well within the
capabilities of routers, that was part of the reason we tried to keep
TRs as simple as possible.

  > eFIT-APT: The placement of TRs is specifically limited to the
  > border routers between providers and their non-provider "customer"
  > networks. ETRs have complex communication functions, including
  > detecting failure of the link to the end-user's host or router.
  > They send messages to their local Default Mapper and to the ITR
  > function of the TR which encapsulated the packet (which can
  > include the Default Mapper of the sender's network).

We aren't hardware experts, but it seems to us that these aren't
particularly complex functions for routers. Routers already detect BGP
connection failures. Border link failure detection could also be
implemented as a persistent TCP connection. (Note that it is only the
customer-edge-to-provider-edge link that needs to be monitored.) Routers
also already send ICMP packets in response to certain incoming packets
(Destination unreachable and so on).

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

Good point. We will include an incremental deployment plan in detail in a
future draft. Hopefully, we can address many of your concerns in this 
area.

- Dan and Michael

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram