Dear Ahmad, Thank you so much for your comments.
>SEND already offers what you are looking for. It has the Timestamp and the Signature options which are attached to the DNP messages. As I explained in my last email to Jeremy, It just updates SEND and does not replace it. It updates SEND because of the signature contents. I also explained in the draft that we used the same timestamp as is used in SEND. >I agree with the claim that CGA is compute intensive, but one can use Sec=0 or 1. In this case the computation of the CGA (SEND) would be equivalent to the complexity of your approach. I compared it with both sec value 0 and sec value 1. I did not consider sec value higher because it is not really feasible in practice that someone wait for 2 or 3 hours to days to generate an address. CGA for 1 it is 600 times more. For zero it is about 10 to 20 times more. The computation of this algorithm is faster than that for CGA and also the verification process is much faster. In the verification process you do not need to do all the CGA generation processing in reverse in order to verify it. With CGA you also have to include the verification time for the signature even though we say we use a sec value of 0 this is not considered in the verification process. For CGA you also need to include an extra 17 bytes of options (modifier and collision count) in the packet, but with SSAS the packet size would be less. Thank you, Hosnieh -----Original Message----- From: Al-Sadeh, Ahmad [mailto:ahmad.alsa...@hpi.uni-potsdam.de] Sent: Sunday, January 06, 2013 9:10 PM To: Hosnieh Rafiee; cga-...@ietf.org Cc: ipv6@ietf.org Subject: RE: [CGA-EXT] Call for comments on draft-rafiee-6man-ssas-00.txt Hosnieh, I have read your draft. And I have the following comments. SEND already offers what you are looking for. It has the Timestamp and the Signature options which are attached to the DNP messages. So, the new benefits of your approach are not clear to me. I agree with the claim that CGA is compute intensive, but one can use Sec=0 or 1. In this case the computation of the CGA (SEND) would be equivalent to the complexity of your approach. Therefore the enhancements that are proposed to protect the user privacy by setting a lifetime for the generated address (e.g. 2 days) or generating the key pairs by CGA code can be directly applied to the CGA and SEND implementation without significant change to proposed standard. In Section 5, ". it provides proof of address ownership at a speed that is about 600 times faster than that of the CGA algorithm." For which Sec value this comparison was done? Regards, Ahmad AlSadeh ________________________________ From: cga-ext-boun...@ietf.org [cga-ext-boun...@ietf.org] On Behalf Of Hosnieh Rafiee [i...@rozanak.com] Sent: 04 January 2013 21:13 To: cga-...@ietf.org Subject: [CGA-EXT] Call for comments on draft-rafiee-6man-ssas-00.txt 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 ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- _______________________________________________ CGA-EXT mailing list cga-...@ietf.org https://www.ietf.org/mailman/listinfo/cga-ext -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
