Subject: [lisp] LISP Security WAS: intro & architecture drafts

From: Paul Vinciguerra <[email-masked]>
Date: Wed, 24 Oct 2012 10:52:37 +0000

My academic blood tells me that we should look at everything
and try to find magical solutions to protect everything. On the
other hand, the operations show that in security the best is
really the enemy of the good. So we have to find a trade-off
between best and good.

Damien Saucez

Hi Damian,

I read your security document after your emails yesterday, and was hoping I could get you to address your thoughts on the best practical security measures.  Without offering an opinion as to the ease of the exploit and the scope of the impact or failure, it becomes hard to determine resources need to allocated to any sort of mitigation.

The single largest risk I took away from your document is the need to protect against spoofing. The second risk, resource starvation, seemed to stem largely from spoofing as well.

It seems to me that the largest problem in terms of addressing many of the issues in your document is that the protocol relies on UDP for transport and while that is a plus for the protocol, it makes security more difficult.  This makes ACL's only marginally useful since UDP is by its nature, so easy to spoof.

You offered up a new type of ACL based on the map cache, specifically for transit through the PxTR.  I agree that its value is to protect against provider theft of service, but the value of ACL's seem to be of limited use because of the use of UDP.  

The only solution that seems to address the spoof-ability of the transport is to provide some type of authentication within the packet.  I also think that if the nonce were not defined as a random packet, but as a key that is generated based on the mapping system being a trusted third party, the spoofing risks could be minimized.  Something similar and lighter that LISP-SEC, but for xTR-xTR communication.

But this would all be future work.

I would be interested in your thoughts on specific configuration options available today and their impact on security.  For example, you discuss gleaning to an extent and the risk it bears.  I am not aware of any option to disable it, so separation of xTR and iTR, for the time being could be step to mitigate that risk.  Enabling RLOC probing may be another tool.

Thanks,

Paul

---

From: Damien Saucez <[email-masked]>
Date: Wed, 24 Oct 2012 14:40:07 +0200

Hello,

> The single largest risk I took away from your document is the need to protect against spoofing. The second risk, resource starvation, seemed to stem largely from spoofing as well.

you are right, protection against spoofing might help a lot.

> It seems to me that the largest problem in terms of addressing many of the issues in your document is that the protocol relies on UDP for transport and while that is a plus for the protocol, it mak…

yes, as opposed to TCP where we can do some pre-verification during the 3 whs.

> You offered up a new type of ACL based on the map cache, specifically for transit through the PxTR.  I agree that its value is to protect against provider theft of service, but the value of ACL's s…

agree
> The only solution that seems to address the spoof-ability of the transport is to provide some type of authentication within the packet.  I also think that if the nonce were not defined as a random…

I remember we looked at this for a while, but the nature of data plane packet is such that it
is probably hard to do it. Mainly for two reasons. First, because the number of bits is limited
so replay attacks are easy; second it is not sure that at very high rate it is easy to do this
kind of signature. There is some early discussion in draft-saucez-lisp-mapping-security for
the control-plane.

I think that if we manage to secure the control plane, almost everything is done. Indeed, the
security issues from the data plane mostly come from optimisations (LSB, echo-noncing,
gleaning) that can be ignored in critical environments.

> I would be interested in your thoughts on specific configuration options available today and their impact on security.  For example, you discuss gleaning to an extent and the risk it bears.  I am n…

Good question, the best is to wait the answer from the Cisco teams. In OpenLISP, there
is no such thing as gleaning.

Damien Saucez