From ietf@rozanak.com Fri Jan 4 12:13:40 2013 Return-Path: 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 E08B021F8A42 for ; Fri, 4 Jan 2013 12:13:40 -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 BpVODarVUlOx for ; Fri, 4 Jan 2013 12:13:36 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id C665421F8A45 for ; Fri, 4 Jan 2013 12:13:36 -0800 (PST) Received: from kopoli (g225038076.adsl.alicedsl.de [92.225.38.76]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LcjIF-1T7OMZ32e7-00jzq0; Fri, 04 Jan 2013 15:13:30 -0500 From: "Hosnieh Rafiee" To: References: <000001cdea08$1a37e0c0$4ea7a240$@rozanak.com> In-Reply-To: <000001cdea08$1a37e0c0$4ea7a240$@rozanak.com> Date: Fri, 4 Jan 2013 21:13:25 +0100 Message-ID: <000d01cdeab7$f627a340$e276e9c0$@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: AQI7ECCw5lZJtuTcH4KW/U5riPTnyZdfT5EQ Content-Language: en-us X-Provags-ID: V02:K0:MEOYiS58rx1TT+LyZPgMreAkMX0bhFmAlrug8Gyc3Hu v6vjIasO6jpQpbS5c2xML6ENg0Xv5TBkNWVZQEn7LEp6AvQj59 jWkr5X2mM+pAP1tWCgjQsU4za6AFB+06hobeg5Bxpwvpn1j+G4 xmrTqGnP/Z6YlXHoMBtrARAaXTkAUP5dLMs8TjSGLPoBExQowd XIkixsy9oKGMDDNMhHKtkM3uzM97FT72nxDt3Z8crOQ7XsMNNE 0JYtihqB2sFQX3KpQrHeEizuxi9t8fIQhpcn/k0kY9PaxFPSnr sFy4NzGQi9Pobl0smeGVeR+AuEKXyWQma595Nsuypgv0k3d1h9 L1qkQirLKcaySi+Psbqo= Subject: [CGA-EXT] Call for comments on draft-rafiee-6man-ssas-00.txt X-BeenThere: cga-ext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 20:13:41 -0000 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 -------------------------------------------------------------------- From Ahmad.AlSadeh@hpi.uni-potsdam.de Sun Jan 6 12:09:29 2013 Return-Path: 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 CCB4E21F859C; Sun, 6 Jan 2013 12:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 vmdslolbzLEW; Sun, 6 Jan 2013 12:09:29 -0800 (PST) Received: from mail2.hpi.uni-potsdam.de (mail2.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17a]) by ietfa.amsl.com (Postfix) with ESMTP id EBE5B21F859B; Sun, 6 Jan 2013 12:09:28 -0800 (PST) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail2.hpi.uni-potsdam.de (Postfix) with ESMTP id 0EA5CD2C8E; Sun, 6 Jan 2013 21:09:26 +0100 (CET) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Sun, 6 Jan 2013 21:09:25 +0100 From: "Al-Sadeh, Ahmad" To: Hosnieh Rafiee , "cga-ext@ietf.org" Content-Class: urn:content-classes:message Date: Sun, 6 Jan 2013 21:09:53 +0100 Thread-Topic: [CGA-EXT] Call for comments on draft-rafiee-6man-ssas-00.txt Thread-Index: AQI7ECCw5lZJtuTcH4KW/U5riPTnyZdfT5EQgAMhrjeAAAIU+A== Message-ID: References: <000001cdea08$1a37e0c0$4ea7a240$@rozanak.com>, <000d01cdeab7$f627a340$e276e9c0$@rozanak.com> In-Reply-To: <000d01cdeab7$f627a340$e276e9c0$@rozanak.com> Accept-Language: en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-GB x-mimectl: Produced By Microsoft Exchange V8.3.105.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipv6@ietf.org" Subject: Re: [CGA-EXT] Call for comments on draft-rafiee-6man-ssas-00.txt X-BeenThere: cga-ext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 20:09:29 -0000 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 benef= its of your approach are not clear to me. I agree with the claim that CGA is compute intensive, but one can use Sec= =3D0 or 1. In this case the computation of the CGA (SEND) would be equivale= nt to the complexity of your approach. Therefore the enhancements that are= proposed to protect the user privacy by setting a lifetime for the generat= ed address (e.g. 2 days) or generating the key pairs by CGA code can be dir= ectly applied to the CGA and SEND implementation without significant change= to proposed standard. In Section 5, =93=85 it provides proof of address ownership at a speed that= is about 600 times faster than that of the CGA algorithm.=94 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 Hosn= ieh 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 From ietf@rozanak.com Sun Jan 6 12:40:23 2013 Return-Path: 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 ; 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 ; 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 ; 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" To: References: In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" To: Hosnieh Rafiee , "cga-ext@ietf.org" Cc: "ipv6@ietf.org" Subject: Re: [CGA-EXT] Call for comments on draft-rafiee-6man-ssas-00.txt Message-ID: 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 ************************************** From rogaglia@cisco.com Mon Jan 7 01:40:56 2013 Return-Path: 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 C67DF21F88B9 for ; Mon, 7 Jan 2013 01:40:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 C0FPPRFSJxd4 for ; Mon, 7 Jan 2013 01:40:55 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2C21121F869C for ; Mon, 7 Jan 2013 01:40:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8713; q=dns/txt; s=iport; t=1357551655; x=1358761255; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=xNDak5k6JYRL5m+D8pe2qDPVoAoMXMG/B8H2k9edheo=; b=Q1HGxr7S50sqEviC81oRt2KxJrbPVu5wXL9lp3DRaZft5RLRv8c1RgVo ym2PdUNYO7L0heVBBB+bJSZm7j/kJeIU0MEET1QqQcWMAw3ByIKUXIJbS KIplD0PFYbZG4/zpnuVGQpHca/lEwVdcHxTqNqaCiMu7ef/s73qn1OMic E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAPGW6lCtJXHA/2dsb2JhbABFvVIWc4IeAQEBAwEBAQEaHRQgCwUHBAIBCA4DAwEBAQsCAREJBycKARQJCAIEDgUIARICBIdwBgy2TIxdg1dhA5JYhE+PLYJ0gWgHAhce X-IronPort-AV: E=Sophos;i="4.84,423,1355097600"; d="scan'208";a="159549167" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 07 Jan 2013 09:40:54 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r079esFw025092 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Jan 2013 09:40:54 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.144]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Mon, 7 Jan 2013 03:40:54 -0600 From: "Roque Gagliano (rogaglia)" To: Hosnieh Rafiee Thread-Topic: [CGA-EXT] CGA-EXT Digest, Vol 47, Issue 2 Thread-Index: AQHN7LsVoJaiGOKzT0iV+Q/2cgoQDw== Date: Mon, 7 Jan 2013 09:40:53 +0000 Message-ID: References: <000701cdec4e$0a6cd040$1f4670c0$@rozanak.com> In-Reply-To: <000701cdec4e$0a6cd040$1f4670c0$@rozanak.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.19.46] Content-Type: text/plain; charset="us-ascii" Content-ID: <8AD42A01694FA64EB07D51AB7F1B90B9@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 09:40:56 -0000 Hosnieh, I have some comments: - Why this is an important problem to be addressed is not clear in the text= other than saying "CGA are computing intensive", which is arguable dependi= ng on network sizes and equipment=20 - You need to add text to the document on where the improvement resides. Yo= u mentioned something on the answer to Ahmad but that is still not convinci= ng. - You mention that the strength of your algorithm requires that the key pai= r needs to be changed every 2 days. In the case you are using SEND, this me= ans generating new certificates for every node every 2 days. This seams lik= e a non-starter IMHO. - Please include the reference to your studies instead of saying "Our exper= imental results show a definite improvement ". BTW, there other proposals for privacy extensions today that you should men= tion: https://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-= 02 Roque. On Jan 6, 2013, at 9:40 PM, Hosnieh Rafiee wrote: > Dear Ahmad, >=20 > Thank you so much for your comments.=20 >=20 >> SEND already offers what you are looking for. It has the Timestamp and t= he > Signature options which are attached to the DNP messages. >=20 > 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= . >=20 >> I agree with the claim that CGA is compute intensive, but one can use Se= c=3D0 > or 1. In this case the computation of the CGA (SEND) would be equivalent = to > the complexity of your approach. =20 > I compared it with both sec value 0 and sec value 1. I did not consider s= ec > value higher because it is not really feasible in practice that someone w= ait > for 2 or 3 hours to days to generate an address. CGA for 1 it is 600 time= s > more. For zero it is about 10 to 20 times more.=20 >=20 > The computation of this algorithm is faster than that for CGA and also th= e > verification process is much faster. In the verification process you do n= ot > need to do all the CGA generation processing in reverse in order to verif= y > 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 consider= ed > 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 S= SAS > the packet size would be less.=20 >=20 > Thank you, > Hosnieh >=20 > -----Original Message----- > From: cga-ext-bounces@ietf.org [mailto:cga-ext-bounces@ietf.org] On Behal= f > 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 >=20 > 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=20 >=20 > https://www.ietf.org/mailman/listinfo/cga-ext >=20 > 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 t= he > list digests you receive at this point. >=20 >=20 >=20 > Send CGA-EXT mailing list submissions to > cga-ext@ietf.org >=20 > 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 >=20 > You can reach the person managing the list at > cga-ext-owner@ietf.org >=20 > When replying, please edit your Subject line so it is more specific than > "Re: Contents of CGA-EXT digest..." >=20 >=20 > Today's Topics: >=20 > 1. Re: Call for comments on draft-rafiee-6man-ssas-00.txt > (Al-Sadeh, Ahmad) >=20 >=20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Sun, 6 Jan 2013 21:09:53 +0100 > From: "Al-Sadeh, Ahmad" > To: Hosnieh Rafiee , "cga-ext@ietf.org" > > Cc: "ipv6@ietf.org" > Subject: Re: [CGA-EXT] Call for comments on > draft-rafiee-6man-ssas-00.txt > Message-ID: > Content-Type: text/plain; charset=3D"Windows-1252" >=20 > 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 th= e > 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= =3D0 > 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 genera= ted > 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 i= s > about 600 times faster than that of the CGA algorithm.? > For which Sec value this comparison was done? > Regards, > Ahmad AlSadeh >=20 > ________________________________ > 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 >=20 >=20 > Dear All, >=20 > 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 >=20 >=20 >=20 > 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 >=20 >=20 > 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). >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 > _______________________________________________ > CGA-EXT mailing list > CGA-EXT@ietf.org > https://www.ietf.org/mailman/listinfo/cga-ext >=20 >=20 > ------------------------------ >=20 > _______________________________________________ > CGA-EXT mailing list > CGA-EXT@ietf.org > https://www.ietf.org/mailman/listinfo/cga-ext >=20 >=20 > End of CGA-EXT Digest, Vol 47, Issue 2 > ************************************** >=20 > _______________________________________________ > CGA-EXT mailing list > CGA-EXT@ietf.org > https://www.ietf.org/mailman/listinfo/cga-ext From ietf@rozanak.com Mon Jan 7 08:05:39 2013 Return-Path: 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 2E65F21F8931 for ; Mon, 7 Jan 2013 08:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 bATAKqD7EaM0 for ; Mon, 7 Jan 2013 08:05:37 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1D221F8732 for ; Mon, 7 Jan 2013 08:05:34 -0800 (PST) Received: from oxuslxltgw01.lxa.perfora.net (oxuslxltgw01.lxa.perfora.net [172.19.206.16]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0M87jd-1T5tsZ2RtZ-00vJgY; Mon, 07 Jan 2013 11:05:30 -0500 Date: Mon, 7 Jan 2013 11:05:30 -0500 (EST) From: Hosnieh To: "Roque Gagliano (rogaglia)" Message-ID: <614007519.821132.1357574730593.JavaMail.open-xchange@email.1and1.com> In-Reply-To: References: <000701cdec4e$0a6cd040$1f4670c0$@rozanak.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_821131_859078821.1357574730523" X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v6.20.7-Rev4 X-Provags-ID: V02:K0:uxj7/d9jupD0do3qwti5KyBdQLLWZPWbU8BHKLvwLVl fw3D12xR6eWmkNiAm3eQzqeoVd45cyQyI+DK21YOPYcyIMhsbT RqI58NZuLNYQTrGKfEyjQ02jhk4oUfjPBp6bT1yXLB/lg/SWvk CNGyjAGtoF6paRDe1ko+e81zfV/M2+W3YdouA0Lhx/5sOSTQh0 MgMn6klctGOID3hZn3EzHsncRWXprFUbL/q6F1CKyS1Bz/WmCm BnlTo7lC6lJ12X8uf1pWDKJ5KUDqv9U0OcXjbMYh5umra8hohr dpH8lVr444OLt5zO2trSSd16YPOX2Z6LY5vq/a8PdVsqMmNJf5 kbaZTGPbc9zY7KcNQ19qeWGSsjK5uAf/HjI19VDCKDeznmK4Ro 4kjRNy1ES7vuDOHADJv8CvfpseoqooiBeek4AFyRjhJmOyj9rP gQXCQ1ZNbSwN1NW96Y479BDZ78g== Cc: "" 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 Reply-To: Hosnieh List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 16:05:39 -0000 ------=_Part_821131_859078821.1357574730523 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Dear Rogue, Thank you for your comments and questions. > Why this is an important problem to be addressed is not clear in the text > other than saying "CGA are computing intensive", which is arguable depending > on network sizes and equipment The problem is one of privacy. Addresses need to change in order to protect privacy. In this vain it then becomes beneficial and important to be able to generate the IID more quickly. For nodes in the network it is enough to use SSAS without thinking about the use of certificates because that is all that is needed to prove address ownership. At the same time, it is recommended to use vehicles outlined in other RFCs to prevent all nodes from claiming to be a router. > You need to add text to the document on where the improvement resides. You > mentioned something on the answer to Ahmad but that is still not convincing. So being able to generate the address faster along with reducing the verification time does not convince you? It is already a given that the use of CGA for a sec value over 1 is not feasible. Even when using a sec value of 0 the verification time using CGA is much higher than that for SSAS. The conclusion drawn from this is that, in the event of DoS attacks, SSAS enable nodes have the ability to process more packets per minute than do those using CGA. > You mention that the strength of your algorithm requires that the key pair > needs to be changed every 2 days. In the case you are using SEND, this means > generating new certificates for every node every >2 days. This seems like a > non-starter IMHO As I explained in my answer to Ray in 6man WG, 2 days is just recommendation. If one uses 20 days the probability is still low. Now let's explain the problem from different aspects, i.e., internal network and external network. Internal network: We can provide privacy in layer 3. For privacy in layer 2, there is also a need to have a dynamic MAC address (this is explained in another paper that is under publication) from which we generate the address by using a kind of hashing algorithm, like SHA256. This is especially feasible in cloud networks where virtual machines are used. Using temporary keys and IP addresses would provide privacy in layer 3. We also provide security for this network by preventing DAD and IP stealing attacks. One thing that is missing in my draft, which I will correct, is how to avoid spoofed MAC address attacks. In this case, we also need to include the MAC address in the signature so that, if the verification process fails, the message is discarded by the node that should redirect this message. External network: Changing router prefixes (now done in some countries) and the IID would provide the privacy needed for this node in layer 3. But for upper layers, there are a lot of different approaches available: far too numerous to explain them here. Another thing is that router nodes do not necessarily require the use of certification because, for a node in local network, it is important that they be able to generate their IP address so that nobody can steal their address and this is also true routers as well. Finally, the reason for recommending that key pairs be generated with the generation of a new IP address is that this eliminates the chance of a node being tracked based on its public key in layer 3 of internal networks and in external networks (eliminates the chance of privacy attacks). > Please include the reference to your studies instead of saying "Our > experimental results show a definite improvement ". Our research in this area is about to be published. I can upload the results of our research to our website and refer you to that. (I will add the reference to the draft after the it published and appears online) Thank you, Hosnieh On January 7, 2013 at 4:40 AM "Roque Gagliano (rogaglia)" wrote: > Hosnieh, > > I have some comments: > - Why this is an important problem to be addressed is not clear in the text > other than saying "CGA are computing intensive", which is arguable depending > on network sizes and equipment > - You need to add text to the document on where the improvement resides. You > mentioned something on the answer to Ahmad but that is still not convincing. > - You mention that the strength of your algorithm requires that the key pair > needs to be changed every 2 days. In the case you are using SEND, this means > generating new certificates for every node every 2 days. This seams like a > non-starter IMHO. > - Please include the reference to your studies instead of saying "Our > experimental results show a definite improvement ". > > BTW, there other proposals for privacy extensions today that you should > mention: > https://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-02 > > Roque. > > On Jan 6, 2013, at 9:40 PM, Hosnieh Rafiee wrote: > > > 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" > > To: Hosnieh Rafiee , "cga-ext@ietf.org" > > > > Cc: "ipv6@ietf.org" > > Subject: Re: [CGA-EXT] Call for comments on > > draft-rafiee-6man-ssas-00.txt > > Message-ID: > > 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 > > ************************************** > > > > _______________________________________________ > > CGA-EXT mailing list > > CGA-EXT@ietf.org > > https://www.ietf.org/mailman/listinfo/cga-ext > ------=_Part_821131_859078821.1357574730523 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
 

