I have read this draft. Following all IMVHO.
The claim in Section 3.1 that replay attacks are avoided by having a timestamp window of 10 minutes seems rather exaggerated. 10 minutes is an eternity in some computer networks. If I was an attacker, I would be happy to wait and detect the 10 minute window when I could cause disruption. That may be enough time to do serious damage in some systems. The claim in section 3.2 that DoS attacks are avoided by rate limiting NDP messages also seems rather exaggerated. How would a rate filter know in advance which messages to discard without processing all of the SSAS signatures? Overloading of the NDP mechanism could still potentially cause nodes to time out their caches, and/or prevent new peerings from forming. And including encryption in NDP may actually make it easier to overload the NDP process rather than harder (because the defender has to do relatively more work than the attacker in the situation where encryption is employed compared to if there was no encryption). The claim in the Security Considerations of /the probability of an attacker finding the same value is 0.00016, a very small value./ would seem to be a bit exaggerated. This seems to ignore birthday attacks. And especially since it appears from the text that the consequence of making this match is that the information leaked to the attacker directly relates to 32 bits of the private key. Is that a correct reading? There are many LANs containing many thousands of nodes, and as an attacker I'd be happy to passively monitor long term if it meant I could glean (significant portions of) one public key (that did not rotate very often and once discovered would potentially be extremely useful). The recommendation of a /maximum of 2 days/ for public key times ignores the practical need in many systems for very long lived sessions, and the difficulty of securely rotating public keys on distributed systems. In summary, I am currently unconvinced whether this ID as it stands significantly moves the state of the art forward compared to existing mechanisms. regards, RayH Hosnieh Rafiee wrote: > Dear All, > > This draft addresses the following problem: > Unfortunately the existing drafts do not consider the integration of security > and privacy for the generation of the Interface ID (IID). This draft tries > to offer a solution to this problem while at the same time considering the > generation and verification times and complexity of the existing algorithms. > Please take a look. Comments are greatly appreciated. > Thank you, > Hosnieh > > > > Filename: draft-rafiee-6man-ssas > Revision: 00 > Title: A Simple Secure Addressing Generation Scheme for IPv6 > AutoConfiguration (SSAS) > Creation date: 2013-01-02 > WG ID: Individual Submission > Number of pages: 13 > URL: > http://www.ietf.org/internet-drafts/draft-rafiee-6man-ssas-00.txt > Status: http://datatracker.ietf.org/doc/draft-rafiee-6man-ssas > Htmlized: http://tools.ietf.org/html/draft-rafiee-6man-ssas-00 > > > Abstract: > The default method for IPv6 address generation uses two unique > manufacturer IDs that are assigned by the IEEE Standards Association > [1] (section 2.5.1 RFC-4291) [RFC4291]. This means that a node will > always have the same Interface ID (IID) whenever it connects to a new > network. Because the node's IP address does not change, the node is > vulnerable to privacy related attacks. To address this issue, there > are currently two mechanisms in use to randomize the IID, > Cryptographically Generated Addresses (CGA) [RFC3972] and Privacy > Extension [RFC4941]. The problem with the former approach is the > computational cost involved for the IID generation. The problem with > the latter approach is that it lacks security. This document offers a > new algorithm for use in the generation of the IID while, at the same > time, securing the node against some types of attack, such as IP > spoofing. These attacks are prevented with the addition of a > signature to the Neighbor Discovery messages (NDP). > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
