Sam,I'm reading the mails about security issues, and wanted to reply. I hope I have not missed some later mails or a re-opening an already closed issue. In any case, you wrote:
* IPSec is not a good fit for this application. If we're going to use IPsec we need to follow the recommendations of the BCP for using IPsec in other protocols. That includes things like specifying what SPD entries are expected and fitting our use of IPsec to RFC 2401.
I agree, and see further below about my response to Noel.
The only protection of the map reply is that it needs to have the same nonce as the map request. Long term, that is unlikely to be good enough. It will be impossible to provide protection against on-path attackers who can observe the nonce unless cryptographic security is used. I understand that the alt does not currently provide cryptographic security.
Not sure about this though. I think the debate about using nothing-vs-nonce-vs-ipsec-vs-tls is too early. First we have to figure out what the security model is. And frankly I'm not sure we have a good idea about that yet, but maybe I'm missing something. If -- as Noel suggests below -- the mapping data itself is protected, then the map request/reply protection has far less to do, and a nonce is likely sufficient to handle DoS attacks.
Also, Noel wrote:
I'm uncomfortable having link-based security (i.e. "between the ITR and map resolver", or "between the ETR and map server"). I'd rather secure the mappings 'at birth', and distribute the authentication along with the mapping. That way, nobody has to trust any entities between the i) ultimate creator of the mapping, and ii) the ultimate consumer.
This is my preference as well. I'd like to see a security model that is based on protecting the data rather than the communications. This will also make it easier to distribute, cache, and re-distribute mapping information.
And Olivier wrote:
I agree, but I would add that mere on/off path designation is probably too simple basis for the analysis. For instance, a control protocol between an ITR and ETR to set up packet forwarding between the two is probably OK even if it is vulnerable to on-path attacks. Once the data packets are flowing you'll be vulnerable to on-path attacks anyway. But I tend to think of the mapping system as a more valuable, centralized resource that needs to be guarded more carefully. And the mapping system is a new component, so if we introduce a vulnerability there then you have an issue with either the source to destination e2e path OR the source ITR to mapping system path. These reasons lead me to believe that on-path attacks may not be OK for the mapping system.I think that this kind of discussion cannot start before we agree on the type of security attacks that LISP must avoid. For example, I'm not convinced that we need to counter on-path attacks with LISP. However, LISP should probably not be vulnerable to off-path attacks, including those with spooffed packets.
Jari
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.