Dear Rogue,

Thank you for your comments and questions.

 

> Why this is an important problem to be addressed is not clear in the text other than saying "CGA are computing intensive", which is arguable depending on network sizes and equipment

 

The problem is one of privacy. Addresses need to change in order to protect privacy. In this vain it then becomes beneficial and important to be able to generate the IID more quickly. For nodes in the network it is enough to use SSAS without thinking about the use of certificates because that is all that is needed to prove address ownership. At the same time, it is recommended to use vehicles outlined in other RFCs to prevent all nodes from claiming to be a router.

 

> You need to add text to the document on where the improvement resides. You mentioned something on the answer to Ahmad but that is still not convincing.

 

So being able to generate the address faster along with reducing the verification time does not convince you? It is already a given that the use of CGA for a sec value over 1 is not feasible. Even when using a sec value of 0 the verification time using CGA is much higher than that for SSAS. The conclusion drawn from this is that, in the event of DoS attacks, SSAS enable nodes have the ability to process more packets per minute than do those using CGA.

 

> You mention that the strength of your algorithm requires that the key pair needs to be changed every 2 days. In the case you are using SEND, this means generating new certificates for every node every >2 days. This seems like a non-starter IMHO

 

As I explained in my answer to Ray in 6man WG, 2 days is just recommendation. If one uses 20 days the probability is still low. Now let's explain the problem from different aspects, i.e., internal network and external network.

