[lisp] AD review of draft-ietf-lisp (part 6)

[Jari Arkko <[e-mail]>]

Technical:

Overall, the security considerations section is a bit thin. I don't think we need a lot of additional text, but there are some additional pieces of information that need to be added. Some suggested text below.

> The nonce, coupled
> with the ITR accepting only solicited Map-Replies goes a long way
> toward providing decent authentication.

Hmm. This is not really descriptive. How about this instead:

The nonce, coupled with the ITR accepting only solicited Map-Replies provides a basic level of security, in many ways similar to the security experienced in the current Internet routing system. It is hard for off-path attackers to launch attacks against these Lisp mechanisms, as they do not have the nonce values. Sending a large number of packets to accidentally find the right nonce value is possible, but would already by itself be a denial-of-service attack. On-path attackers can perform far more serious attacks, but on-path attackers can launch serious attacks in the current Internet as well, including eavesdropping, blocking or redirecting traffic. Lisp relies on the correct operation of a BGP-based routing system [LISP-ALT], but so do the current Internet routing mechanisms.

> It is a good idea to have instrumentation in place
> to detect thrashing of the cache.  Implementation experimentation
> will be used to determine which cache management strategies work
> best.

Yes, but I think we should also acknowledge that defending against cache trashing attacks is hard:

    It is a good idea to have instrumentation in place
    to detect thrashing of the cache.  Implementation experimentation
    will be used to determine which cache management strategies work
    best. In general, it is difficult to defend against cache trashing attacks.

(Unless, of course, I'm missing some obvious schemes that show promise of avoiding some of these issues against determined attackers. It is also possible that if we described the situation in more detail, we'd be able to describe the threats in a more rational way. E.g., outsiders can cause some (limited) problems, insiders could cause big trouble but are generally a bit more trusted, etc.)

>     This experimental specification does not address automated key
>     management (AKM).BCP 107  <http://tools.ietf.org/html/bcp107>  provides guidance in this area.

Yes, but I think we should include two additional important pieces of information. 1. you need to acknowledge that you are not following BCP 107 in this case, as it requires AKM under certain conditions (we are within those conditions, right?). And 2) more importantly, you need to document the implications of not providing AKM. Personally, I do not necessarily consider it a panacea, and often the nonce etc. mechanisms are far more important. In any case, the reader needs to understand what we are losing without AKM.

> 13.  Network Management Considerations
>
>    Considerations for Network Management tools exist so the LISP
>    protocol suite can be operationally managed.  The mechanisms can be
>    found in [LISP-MIB] and [LISP-LIG].

It is good that you point to these specifications. I wonder if there are additional things you should say in this spec, however. Are there parameters that Lisp needs to operate? Are they and their default values described in LISP-MIB? There are many good pieces of advice about the management of a Lisp network in previous sections, should there be some kind of summary/pointers for these here as well?

Editorial:

> Return- Routability

s/- /-/


>     datragram.  If a LISP encapsulated packet arrives at an ETR, it MAY
>

datagram

> system [KARP  <http://tools.ietf.org/html/draft-ietf-lisp-15#ref-KARP>], [RPKI  <http://tools.ietf.org/html/draft-ietf-lisp-15#ref-RPKI>],
>     [BGP-SEC  <http://tools.ietf.org/html/draft-ietf-lisp-15#ref-BGP-SEC>], [LISP-SEC  <http://tools.ietf.org/html/draft-ietf-lisp-15#ref-LISP-SEC>],

s/[LISP-SEC],/[LISP-SEC]./

Jari