As you can see the latest version of the SSAS draft (version 3) has been successfully applied to the IETF repository. I want to thank all of you who reviewed the prior version and proffered comments. I included the information from those comments in version 3. A brief synopsis of the changes contained in version 3 are as follow: - correct the spelling error and typos (hopefully no new ones were inserted in this version) - extended this draft to include devices using Mobile nodes for the secure configuration of CoA using ND. Also included nodes with limited resources, such as 6LoWPAN, which can make use of SSAS as a security mechanism during address configuration using ND and car to car networks. - Explained the differences between mechanisms used in this draft with current mechanisms in use today. - Improved the SSAS algorithm and classified it into two different uses: observing both security and privacy and just observing privacy
Please review this latest version to ensure that I haven't missed anything. I always welcome your comments which enable me to improve it more. I would also like to present it, informally, to anybody who is interested in ND security. I will do this tomorrow (Tuesday) at 12:15 in Grand Sierra D (IETF lounge) and then formally on Friday, in the 6man session, if time permits as I am an "if time permits" person. Thank you, Hosnieh Filename: draft-rafiee-6man-ssas Revision: 03 Title: A Simple Secure Addressing Generation Scheme for IPv6 AutoConfiguration (SSAS) Creation date: 2013-03-11 Group: Individual Submission Number of pages: 17 URL: http://www.ietf.org/internet-drafts/draft-rafiee-6man-ssas-03.txt Status: http://datatracker.ietf.org/doc/draft-rafiee-6man-ssas Htmlized: http://tools.ietf.org/html/draft-rafiee-6man-ssas-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-rafiee-6man-ssas-03 Abstract: The default method for IPv6 address generation uses an Organizationally Unique Identifier (OUI) assigned by the IEEE Standards Association and an Extension Identifier assigned to the hardware manufacturer [1] (section 2.5.1 RFC-4291) [RFC4291]. This fact thus 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 will be vulnerable to privacy related attacks. Currently this problem is addressed by the use of two mechanisms that do not make use of the MAC address, or other unique values that can be used for ID generation, for randomizing 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 and in the verification process. The problem with the latter approach is that it lacks necessary security mechanisms and provides the node with only partial protection against privacy related attacks. This document proposes the use of a new algorithm for use in the generation of the IID while, at the same time, securing the node against some types of attack, like IP spoofing. These attacks are prevented by the addition of a signature to messages sent over the network and by direct use of a public key in the IP address. The IETF Secretariat -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