Internal network:

We can provide privacy in layer 3. For privacy in layer 2, there is also a need to have a dynamic MAC address (this is explained in another paper that is under publication) from which we generate the address by using a kind of hashing algorithm, like SHA256. This is especially feasible in cloud networks where virtual machines are used. Using temporary keys and IP addresses would provide privacy in layer 3.

 We also provide security for this network by preventing DAD and IP stealing attacks.

One thing that is missing in my draft, which I will correct, is how to avoid spoofed MAC address attacks. In this case, we also need to include the MAC address in the signature so that, if the verification process fails, the message is discarded by the node that should redirect this message.

External network: 

Changing router prefixes (now done in some countries) and the IID would provide the privacy needed for this node in layer 3. But for upper layers, there are a lot of different approaches available: far too numerous to explain them here.

Another thing is that router nodes do not necessarily require the use of  certification because, for a node in local network, it is important that they be able to generate their IP address so that nobody can steal their address and this is also true routers as well. Finally, the reason for recommending that key pairs be generated with the generation of a new IP address is that this eliminates the chance of a node being tracked based on its public key in layer 3 of internal networks and in external networks (eliminates the chance of privacy attacks).

 

 

> Please include the reference to your studies instead of saying "Our experimental results show a definite improvement ".

 

Our research in this area is about to be published. I can upload the results of our research to our website and refer you to that. (I will add the reference to the draft after the it published and appears online)

 

