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

From: Olivier Bonaventure <[email-masked]>
Date: Thu, 26 Mar 2009 15:44:38 +0100

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

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 26 Mar 2009 22:19:08 -0700

> allow people to experiment with mapping systems. I thus fully support

Thanks Olivier.

> mapping register appears more like a quick hack than an  

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

> prefix and a keypair and use this keypair to sign the mapping  

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.

> caused an update of the mapping server.

Yes, we are considering this.

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

> expect that the map-server will load balance the received request  

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.

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

> 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  

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

Dino

> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp