[CGA-EXT] Call for comments on draft-rafiee-6man-ssas-01.txt

"Hosnieh Rafiee" <ietf@rozanak.com> Mon, 21 January 2013 23:56 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 A27DB21F8853; Mon, 21 Jan 2013 15:56:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 rYUna4YRuzZS; Mon, 21 Jan 2013 15:56:38 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3CF21F884C; Mon, 21 Jan 2013 15:56:38 -0800 (PST)
Received: from kopoli (g225040193.adsl.alicedsl.de [92.225.40.193]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LmK8A-1TOede3lOE-00ZGkh; Mon, 21 Jan 2013 18:56:34 -0500
From: Hosnieh Rafiee <ietf@rozanak.com>
To: Ray Hunter <v6ops@globis.net>, "'Duncan, Richard (Jeremy)'" <jeremy.duncan@salientfed.com>, Fernando Gont <fgont@si6networks.com>, "'Al-Sadeh, Ahmad'" <Ahmad.AlSadeh@hpi.uni-potsdam.de>, "Roque Gagliano (rogaglia)" <rogaglia@cisco.com>
Date: Tue, 22 Jan 2013 00:56:20 +0100
Message-ID: <000101cdf832$ef9b5480$ced1fd80$@rozanak.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac34Mm/A07P7NjLJTCeC5Jyh13oWOQ==
Content-Language: en-us
X-Provags-ID: V02:K0:193UQz0g5JUVYzdnRWWwmMB0RNWDFMfWcvl8OXvzW6Q hry2C+rOBHaGQzXuy51Q2EWoHtZafYgjEnwykTEjOufnneUk9x wlNGVwukb18Wc9zb/b7iT/2vRmGKaWPCA/WlABFVblCAkZjoCD 7TGpVMMqMmfw7AyMIqrGCAPoVqfDlF4jxzWFAR7q5S7RWPU+5f EL1jACiV7NrhVMjB/2FrY45C8x9lM//458pAOB2fbvpgnr2U67 wfXVvqgfnMn2IEWl3/lbSdUQF6VNJ0HYuNG0Usgd+72nNGjRfu IEnvpp23YA7wX6smyB4sQqk/oLY8ceERW/okruIfYoNDUgmQB3 hs1WwL3AIwAdA5h+wM9I=
Cc: cga-ext@ietf.org, ipv6@ietf.org
Subject: [CGA-EXT] Call for comments on draft-rafiee-6man-ssas-01.txt
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: Mon, 21 Jan 2013 23:56:38 -0000

Dear all,

I have considered your comments and updated our draft rfc accordingly. Feel free to add further comments.

Thank you,
Hosnieh



Filename:	 draft-rafiee-6man-ssas
Revision:	 01
Title:		 A Simple Secure Addressing Generation Scheme for IPv6 AutoConfiguration (SSAS)
Creation date:	 2013-01-21
WG ID:		 Individual Submission
Number of pages: 15
URL:             http://www.ietf.org/internet-drafts/draft-rafiee-6man-ssas-01.txt
Status:          http://datatracker.ietf.org/doc/draft-rafiee-6man-ssas
Htmlized:        http://tools.ietf.org/html/draft-rafiee-6man-ssas-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-rafiee-6man-ssas-01

Abstract:
   The default method for IPv6 address generation uses a organitionally
   unique identifier assigned by the IEEE Standards Association and the
   extension identifier by the hardware manufacturer [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 and verification. The problem with the latter
   approach is that it lacks security and offers only partial protection
   to the node against privacy related attacks. 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, like IP
   spoofing. These attacks are prevented by the addition of a signature
   to the messages sent over the network and by directly using a public
   key in the IP address.



                                                                                  


The IETF Secretariat