Thank you,

Hosnieh

 

 


On January 7, 2013 at 4:40 AM "Roque Gagliano (rogaglia)" <rogaglia@cisco.com> wrote:
> Hosnieh,
>
> I have some comments:
> - Why this is an important problem to be addressed is not clear in the text other than saying "CGA are computing intensive", which is arguable depending on network sizes and equipment
> - You need to add text to the document on where the improvement resides. You mentioned something on the answer to Ahmad but that is still not convincing.
> - You mention that the strength of your algorithm requires that the key pair needs to be changed every 2 days. In the case you are using SEND, this means generating new certificates for every node every 2 days. This seams like a non-starter IMHO.
> - Please include the reference to your studies instead of saying "Our experimental results show a definite improvement ".
>
> BTW, there other proposals for privacy extensions today that you should mention: https://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-02
>
> Roque.
>
> On Jan 6, 2013, at 9:40 PM, Hosnieh Rafiee <ietf@rozanak.com> wrote:
>
> > 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
> > **************************************
> >
> > _______________________________________________
> > CGA-EXT mailing list
> > CGA-EXT@ietf.org
> > https://www.ietf.org/mailman/listinfo/cga-ext
>
------=_Part_821131_859078821.1357574730523-- From rogaglia@cisco.com Mon Jan 7 09:00:36 2013 Return-Path: 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 B7CDA21F84DB for ; Mon, 7 Jan 2013 09:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 xAKpjr-rW5go for ; Mon, 7 Jan 2013 09:00:34 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4C721F8910 for ; Mon, 7 Jan 2013 09:00:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33786; q=dns/txt; s=iport; t=1357578034; x=1358787634; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=IViKpYuotkh2gSociV8wJ8ZMO0a5GKabhT4N12sMTn4=; b=KlW5FiHkgOuzJZD9GLMwKB4qsaNCuWr3sWs36GEVxz6oMWfqmJ8a+T6x QKUEgw01sSVMB3TSOTmitb4MNlEG336Xyn3eBAnrdcPkpFPcnOrPQ8dPV Y9k1YBYMvdHOFwK0EWs8NDkJRdPPV7U3Oj79GdeAYaDQsEfvdukLK45+P 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtIFAJf+6lCtJV2d/2dsb2JhbABFqyuJCgGJHhZzgh4BAQEDAQEBARcDMSALBQcEAgEIEQMBAQEBCgIBEwcHJwoBFAkIAgQOBQgBEgIEh3AGDLVHjFQIAYNXYQOSHjqET48tgnSBaAcCFwQa X-IronPort-AV: E=Sophos;i="4.84,424,1355097600"; d="scan'208,217";a="159715725" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 07 Jan 2013 17:00:32 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r07H0Wan026133 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Jan 2013 17:00:32 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.194]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Mon, 7 Jan 2013 11:00:32 -0600 From: "Roque Gagliano (rogaglia)" To: Hosnieh Thread-Topic: [CGA-EXT] CGA-EXT Digest, Vol 47, Issue 2 Thread-Index: AQHN7LsVoJaiGOKzT0iV+Q/2cgoQDw== Date: Mon, 7 Jan 2013 17:00:31 +0000 Message-ID: References: <000701cdec4e$0a6cd040$1f4670c0$@rozanak.com> <614007519.821132.1357574730593.JavaMail.open-xchange@email.1and1.com> In-Reply-To: <614007519.821132.1357574730593.JavaMail.open-xchange@email.1and1.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.20.110] Content-Type: multipart/alternative; boundary="_000_EF4348D391D0334996EE9681630C83F02202AE93xmbalnx02ciscoc_" MIME-Version: 1.0 Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 17:00:36 -0000 --_000_EF4348D391D0334996EE9681630C83F02202AE93xmbalnx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hosnieh, On Jan 7, 2013, at 5:05 PM, Hosnieh > wrote: Dear Rogue, Thank you for your comments and questions. > Why this is an important problem to be addressed is not clear in the text= other than saying "CGA are computing intensive", which is arguable dependi= ng on network sizes and equipment The problem is one of privacy. Addresses need to change in order to protect= privacy. In this vain it then becomes beneficial and important to be able = to generate the IID more quickly. For nodes in the network it is enough to = use SSAS without thinking about the use of certificates because that is all= that is needed to prove address ownership. At the same time, it is recomme= nded to use vehicles outlined in other RFCs to prevent all nodes from claim= ing to be a router. So if the problem you want to solve is privacy, what is the big difference = between your proposal and changing a CGA by using a different modifier from= time to time? In your case you have a timestamp but the modifier can be ar= bitrary. > You need to add text to the document on where the improvement resides. Yo= u mentioned something on the answer to Ahmad but that is still not convinci= ng. So being able to generate the address faster along with reducing the verifi= cation time does not convince you? It is already a given that the use of CG= A for a sec value over 1 is not feasible. Even when using a sec value of 0 = the verification time using CGA is much higher than that for SSAS. The conc= lusion drawn from this is that, in the event of DoS attacks, SSAS enable no= des have the ability to process more packets per minute than do those using= CGA. What do you mean by packet per minutes? ND packets? new neighbours? old nei= ghbours that I already have in the cache? which L2 domain size? I think I w= ould expect these sort of data to backup your comments. > You mention that the strength of your algorithm requires that the key pai= r needs to be changed every 2 days. In the case you are using SEND, this me= ans generating new certificates for every node every >2 days. This seems li= ke a non-starter IMHO As I explained in my answer to Ray in 6man WG, 2 days is just recommendatio= n. If one uses 20 days the probability is still low. Now let's explain the = problem from different aspects, i.e., internal network and external network= . I am not following 6man. I will read your documents once you have publish a= ll the data. Roque Internal network: We can provide privacy in layer 3. For privacy in layer 2, there is also a = need to have a dynamic MAC address (this is explained in another paper that= is under publication) from which we generate the address by using a kind o= f hashing algorithm, like SHA256. This is especially feasible in cloud netw= orks where virtual machines are used. Using temporary keys and IP addresses= would provide privacy in layer 3. We also provide security for this network by preventing DAD and IP stealin= g attacks. One thing that is missing in my draft, which I will correct, is how to avoi= d spoofed MAC address attacks. In this case, we also need to include the MA= C address in the signature so that, if the verification process fails, the = message is discarded by the node that should redirect this message. External network: Changing router prefixes (now done in some countries) and the IID would pro= vide the privacy needed for this node in layer 3. But for upper layers, the= re are a lot of different approaches available: far too numerous to explain= them here. Another thing is that router nodes do not necessarily require the use of c= ertification because, for a node in local network, it is important that the= y be able to generate their IP address so that nobody can steal their addre= ss and this is also true routers as well. Finally, the reason for recommend= ing that key pairs be generated with the generation of a new IP address is = that this eliminates the chance of a node being tracked based on its public= key in layer 3 of internal networks and in external networks (eliminates t= he chance of privacy attacks). > Please include the reference to your studies instead of saying "Our exper= imental results show a definite improvement ". Our research in this area is about to be published. I can upload the result= s of our research to our website and refer you to that. (I will add the ref= erence to the draft after the it published and appears online) Thank you, Hosnieh On January 7, 2013 at 4:40 AM "Roque Gagliano (rogaglia)" > wrote: > Hosnieh, > > I have some comments: > - Why this is an important problem to be addressed is not clear in the te= xt other than saying "CGA are computing intensive", which is arguable depen= ding on network sizes and equipment > - You need to add text to the document on where the improvement resides. = You mentioned something on the answer to Ahmad but that is still not convin= cing. > - You mention that the strength of your algorithm requires that the key p= air needs to be changed every 2 days. In the case you are using SEND, this = means generating new certificates for every node every 2 days. This seams l= ike a non-starter IMHO. > - Please include the reference to your studies instead of saying "Our exp= erimental results show a definite improvement ". > > BTW, there other proposals for privacy extensions today that you should m= ention: https://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresse= s-02 > > Roque. > > On Jan 6, 2013, at 9:40 PM, Hosnieh Rafiee > wrote: > > > 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 doe= s 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 SE= ND. > > > >> I agree with the claim that CGA is compute intensive, but one can use = Sec=3D0 > > or 1. In this case the computation of the CGA (SEND) would be equivalen= t 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 ti= mes > > 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 ver= ify > > 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 consid= ered > > 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 MI= ME 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 tha= n > > "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" > > > To: Hosnieh Rafiee >, "cga-ex= t@ietf.org" > > > > > Cc: "ipv6@ietf.org" > > > Subject: Re: [CGA-EXT] Call for comments on > > draft-rafiee-6man-ssas-00.txt > > Message-ID: > > Content-Type: text/plain; charset=3D"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 S= ec=3D0 > > or 1. In this case the computation of the CGA (SEND) would be equivalen= t to > > the complexity of your approach. Therefore the enhancements that are > > proposed to protect the user privacy by setting a lifetime for the gene= rated > > 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-ex= t-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 appreciat= ed. > > 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 > > ************************************** > > > > _______________________________________________ > > CGA-EXT mailing list > > CGA-EXT@ietf.org > > https://www.ietf.org/mailman/listinfo/cga-ext > --_000_EF4348D391D0334996EE9681630C83F02202AE93xmbalnx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <4325A313D2890F45910DA9B5CBE161BE@cisco.com> Content-Transfer-Encoding: quoted-printable Hosnieh,

