[lisp] Comments on draft-saucez-lisp-security-00

[Sam Hartman <[e-mail]>]

Hi.

I agree with the goals of the approach you're taking as something we
should do.  I think that my effort and yours can proceed in parallel
adapting information from each other.  They may merge some day,
although I think right now that the taxonomy I'm taking is somewhat
different and I don't think it would make sense to merge at this
point.

One thing I think it would be valuable to adopt is to set out some
high level goals for LISP security; perhaps you could use something similar to mine, or describe your own.
My high level goals follow:

    * LISP will not make Internet security worse
    * LISP will not create an architecture in which ongoing IETF-wide security goals such as the SIDR working group or BCP 84 are made more difficult.

The big question is what does it mean to make the Internet security worse and what is the current security model of the Internet. In answering these sorts of questions, 
Then, I recommend referencing your requirements back to these goals.


Section 4.1
When you talk about security of the data stream, what security  services are you talking about?  Confidentiality?  Integrity?  Peer entity authentication?
Where do these requirements come from for LISP as a routing scalability solution?

Why would you propose IPsec  inside the tunnel to secure LISP rather than IPsec outside the tunnel?

Section 4.2 discusses packet spoofing.  How is the work in SAVI applicable?  I cannot figure out how to apply what I know of SAVI to LISP?

Section 4.3 proposes that the nonce is similar to the L2TP cookie.
How is that true?  The L2TP cooking is a cookie established between
two peers to prevent off-path attacks.  If a packet is included in an
L2TP tunnel with an improper cookie, that packet is discarded.  In
what circumstances is a 24-bit nonce long enough to provide
protection?  In what circumstances can an ETR discard a packet based
on a nonce?

Section 4.4.1: Another important attack is DOS attacks based on rloc
entries.  Take a look at the mip6 route optimization security
analysis.  One attack is to set up a very high bandwidth flow to EIDs
you own.  Then update your mapping redirecting some or all of that
traffic off to some unsuspecting person.  This is the attack that
motivates the requirement that someone with an RLOC prove that they
actually want to accept traffic before you redirect to them.

Section 4.6.2:  How will ignoring the loc reach bits if nonce/versioning did not change help?  Wouldn't an attacker change the nonce/version?

Section 4.6.3: How do you deal with missing packets/version numbers changing rapidly enough that one ETR doesn't see a packet of a particular version?

Section 4.6.4: How can filtering spoofed EIDs on the ITR remove cache
poisoning?  How do you actually filter out spoofed EIDs/identify them?
Section 4.6.6: How do PITRs effectively filter?  What does requiring a
source EID be in the mapping cache on the *ETR* accomplish?  Section
5.2: I think that there are some significant deployment considerations
that generate requirements.  For example I think we need a level of
security similar to what we get on the Internet today if two clients
of the mapping system do not share trust anchors for public-key
operations.  I think it is reasonable to assume that an ITR and its
map resolver share trust, an ETR and a map server share trust.  However I think we want to do at least as well as the internet does today without requiring more trust.