IETF Logo Mail Archive

Re: FW: 6MAN Adoption call on draft-rafiee-6man-ssas-07

marcelo bagnulo braun <marcelo@it.uc3m.es> Sat, 23 November 2013 20:01 UTC

Return-Path: <marcelo@it.uc3m.es>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39AF21AE340 for <ipv6@ietfa.amsl.com>; Sat, 23 Nov 2013 12:01:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.06
X-Spam-Level:
X-Spam-Status: No, score=-104.06 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_SOFTFAIL=0.665, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-ub0YIDbjGJ for <ipv6@ietfa.amsl.com>; Sat, 23 Nov 2013 12:01:24 -0800 (PST)
Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id B02441AE333 for <ipv6@ietf.org>; Sat, 23 Nov 2013 12:01:24 -0800 (PST)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 6E64376B81D; Sat, 23 Nov 2013 21:01:15 +0100 (CET)
X-uc3m-safe: yes
Received: from [163.117.203.85] (unknown [163.117.203.85]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id 273F376788E; Sat, 23 Nov 2013 21:01:15 +0100 (CET)
Message-ID: <5291098B.2050402@it.uc3m.es>
Date: Sat, 23 Nov 2013 21:01:15 +0100
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Hosnieh Rafiee <ietf@rozanak.com>, ipv6@ietf.org
Subject: Re: FW: 6MAN Adoption call on draft-rafiee-6man-ssas-07
References: <C1684DC4-3748-4B4C-A39F-3B8DB928645D@employees.org> <CEB3E7E4.28A01%elevyabe@cisco.com> <00a201cee6f5$926e6f10$b74b4d30$@rozanak.com> <528E6A0F.6040706@it.uc3m.es> <00aa01cee6f7$934cd640$b9e682c0$@rozanak.com> <528E7193.8010500@it.uc3m.es> <00ac01cee6fc$1dc12f70$59438e50$@rozanak.com> <528E7440.7090400@it.uc3m.es> <00bf01cee6fe$b9f1b430$2dd51c90$@rozanak.com> <528E78B5.8010209@it.uc3m.es> <00f001cee705$16921c10$43b65430$@rozanak.com> <528EFA70.7000800@it.uc3m.es> <001201cee753$11c5a370$3550ea50$@rozanak.com> <CAAfuxnJbmPQVS8BCWbUkmpBFhNHpH=xHLwqQ+nRR_ausL4oUcQ@mail.gmail.com> <004d01cee7c9$9d9e40c0$d8dac240$@rozanak.com> <C91E67751B1EFF41B857DE2FE1F68ABA2FBBECB0@tk5ex14mbxc272.redmond.corp.microsoft.com> <52906944.3030109@it.uc3m.es> <000701cee839$034e0df0$09ea29d0$@rozanak.com>
In-Reply-To: <000701cee839$034e0df0$09ea29d0$@rozanak.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Greylist: Sender IP whitelistedACL 131 matched, not delayed by milter-greylist-4.2.7 (smtp02.uc3m.es); Sat, 23 Nov 2013 21:01:15 +0100 (CET)
X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20316.001
X-TM-AS-Result: No--5.945-7.0-31-1
X-imss-scan-details: No--5.945-7.0-31-1
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Nov 2013 20:01:28 -0000

El 23/11/13 11:44, Hosnieh Rafiee escribió:
>>>> Now, we could indeed rework the CGA spec to allow for algorithm
> agility,
>> and protect against a possible crypto analysis of SHA1. And use the u/g
> bits.
>> Like any other effort related to CGA/SEND, the urgency of such efforts
>> depends on the priority of the SEND scenario.
>>
>> This is already done, please see:
>>
>> http://www.ietf.org/rfc/rfc4982.txt
>>
>
> This specification cannot help CGA again since they use the 3 ignored bits.

ok, this is my last attempt
SEC value is part of the address. Changing the SEc value changes the 
address, hence, if you manage to proof the onership of a CGA with a 
different SEC value you are in fact attacking a different address.



> About the deployments. What I understood from one of implementers, he
> worries about IPR of CGA. However, Christian said someone can sell it and it
> is royalty free , etc. But  he  just do not like the idea of IPR on
> something.
>
> Smile,
> Hosnieh
>
>

v2.39.1 | Report a Bug | By Email | System Status