Re: [lisp] [#3] lisp-ms needs security between ITR and map resolver

[Sam Hartman <hartmans-ietf at mit.edu>]

>>>>> "Jari" == Jari Arkko <jari.arkko at piuha.net> writes:

    Jari> Not sure about this though. I think the debate about using
    Jari> nothing-vs-nonce-vs-ipsec-vs-tls is too early. First we have
    Jari> to figure out what the security model is. And frankly I'm
    Jari> not sure we have a good idea about that yet, but maybe I'm
    Jari> missing something. If -- as Noel suggests below -- the
    Jari> mapping data itself is protected, then the map request/reply
    Jari> protection has far less to do, and a nonce is likely
    Jari> sufficient to handle DoS attacks.


I agree it's really too early to be having this discussion.  I brought
it up because it was on my mind if it didn't get written down I'd
forget it.

My suspicion is that we'll end up divinding the security into three legs:

* ITR to map resolver
* inside the mapping system
* map server to ETR.

My suspicion is that each mapping system will have its own internal
security model.  For example, ALT probably ends up using something
similar to SIDR internally.  Some mapping system based on DHTs and
cryptographically generated prefixes would not benefit from something
like SIDR at all.

In addition, I'm not sure that all ITRs will be in the position to
have the CRLs, trust anchors, trust anchor updates and intermediate
certificates necessary to verify mappings. So, it might be better to
have a simpler trust relationship between an ITR and its map resolver
and to have the map resolver do the heavy lifting for security.

Also, before we have real security in the map system--while the map
system security looks a lot like current core BGP security--then the
link between the ITR and map resolver looks a lot more attractive as a
target.  It may well run over access networks or other relatively low
security links.  We may be able to assure that the alt runs mostly or
completely in the core.q So, before there is real mapping security
within the alt, we may get significant benefit from security the
ITR->map resolver link.

However, as you point out, it's too early for this discussion.  Also,
the above assumes some significant changes to the ITR<->map resolver
protocol.  I believe those changes are needed for other reasons.