Re: [CGA-EXT] CGA-EXT Digest, Vol 47, Issue 2

"Hosnieh Rafiee" <ietf@rozanak.com> Sun, 06 January 2013 20:40 UTC

Return-Path: <ietf@rozanak.com>
X-Original-To: cga-ext@ietfa.amsl.com
Delivered-To: cga-ext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5FA21F853E for <cga-ext@ietfa.amsl.com>; Sun, 6 Jan 2013 12:40:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.456
X-Spam-Level:
X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRoQ+EPWVrI2 for <cga-ext@ietfa.amsl.com>; Sun, 6 Jan 2013 12:40:22 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 215A121F84BB for <cga-ext@ietf.org>; Sun, 6 Jan 2013 12:40:22 -0800 (PST)
Received: from kopoli (g225033246.adsl.alicedsl.de [92.225.33.246]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0Le5vo-1TD70f3LUy-00pnnh; Sun, 06 Jan 2013 15:40:21 -0500
From: "Hosnieh Rafiee" <ietf@rozanak.com>
To: <cga-ext@ietf.org>
References: <mailman.6716.1357502970.3374.cga-ext@ietf.org>
In-Reply-To: <mailman.6716.1357502970.3374.cga-ext@ietf.org>
Date: Sun, 6 Jan 2013 21:40:12 +0100
Message-ID: <000701cdec4e$0a6cd040$1f4670c0$@rozanak.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJ8yJBoNjjL67lO6xYHS3PvKMAFbJbfCspg
Content-Language: en-us
X-Provags-ID: V02:K0:iyqwqjIO2woDeqElZL0onJGVpugWmT/fG+ik2+IP6m0 vUDSaJ3vOitOFcT/+XzrNyTD87uEAxnS41ZWRfk1AyqDxqFFR7 QYPX6IOKUazqRz4CVrfZSU1Kv4GK6D9M5XsHW04ZbFK23veQPZ I/MgoFBI2GB7E2yNHYNYrwyECtcZTxwYyf7Dm+IguqJrBMm8is lBZVa4HuhKCY4YCo2yw8YmcsXt78SCE9ucFb4a6a8nLIBYRCIW JjhBW9IZ7jg5r2pKpupSevpcaQQnd+C5yIh4wnu/4AnC6LVIIZ JDRsdin+oeavWNrlJ8nWSqqCrLmE9UaC3EgA+P9U7BMM4N7xZm ZOAXtKlG6d9xMxo9wTus=
Subject: Re: [CGA-EXT] CGA-EXT Digest, Vol 47, Issue 2
X-BeenThere: cga-ext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: CGA and SeND Extensions <cga-ext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cga-ext>
List-Post: <mailto:cga-ext@ietf.org>
List-Help: <mailto:cga-ext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Jan 2013 20:40:23 -0000

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: cga-ext-bounces@ietf.org [mailto:cga-ext-bounces@ietf.org] On Behalf
Of cga-ext-request@ietf.org
Sent: Sunday, January 06, 2013 9:10 PM
To: cga-ext@ietf.org
Subject: CGA-EXT Digest, Vol 47, Issue 2

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/cga-ext

Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or
Plain Text Digests?" to MIME.  You can set this option globally for all the
list digests you receive at this point.



Send CGA-EXT mailing list submissions to
	cga-ext@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/cga-ext
or, via email, send a message with subject or body 'help' to
	cga-ext-request@ietf.org

You can reach the person managing the list at
	cga-ext-owner@ietf.org

When replying, please edit your Subject line so it is more specific than
"Re: Contents of CGA-EXT digest..."


Today's Topics:

   1. Re:  Call for comments on draft-rafiee-6man-ssas-00.txt
      (Al-Sadeh, Ahmad)


----------------------------------------------------------------------

Message: 1
Date: Sun, 6 Jan 2013 21:09:53 +0100
From: "Al-Sadeh, Ahmad" <Ahmad.AlSadeh@hpi.uni-potsdam.de>;
To: Hosnieh Rafiee <ietf@rozanak.com>;, "cga-ext@ietf.org";
	<cga-ext@ietf.org>;
Cc: "ipv6@ietf.org"; <ipv6@ietf.org>;
Subject: Re: [CGA-EXT] Call for comments on
	draft-rafiee-6man-ssas-00.txt
Message-ID: <BB4E1F8A-2971-4648-82E4-3A34DBE777A5@mimectl>
Content-Type: text/plain; charset="Windows-1252"

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-bounces@ietf.org [cga-ext-bounces@ietf.org] On Behalf Of
Hosnieh Rafiee [ietf@rozanak.com]
Sent: 04 January 2013 21:13
To: cga-ext@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-EXT@ietf.org
https://www.ietf.org/mailman/listinfo/cga-ext


------------------------------

_______________________________________________
CGA-EXT mailing list
CGA-EXT@ietf.org
https://www.ietf.org/mailman/listinfo/cga-ext


End of CGA-EXT Digest, Vol 47, Issue 2
**************************************