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 _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
