Hello, On 24 Oct 2012, at 12:52, Paul Vinciguerra <[email protected]> wrote:
> > > 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. 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 makes security more difficult. > This makes ACL's only marginally useful since UDP is by its nature, so easy > to spoof. 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 seem to be of limited use > because of the use of UDP. 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 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. > 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. > 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. Good question, the best is to wait the answer from the Cisco teams. In OpenLISP, there is no such thing as gleaning. Damien Saucez > > Thanks, > > Paul > > > > > > > > > > > > > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