On Jan 7, 2013, at 5:05 PM, Hosnieh <ietf@rozanak.com> wrote:

 

Dear Rogue,

Thank you for your comments and questions.

 

> Why this is an important problem to be addressed is not clear in th= e text other than saying "CGA are computing intensive", which is = arguable depending on network sizes and equipment

 

The problem is one of privacy. Addresses need to change in order to prot= ect privacy. In this vain it then becomes beneficial and important to be ab= le to generate the IID more quickly. For nodes in the network it is enough = to use SSAS without thinking about the use of certificates because that is all that is needed to prove addres= s ownership. At the same time, it is recommended to use vehicles outlined i= n other RFCs to prevent all nodes from claiming to be a router.

So if the problem you want to solve is privacy, what is the big differ= ence between your proposal and changing a CGA by using a different modifier= from time to time? In your case you have a timestamp but the modifier can = be arbitrary.

> You need to add text to the document on where the improvement resid= es. You mentioned something on the answer to Ahmad but that is still not co= nvincing.

So being able to generate the address faster along with reducing the ver= ification time does not convince you? It is already a given that the use of= CGA for a sec value over 1 is not feasible. Even when using a sec value of= 0 the verification time using CGA is much higher than that for SSAS. The conclusion drawn from this is that,= in the event of DoS attacks, SSAS enable nodes have the ability to process= more packets per minute than do those using CGA.

What do you mean by packet per minutes? ND packets? new neighbours? old nei= ghbours that I already have in the cache? which L2 domain size? I thin= k I would expect these sort of data to backup your comments.

> You mention that the strength of your algorithm requires that the k= ey pair needs to be changed every 2 days. In the case you are using SEND, t= his means generating new certificates for every node every >2 days. This= seems like a non-starter IMHO

As I explained in my answer to Ray in 6man WG, 2 days is just recommenda= tion. If one uses 20 days the probability is still low. Now let's explain t= he problem from different aspects, i.e., internal network and external netw= ork.

I am not following 6man. I will read your documents once you have publ= ish all the data.

Roque

Internal network:

We can provide privacy in layer 3. For privacy in layer 2, there is also= a need to have a dynamic MAC address (this is explained in another paper t= hat is under publication) from which we generate the address by using a kin= d of hashing algorithm, like SHA256. This is especially feasible in cloud networks where virtual machines are u= sed. Using temporary keys and IP addresses would provide privacy in layer 3= .

 We also provide security for this network by preventing DAD and IP= stealing attacks.

One thing that is missing in my draft, which I will correct, is how to a= void spoofed MAC address attacks. In this case, we also need to include the= MAC address in the signature so that, if the verification process fails, t= he message is discarded by the node that should redirect this message.

External network: 

Changing router prefixes (now done in some countries) and the IID would = provide the privacy needed for this node in layer 3. But for upper layers, = there are a lot of different approaches available: far too numerous to expl= ain them here.

Another thing is that router nodes do not necessarily require the use of=   certification because, for a node in local network, it is important = that they be able to generate their IP address so that nobody can steal the= ir address and this is also true routers as well. Finally, the reason for recommending that key pairs be generated = with the generation of a new IP address is that this eliminates the chance = of a node being tracked based on its public key in layer 3 of internal netw= orks and in external networks (eliminates the chance of privacy attacks).

 
 

