Locator/ID Separation Protocol (LISP) Threat Analysis
draft-ietf-lisp-threats-15

Would have been nice to see a thorough privacy analysis in Section 4. Perhaps that can be a topic for future work.

Thanks for doing this document. I think it's a useful part
of the LISP documentation set.

general: I think you underestimate the purely passive
threats - my point on 2.2 below was almost a DISCUSS but
given the WG have already adopted draft-ietf-lisp-crypto I
figured there's no need to try block this. I would really
encourage you to consider the threats that are mitigated by
that specification here, even if those threats weren't
initially considered as being that relevant to LISP (when
the work on LISP began I mean). If that had been done
already in this draft, I'd have been a YES ballot, if that
makes any difference;-)

- intro: I think you should add a few caveats here to say
that you're not covering threats due to specific
implementations and also that the text here captures only
those LISP-specific threats we know about today and that
more *will* be discovered as deployment continues.
 
- intro: you don't write about DNS here, but if some LISP
configuration settings use DNS names then via DNS with no
DNSSEC an attacker can decide to be on-path sometimes,
off-path other times. That (or similar) might be a nice way
to illustrate the scope here, while also alerting the
implementer to other threats that might affect their
implementations.

- 2.1 I think it'd be valuable to say that the 2.1.x
sections are really just for the sake of exposition - we
cannot assume that all attackers fall into any neat
category. You do note this (more or less) in 2.1.5 but I
think that'd be better done in 2.1. The reason to suggest
this change is that being open to attackers not conforming
to our descriptions is important. 

- 2.2 - which section here covers purely passive monitoring?
All the 2.2.x seem to only cover active attacks. (I'd also
suggest moving the 2.2.10 text to 2.2 similarly to the
suggestion above for 2.1.)

- 3.8 - you probably need to note somewhere (not sure where)
that a bad PRNG would improve the attacker's chances in
various ways. I think a calculation of the probability of a
nonce collision (for both a good and not-good PRNG) could be
a useful addition.

- 3.8, 3rd para: I would argue that this threat is a "core"
point to be made, as it's arguably the main LISP-specific
threat and ought be emphasised more, e.g. via a mention and
pointer in the introduction, or otherwise.

- section 4 is pretty weak to be honest. I think you could
at least recognise that LISP, as with any mechanism that
concentrates traffic (between xTRs) means that passively
monitoring plaintext is easier than before and that there is
therefore value in encrypting the traffic between xTRs as is
proposed in draft-ietf-lisp-crypto

- (nit) section 5 has a really odd sentence " The usage will
be designed and defined specific for the needs of the
specification." I've no idea what that means TBH.