Re: [RRG] LISP-EMACS (was: LISPEMACS & LISP-ALT)

[Robin Whittle <rw@firstpr.com.au>]

Hi Scott,

Here are some further thoughts on LISP-EMACS.  By the way,
Thunderbird 2.0.0.9 (20071031) removes the bracketed part of this
subject line when creating a reply.

The most obvious way I can think of to reduce the packet
amplification problem I referred to is to increase the number of
multicast groups - so each one sends packets to a smaller number of
ETRs.

LISP-EMACS-00 involves chopping the IPv4 destination address in the
middle, so the 16 least significant bits are discarded, and the 16
most significant bits are used to select the multicast group.

This only uses 2^16 multicast addresses, 1/16 of the 2^20 available.

You could assign multicast addresses 16 times finer and so, in
general, reduce the number of packets multicast by about this factor.

Since the unicast /8s are 0 to 223, this would require 7/8 of the
multicast address space:

  EIDs 0.0.0.0  to 0.0.15.255            Multicast 224.0.0.0
  EIDs 0.0.16.0 to 0.0.31.255            Multicast 224.0.0.1
  ...
  EIDs 223.255.240.0 to 223.255.255.255  Multicast 237.255.255.255

I have no idea what costs this imposes in structuring the multicast
system and I doubt that it adequately resolves the problems with
efficiency and susceptibility to DoS, but as far as I know, it is an
option.

I now understand why the ID (4.9) states that a nonce is inadequate
as an authentication of a map reply message.  There needs to be
either a digital signature which the ITR can use to be sure the
reply came from an ETR which is authoritative for the mapping of
this EID address, since a nonce from the ITR is sent out with
multicast to multiple ETRs.   This seems to require an overly
elaborate PKI arrangement, with the ITR having to send other packets
and get responses before it could be sure that the mapping
information it received could be trusted.  Even if this cost could
be contemplated, the delays would add up and in many cases, there
would be no point in the ITR forwarding the packet by the time it
could be sure the mapping information was valid.  Both the
LISP-EMACS network and any PKI system would be global in geographic
spread, so the delays would often be quite long.

I think any one of these problems:

   Packet amplification in multicast => inefficiency and DoS

   Delays and costs in authenticating map reply messages.

   Authenticating requests to join multicast groups => PKI.

   Generally global size of LISP-EMACS network leading to excessive
   costs and delays. (Likewise LISP-CONS' CAR-CDR network.)

   ETRs snooping on traffic packets sent to other end-user's
   networks.

are severe enough to make the EMACS proposal unworkable.
Nonetheless, I think it is worth tossing these ideas about - they
might lead to something better.

You refer to Snooping in 4.6.  Some kind of "Join Filter" would be
required to ensure only ETRs which were authoritative for the
relevant EID space could join the multicast group.  This seems to
require a large overhead of looking up some centralised system by
which the authority is delegated, perhaps with crypto to secure it.
 I am not sure how the authority is physically verified in LISP anyway.

Ivip has a comparable problem in ensuring that an attacker can't
inject bogus packets into the "Replicator" steam of mapping data
which is fanned out to ITRDs and QSCs.

Even if you did have reliable "Join Filters", this wouldn't solve
the problem of snooping.

Any "owner" of EID space within the range which is covered by a
single multicast group will be able to snoop on some of the initial
packets in communication flows to other networks which use the same
group.

This seems to be a fundamental limitation of LISP-EMACS.  I think
that alone would be sufficient for almost all end-users to regard it
as unacceptable.


I am not sure about how LISP-EMACS would scale to IPv6.  With IPv4,
about 24 bits are "in play" between the MSB of the address space and
the LSB of the currently used smallest end-user address assignment.
 I think LISP or any other ITR-ETR scheme should be used to slice
address space finer - to individual IP addresses in principle, and
certainly to /28 and /30.

This means there would be up to 32 IPv4 bits "in play".  Your
current proposal uses the most significant 16 of these to split this
space into 2^16 (actually 224 * 256 = 57344) multicast groups.  My
modification above splits the space into 16 times this number of
multicast groups.

I am not sure how small a micronet an ITR-ETR scheme should support
in IPv6.  PI /48s are currently being handed out, so I guess it
would be desirable to have something finer.  Ideally, to /64 would
be good, but for the sake of this discussion, lets say to /52.

Although, at present, a few most significant bits in IPv6 are
relatively fixed, this "52 bits in play" is a much more challenging
situation for LISP-EMACS than IPv4's 32 bits.

LISP-EMACS needs to split the "in play" bits into two categories:

  1 - Most significant bits - which set the number of multicast
      groups.  This is limited by multicast address space (I guess
      not much of a problem in the IPv6 overlay network) and by
      whatever administrative costs there are in running this number
      of groups.

  2 - The least significant bits, which - depending on how densely
      populated that region of the address space is, in terms of
      end-user networks with unique ETRs - determines how many
      ETRs each packet is multicast to.

I haven't thought much about IPv6 in general for Ivip, so I am not
saying my proposal has no scaling challenges with it, but I think
that a more fully developed LISP-EMACS proposal should contemplate
how the greater number of IPv6 "in play" bits would be split.


  - Robin


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