> Please include the reference to your studies instead of saying &quo= t;Our experimental results show a definite improvement ".

 

Our research in this area is about to be published. I can upload the res= ults of our research to our website and refer you to that. (I will add the = reference to the draft after the it published and appears online)

 

Thank you,

Hosnieh

 
 

On January 7, 2013 at 4:40 AM "Roque Gagliano (rogaglia)" <rogaglia@cisco.com> wrote:
> Hosnieh,
>
> I have some comments:
> - Why this is an important problem to be addressed is not clear in the= text other than saying "CGA are computing intensive", which is a= rguable depending on network sizes and equipment
> - You need to add text to the document on where the improvement reside= s. You mentioned something on the answer to Ahmad but that is still not con= vincing.
> - You mention that the strength of your algorithm requires that the ke= y pair needs to be changed every 2 days. In the case you are using SEND, th= is means generating new certificates for every node every 2 days. This seam= s like a non-starter IMHO.
> - Please include the reference to your studies instead of saying "= ;Our experimental results show a definite improvement ".
>
> BTW, there other proposals for privacy extensions today that you shoul= d mention: https://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-02=
>
> Roque.
>
> On Jan 6, 2013, at 9:40 PM, Hosnieh Rafiee <ietf@rozanak.com> wrote:
>
> > Dear Ahmad,
> >
> > Thank you so much for your comments.
> >
> >> SEND already offers what you are looking for. It has the Time= stamp and the
> > Signature options which are attached to the DNP messages.
> >
> > As I explained in my last email to Jeremy, It just updates SEND a= nd 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=3D0
> > or 1. In this case the computation of the CGA (SEND) would be equ= ivalent to
> > the complexity of your approach.
> > I compared it with both sec value 0 and sec value 1. I did not co= nsider sec
> > value higher because it is not really feasible in practice that s= omeone 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 t= he
> > 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, bu= t with SSAS
> > the packet size would be less.
> >
> > Thank you,
> > Hosnieh
> >
> > -----Original Message-----
> > From: cga-ext-bounces= @ietf.org [mailto:cga-ext-bounc= es@ietf.org] On Behalf
> > Of cga-ext-request@ie= tf.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 messa= ge
> > attachments you will need to update your digest options in your l= ist
> > 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 &= quot;Get MIME or
> > Plain Text Digests?" to MIME. You can set this option global= ly 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<= /a>
> >
> > When replying, please edit your Subject line so it is more specif= ic 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@r= ozanak.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=3D"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 Timestam= p 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=3D0
> > or 1. In this case the computation of the CGA (SEND) would be equ= ivalent to
> > the complexity of your approach. Therefore the enhancements that = are
> > proposed to protect the user privacy by setting a lifetime for th= e 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 signi= ficant
> > change to proposed standard.
> > In Section 5, ?? it provides proof of address ownership at a spee= d 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 app= reciated.
> > 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 Associat= ion
> > [1] (section 2.5.1 RFC-4291) [RFC4291]. This means that a node wi= ll
> > 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, the= re
> > 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 w= ith
> > the latter approach is that it lacks security. This document offe= rs 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
> > **************************************
> >
> > _______________________________________________
> > CGA-EXT mailing list
> > CGA-EXT@ietf.org
> > https:/= /www.ietf.org/mailman/listinfo/cga-ext
>

