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

[Dino Farinacci <[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.

Thanks Olivier.

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

It is simple and IPsec is suppose to be used for packet authentication.

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

Since each side (the ETR side and the map-server side) needs explicit  
configuration, which aids in the security of both allowing the EID- 
prefix into the mapping system as well as authenticating the binding,  
you can also configure the HMAC used. In fact, it's just another  
element of a multi-tuple passphrase that can be used.

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

Yes, we are considering this.

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

Just so the implementation can remain simple and reuse code. Plus, if  
later we want the full mappings to be stored in the map-server, we  
already have the packet format supporting it.

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

Yes, we are planning on doing this. Plus we want each ETR at the site  
to register to more than one map-server for redundancy.

> 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

It may be useful but we are proceeding with caution. There are many  
complications that may arise from it so it may be more cost than  
benefit.

> 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

The largest possible prefix which would cover a non-EID-prefix. The  
point is to put the prefix in the map-cache, so when a packet matches  
it, that we can natively-forward the packet (to a non-LISP site).

> reply containing 0.0.0.0/0, then it would consider that the entire  
> IPv4
> Internet is unreachable.

No, it would consider the entire Internet as non-LISP capable.

Dino

>
>
>
> Olivier
> -- 
> http://inl.info.ucl.ac.be , UCLouvain, Belgium
> _______________________________________________
> lisp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lisp