[lisp] Comments on draft-fuller-lisp-ms

[Olivier Bonaventure <[e-mail]>]

Hello,

I had a look at draft draft-fuller-lisp-ms-00.

My first comment is that this is a very good addition to the set of LISP
documents, this will allow the implementation of simpler xTRs and also
allow people to experiment with mapping systems. I thus fully support
this direction on work.

However, I have some concerns about the details and the solution chosen
in the draft.

First, concerning the map register message defined in
draft-farinacci-lisp-12 I completely agree that we need a method to
authenticate the map register messages. Using AH with MD5 and a key
shared between the ETR and the mapping server to authenticate the
mapping register appears more like a quick hack than an implementation.

Instead of using IPSec to authenticate the content of the map register,
I would suggest that we consider adding authentication data inside the
map register at least. The authentication data should be flexible and
support different types of authentications. MD5 with a shared key could
be a first example, but I think that we should also explore the
possibility of using certificates that certify a binding between an EID
prefix and a keypair and use this keypair to sign the mapping register.

Second, the reliability of the transmission of the map register should
be discussed. As map register messages are sent in normal IP packets,
they may be dropped. One possibility could be that everytime an ETR
sends a map-register to a mapping server, it should after a timeout send
a map-request to this server to check that the map register sent has
caused an update of the mapping server.

Third, concerning the map-server processing, draft-fuller-lisp-ms
explains that the map-server does not produce map replies, but only
forwards the map-requests to the appropriate ETRs. This implies that the
 map-server does not need to store all the mapping information (i.e.
rlocs, reachability, weight, priority, ...). In this case, then why does
the ETR indicates all this information in the map register message ?

Fourth, when an EID prefix is served by several ETRs, it seems useful to
expect that the map-server will load balance the received request among
the ETRs that it knows.

Fifth, the ability of sending a negative map reply (with an empty
locator set) is a useful addition. However, it may create risks of DoS
attacks that would be useful to discuss in the security section. The
verification of the contents of the map reply (source port, nonce) is
very important. The draft suggest to send a negative map reply that
contains the largest possible EID prefix. If an ITR accepts a negative
reply containing 0.0.0.0/0, then it would consider that the entire IPv4
Internet is unreachable.


Olivier
-- 
http://inl.info.ucl.ac.be , UCLouvain, Belgium