--_000_EF4348D391D0334996EE9681630C83F02202AE93xmbalnx02ciscoc_-- From ietf@rozanak.com Sun Jan 13 16:37:31 2013 Return-Path: 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 9812821F8442 for ; Sun, 13 Jan 2013 16:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 LiPFFvPAd7yz for ; Sun, 13 Jan 2013 16:37:25 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 82CAB21F85D0 for ; Sun, 13 Jan 2013 16:37:25 -0800 (PST) Received: from kopoli (f052070143.adsl.alicedsl.de [78.52.70.143]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0M2btd-1T4eJm1MQf-00sCSs; Sun, 13 Jan 2013 19:37:24 -0500 From: "Hosnieh Rafiee" To: "'Roque Gagliano \(rogaglia\)'" References: <000701cdec4e$0a6cd040$1f4670c0$@rozanak.com> <614007519.821132.1357574730593.JavaMail.open-xchange@email.1and1.com> In-Reply-To: Date: Mon, 14 Jan 2013 01:37:15 +0100 Message-ID: <000401cdf1ef$50b96ee0$f22c4ca0$@rozanak.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01CDF1F7.B282DFF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ8yJBoNjjL67lO6xYHS3PvKMAFbAJoT+25ASXkDMMB+UXsegDNm62MlrecQPA= Content-Language: en-us X-Provags-ID: V02:K0:XG0G09J4zz3BoQfTQABeGnnCucp6XSgcc21lTnqonzT aUfl8ntgQzWCkA2SsaYQW1mguUae76MV/7AMAvhjf6iTWI2ytj FiPg0BeQwVzSA1S5bVDD5DYgN3JitHtvMQVKfSCKE+DnHWgZqk yzLJaHtd7tJIsVw8+j4rxK62tep/cc29bOPduVq+5Wbqkf5JZw dojQEoGVqJI32AHg0VYCAoKGL87YybpaKIddGYwlmsadmZQN8u eiHOYKm+wcvFQvfa/R2gllnXoclphACyEw7DLpqlPjD0B/NZ0V piSxz/pSn8mDPxk6LFE7d/sIWrYpQQ1z0ZV4yOGSndetXsa9um 5zn4dX6kA8f2bUylLTk0= Cc: cga-ext@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 00:37:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0005_01CDF1F7.B282DFF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Roque, >So if the problem you want to solve is privacy, what is the big difference between your proposal and changing a CGA by using a different modifier from time to time? In >your case you have a timestamp but the modifier can be arbitrary. I also use a modifier. The difference between SSAS and CGA is the direct usage of a public key as a part of the IP address. So, SSAS also generates a random address and the chances of address collision is also minimized because SSAS uses SHA2. If we want to use SHA2 for CGA, we would need to forget about a sec value higher than 0 because of the generation time is dependent on the condition of 16 by sec value that must be equal to zero. For the generation of CGA, the subnet prefix is required. This generation must be in real time and cannot be in offline. For privacy, you usually need to change your IP address regularly. Unfortunately, to generate a CGA, it takes all the CPU power to accomplish this generation. This might have an adverse effect on the other services trying to use that CPU. This is why an algorithm needing less computing time is an advantage. >What do you mean by packet per minutes? ND packets? new neighbours? old neighbours that I already have in the cache? which L2 domain size? I think I would expect ?>these sort of data to backup your comments. The number of NDP messages a node can verify per a certain period of time. This verification is due to the addition of the addition of that node's IP address to the node's neighbor cache or just for to accomplish the DAD process. As you know, one type of attack against CGA is related to DoS. This means that the node is kept busy with false parameters. There is nothing in the CGA RFC about how to protect a node against this type of attack. The new RFCs, that extend CGA, also did not explain this. But in SSAS, we did we explain how to protect nodes against this type of attack and in new version of SSAS I enhanced the process to making the verification time even faster. This should also be of help. Thank you, Best Regards, Hosnieh From: Roque Gagliano (rogaglia) [mailto:rogaglia@cisco.com] Sent: Monday, January 07, 2013 6:01 PM To: Hosnieh Cc: Roque Gagliano (rogaglia); Subject: Re: [CGA-EXT] CGA-EXT Digest, Vol 47, Issue 2 Hosnieh, On Jan 7, 2013, at 5:05 PM, Hosnieh wrote: Dear Rogue, Thank you for your comments and questions. > Why this is an important problem to be addressed is not clear in the text other than saying "CGA are computing intensive", which is arguable depending on network sizes and equipment The problem is one of privacy. Addresses need to change in order to protect privacy. In this vain it then becomes beneficial and important to be able to generate the IID more quickly. For nodes in the network it is enough to use SSAS without thinking about the use of certificates because that is all that is needed to prove address ownership. At the same time, it is recommended to use vehicles outlined in other RFCs to prevent all nodes from claiming to be a router. So if the problem you want to solve is privacy, what is the big difference between your proposal and changing a CGA by using a different modifier from time to time? In your case you have a timestamp but the modifier can be arbitrary. > You need to add text to the document on where the improvement resides. You mentioned something on the answer to Ahmad but that is still not convincing. So being able to generate the address faster along with reducing the verification time does not convince you? It is already a given that the use of CGA for a sec value over 1 is not feasible. Even when using a sec value of 0 the verification time using CGA is much higher than that for SSAS. The conclusion drawn from this is that, in the event of DoS attacks, SSAS enable nodes have the ability to process more packets per minute than do those using CGA. What do you mean by packet per minutes? ND packets? new neighbours? old neighbours that I already have in the cache? which L2 domain size? I think I would expect these sort of data to backup your comments. > You mention that the strength of your algorithm requires that the key pair needs to be changed every 2 days. In the case you are using SEND, this means generating new certificates for every node every >2 days. This seems like a non-starter IMHO As I explained in my answer to Ray in 6man WG, 2 days is just recommendation. If one uses 20 days the probability is still low. Now let's explain the problem from different aspects, i.e., internal network and external network. I am not following 6man. I will read your documents once you have publish all the data. Roque Internal network: We can provide privacy in layer 3. For privacy in layer 2, there is also a need to have a dynamic MAC address (this is explained in another paper that is under publication) from which we generate the address by using a kind of hashing algorithm, like SHA256. This is especially feasible in cloud networks where virtual machines are used. Using temporary keys and IP addresses would provide privacy in layer 3. We also provide security for this network by preventing DAD and IP stealing attacks. One thing that is missing in my draft, which I will correct, is how to avoid spoofed MAC address attacks. In this case, we also need to include the MAC address in the signature so that, if the verification process fails, the message is discarded by the node that should redirect this message. External network: Changing router prefixes (now done in some countries) and the IID would provide the privacy needed for this node in layer 3. But for upper layers, there are a lot of different approaches available: far too numerous to explain them here. Another thing is that router nodes do not necessarily require the use of certification because, for a node in local network, it is important that they be able to generate their IP address so that nobody can steal their address and this is also true routers as well. Finally, the reason for recommending that key pairs be generated with the generation of a new IP address is that this eliminates the chance of a node being tracked based on its public key in layer 3 of internal networks and in external networks (eliminates the chance of privacy attacks). > Please include the reference to your studies instead of saying "Our experimental results show a definite improvement ". Our research in this area is about to be published. I can upload the results of our research to our website and refer you to that. (I will add the reference to the draft after the it published and appears online) Thank you, Hosnieh On January 7, 2013 at 4:40 AM "Roque Gagliano (rogaglia)" wrote: > Hosnieh, > > I have some comments: > - Why this is an important problem to be addressed is not clear in the text other than saying "CGA are computing intensive", which is arguable depending on network sizes and equipment > - You need to add text to the document on where the improvement resides. You mentioned something on the answer to Ahmad but that is still not convincing. > - You mention that the strength of your algorithm requires that the key pair needs to be changed every 2 days. In the case you are using SEND, this means generating new certificates for every node every 2 days. This seams like a non-starter IMHO. > - Please include the reference to your studies instead of saying "Our experimental results show a definite improvement ". > > BTW, there other proposals for privacy extensions today that you should mention: https://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-02 > > Roque. > > On Jan 6, 2013, at 9:40 PM, Hosnieh Rafiee wrote: > > > 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" > > To: Hosnieh Rafiee , "cga-ext@ietf.org" > > > > Cc: "ipv6@ietf.org" > > Subject: Re: [CGA-EXT] Call for comments on > > draft-rafiee-6man-ssas-00.txt > > Message-ID: > > 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 > > ************************************** > > > > _______________________________________________ > > CGA-EXT mailing list > > CGA-EXT@ietf.org > > https://www.ietf.org/mailman/listinfo/cga-ext > ------=_NextPart_000_0005_01CDF1F7.B282DFF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Roque,

 

>So if the = problem you want to solve is privacy, what is the big difference between = your proposal and changing a CGA by using a different modifier from time = to time? In >your case you have a timestamp but the modifier can be = arbitrary.

 

I also use a modifier. The difference between SSAS and CGA is the = direct usage of a public key as a part of the IP address. So, SSAS also = generates a random address and the chances of address collision is also = minimized because SSAS uses SHA2. If we want to use SHA2 for CGA, we = would need to forget about a sec value  higher than 0 because of = the generation time is dependent on the condition of 16 by sec value = that must be equal to zero.

For the generation of CGA, the subnet prefix is required. This = generation must be in real time and cannot be in offline. For privacy, = you usually need to change your IP address regularly. Unfortunately, to = generate a CGA, it takes all the CPU power to accomplish this = generation. This might have an adverse effect on the other services = trying to use that CPU. This is why an algorithm needing less computing = time is an advantage.

 

 

>What do you mean = by packet per minutes? ND packets? new neighbours? old = neighbours that I already have in the cache? which L2 domain size? = I think I would expect ?>these sort of data to backup your = comments.

 

The number of NDP messages a node can verify per a certain period of = time. This verification is due to the addition of the addition of =  that node’s IP address to the node’s neighbor cache or = just for to accomplish the DAD process. As you know, one type of attack = against CGA is related to DoS. This means that the node is kept busy = with false parameters. There is nothing in the CGA RFC about how to = protect a node against this type of attack. The new RFCs, that extend = CGA, also did not explain this. But in SSAS, we did we explain how to = protect nodes against this type of attack and in new version of SSAS I = enhanced the process to making the verification time even faster. This = should also be of help.

 

 

Thank you,

Best Regards,

Hosnieh

 

 

 

 

From:= = Roque Gagliano (rogaglia) [mailto:rogaglia@cisco.com]
Sent: = Monday, January 07, 2013 6:01 PM
To: Hosnieh
Cc: = Roque Gagliano (rogaglia); <cga-ext@ietf.org>
Subject: = Re: [CGA-EXT] CGA-EXT Digest, Vol 47, Issue = 2

 

Hosnieh, =

 

On = Jan 7, 2013, at 5:05 PM, Hosnieh <ietf@rozanak.com> = wrote:



 

Dear = Rogue,

Thank you for your comments and = questions.

 

> Why this is an = important problem to be addressed is not clear in the text other than = saying "CGA are computing intensive", which is arguable = depending on network sizes and equipment

 

The problem is one of = privacy. Addresses need to change in order to protect privacy. In this = vain it then becomes beneficial and important to be able to generate the = IID more quickly. For nodes in the network it is enough to use SSAS = without thinking about the use of certificates because that is all that = is needed to prove address ownership. At the same time, it is = recommended to use vehicles outlined in other RFCs to prevent all nodes = from claiming to be a router.

So if the problem you want to solve is privacy, what = is the big difference between your proposal and changing a CGA by using = a different modifier from time to time? In your case you have a = timestamp but the modifier can be = arbitrary.

> You = need to add text to the document on where the improvement resides. You = mentioned something on the answer to Ahmad but that is still not = convincing.

So being able to generate the address = faster along with reducing the verification time does not convince you? = It is already a given that the use of CGA for a sec value over 1 is not = feasible. Even when using a sec value of 0 the verification time using = CGA is much higher than that for SSAS. The conclusion drawn from this is = that, in the event of DoS attacks, SSAS enable nodes have the ability to = process more packets per minute than do those using = CGA.

What do = you mean by packet per minutes? ND packets? new neighbours? old = neighbours that I already have in the cache? which L2 domain size? = I think I would expect these sort of data to backup your = comments.

> You = mention that the strength of your algorithm requires that the key pair = needs to be changed every 2 days. In the case you are using SEND, this = means generating new certificates for every node every >2 days. This = seems like a non-starter IMHO

As I explained in my = answer to Ray in 6man WG, 2 days is just recommendation. If one uses 20 = days the probability is still low. Now let's explain the problem from = different aspects, i.e., internal network and external = network.

I am not following 6man. I will read your documents = once you have publish all the data.

 

Roque

Internal = network:

We can provide privacy in layer 3. For privacy = in layer 2, there is also a need to have a dynamic MAC address (this is = explained in another paper that is under publication) from which we = generate the address by using a kind of hashing algorithm, like SHA256. = This is especially feasible in cloud networks where virtual machines are = used. Using temporary keys and IP addresses would provide privacy in = layer 3.

 We also provide security for this = network by preventing DAD and IP stealing attacks.

One = thing that is missing in my draft, which I will correct, is how to avoid = spoofed MAC address attacks. In this case, we also need to include the = MAC address in the signature so that, if the verification process fails, = the message is discarded by the node that should redirect this = message.

External = network: 

Changing router prefixes (now done in = some countries) and the IID would provide the privacy needed for this = node in layer 3. But for upper layers, there are a lot of different = approaches available: far too numerous to explain them = here.

Another thing is that router nodes do not = necessarily require the use of  certification because, for a node = in local network, it is important that they be able to generate their IP = address so that nobody can steal their address and this is also true = routers as well. Finally, the reason for recommending that key pairs be = generated with the generation of a new IP address is that this = eliminates the chance of a node being tracked based on its public key in = layer 3 of internal networks and in external networks (eliminates the = chance of privacy attacks).

 

 

> Please include the = reference to your studies instead of saying "Our experimental = results show a definite improvement ".

 

Our research in this = area is about to be published. I can upload the results of our research = to our website and refer you to that. (I will add the reference to the = draft after the it published and appears online)

 

Thank = you,

Hosnieh

 

 


On January 7, 2013 at 4:40 AM "Roque Gagliano = (rogaglia)" <rogaglia@cisco.com> wrote: =
> Hosnieh,
>
> I have some comments:
> - Why = this is an important problem to be addressed is not clear in the text = other than saying "CGA are computing intensive", which is = arguable depending on network sizes and equipment
> - You need to = add text to the document on where the improvement resides. You mentioned = something on the answer to Ahmad but that is still not convincing. =
> - You mention that the strength of your algorithm requires that = the key pair needs to be changed every 2 days. In the case you are using = SEND, this means generating new certificates for every node every 2 = days. This seams like a non-starter IMHO.
> - Please include the = reference to your studies instead of saying "Our experimental = results show a definite improvement ".
>
> BTW, there = other proposals for privacy extensions today that you should mention: https://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addres= ses-02
>
> Roque.
>
> On Jan 6, 2013, at = 9:40 PM, Hosnieh Rafiee <ietf@rozanak.com> wrote: =
>
> > 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=3D0
> > 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.o= rg/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.o= rg/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-po= tsdam.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=3D"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=3D0
> > 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://da= tatracker.ietf.org/doc/draft-rafiee-6man-ssas
> > = Htmlized: http://tool= s.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.o= rg/mailman/listinfo/cga-ext
> >
> >
> = > ------------------------------
> >
> > = _______________________________________________
> > CGA-EXT = mailing list
> > CGA-EXT@ietf.org
> > https://www.ietf.o= rg/mailman/listinfo/cga-ext
> >
> >
> = > End of CGA-EXT Digest, Vol 47, Issue 2
> > = **************************************
> >
> > = _______________________________________________
> > CGA-EXT = mailing list
> > CGA-EXT@ietf.org
> > https://www.ietf.o= rg/mailman/listinfo/cga-ext
> =

 

------=_NextPart_000_0005_01CDF1F7.B282DFF0-- From ietf@rozanak.com Mon Jan 21 15:56:38 2013 Return-Path: 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" To: "Ray Hunter" , "'Duncan, Richard \(Jeremy\)'" , "Fernando Gont" , "'Al-Sadeh, Ahmad'" , "Roque Gagliano \(rogaglia\)" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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=3Ddraft-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. = =20 The IETF Secretariat