Subject: Re: [lisp] Call for interest in working on security

From: Sam Hartman <[email-masked]>
Date: Fri, 09 Oct 2009 16:20:48 -0400

>>>>> "Luigi" == Luigi Iannone <[email-masked]> writes:

    Luigi> Coming back to you page, I really think that we should
    Luigi> analyze the mapping system from the inside. What I mean is
    Luigi> that we do not need to analyze the ALT, or whatever mapping
    Luigi> system you like, the most appropriate approach is IMO to
    Luigi> give a set "guidelines/requirements" (I do not have a
    Luigi> better word right now) for designing a mapping system.

I agree we should do this.
I think that it's even one of our charter deliverables.

    Luigi> Discussing if ALT provides the same level of security like
    Luigi> BGP is IMHO a waste of time.

Well, we're also trying to build something practical here.  It's all well and good to write up requirements: I certainly have done it many times myself and expect to participate in work of this type in LISP.
However,   I'm also trying to be practical in a number of ways:

* I'm guessing some of the results of the security analysis--I'm guessing we're going to decide that mapping integrity is the big deal for a mapping system.
* I'm guessing that designing a PKI  for a mapping system may be out of scope for our current efforts
* I'm guessing that mandatory-to-use PKIs will not gain consensus in this WG (I doubt I'd support them and I'm fairly pro-security for our population)
* However, we need to make sure that absent such a PKI, the mapping system is not worse than today's internet.

I don't see how to deal with the last point without getting into the details of alt.
Remember also that we're trying to run experiments.

* I want to get to a point where I know if alt is secure enough that I'm willing to run my day-to-day traffic over it.  I understand some people do, but I need to understand its security properties before I will.
* We want to make sure that our experimental results are useful.  That means we need our security mechanisms present at least enough to understand their performance impact etc.

So, I think we need to dig into the details of alt a bit.  Not to develop requirements, but 
1) to understand whether alt meets the requirements we do develop
2)  to  make it good enough for the experiments.

Finally, I think I need to motivate my list of threats.
I think I should have to answer the question of "why isn't this a problem on the Internet today?"

---

From: Sam Hartman <[email-masked]>
Date: Fri, 09 Oct 2009 17:04:57 -0400

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.