On Sep 7, 2009, at 4:19 PM, Jari Arkko wrote:
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.
When you say "the data itself is protected", I _think_ you mean something different than Noel does.
Noel is saying that the mechanism for adding mapping entries to the mapping system is protected. This is currently true by virtue of the fact that mapping registrations use IPsec AH, and nothing will be added to the mapping system that isn't properly authorized.
However, the data that is passed in a mapping reply is not "protected". An ITR sends a mapping request to its mapping server. The response will come back from another node (an ETR), and will contain data that is not encrypted and cannot be authenticated. The only "protection" on the response is that it contains a 32-bit nonce that matches the request. So, anyone who can see the request (or guess its contents) can send a spoofed response that will be accepted by the requesting ITR. Even if two replies are received (one valid and one spoofed), the ITR will have no means to tell the difference between them.
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 themappings 'at birth', and distribute the authentication along with themapping. That way, nobody has to trust any entities between the i) ultimatecreator 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.
I think this is a good general approach, but there is nothing in the current protocol that does this.
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 agree. I think that it should be possible for an ITR to somehow authenticate the mapping data it receives in a mapping request. Something similar to the level of security provided by DNSSEC would be appropriate, in my opinion.
Margaret
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.