Re: [CGA-EXT] Review draft-ietf-csi-proxy-send-01

Roque Gagliano <roque@lacnic.net> Thu, 10 December 2009 00:10 UTC

Return-Path: <roque@lacnic.net>
X-Original-To: cga-ext@core3.amsl.com
Delivered-To: cga-ext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 075D33A684C for <cga-ext@core3.amsl.com>; Wed, 9 Dec 2009 16:10:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.047
X-Spam-Level:
X-Spam-Status: No, score=-1.047 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKI+eN8jblZr for <cga-ext@core3.amsl.com>; Wed, 9 Dec 2009 16:09:59 -0800 (PST)
Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by core3.amsl.com (Postfix) with ESMTP id 0446E3A6968 for <cga-ext@ietf.org>; Wed, 9 Dec 2009 16:09:58 -0800 (PST)
Received: from 85-7-200.lacnic.net.uy (unknown [200.7.85.78]) by mail.lacnic.net.uy (Postfix) with ESMTP id 58001308475; Wed, 9 Dec 2009 22:09:33 -0200 (UYST)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: multipart/alternative; boundary=Apple-Mail-10-776210640
From: Roque Gagliano <roque@lacnic.net>
In-Reply-To: <BF345F63074F8040B58C00A186FCA57F1C65FB3043@NALASEXMB04.na.qualcomm.com>
Date: Thu, 10 Dec 2009 01:09:28 +0100
Message-Id: <5B84EA57-9C58-4968-BA15-8A43A555C50C@lacnic.net>
References: <alpine.LNX.2.00.0911191100150.7833@whitebox> <BF345F63074F8040B58C00A186FCA57F1C66087842@NALASEXMB04.na.qualcomm.com> <alpine.LNX.2.00.0911201144010.7546@whitebox> <BF345F63074F8040B58C00A186FCA57F1C65FB277D@NALASEXMB04.na.qualcomm.com> <alpine.LNX.2.00.0911211025090.11248@localhost.localdomain> <BF345F63074F8040B58C00A186FCA57F1C65FB2942@NALASEXMB04.na.qualcomm.com> <alpine.LNX.2.00.0911242317130.11124@localhost.localdomain> <BF345F63074F8040B58C00A186FCA57F1C65FB2A51@NALASEXMB04.na.qualcomm.com> <alpine.LNX.2.00.0911260951580.7596@whitebox> <37915D90-B246-48E4-9C7B-69DAF54FA43A@lacnic.net> <BF345F63074F8040B58C00A186FCA57F1C65FB2ECE@NALASEXMB04.na.qualcomm.com> <B2FDAE8C-CBC8-41BA-8604-B8A79AA763D7@lacnic.net> <BF345F63074F8040B58C00A186FCA57F1C65FB3043@NALASEXMB04.na.qualcomm.com>
To: "Laganier, Julien" <julienl@qualcomm.com>
X-Mailer: Apple Mail (2.1077)
X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information
X-LACNIC.uy-MailScanner: Found to be clean
X-LACNIC.uy-MailScanner-SpamCheck:
X-LACNIC.uy-MailScanner-From: roque@lacnic.net
Cc: "draft-ietf-csi-proxy-send@tools.ietf.org" <draft-ietf-csi-proxy-send@tools.ietf.org>, "cga-ext@ietf.org" <cga-ext@ietf.org>
Subject: Re: [CGA-EXT] Review draft-ietf-csi-proxy-send-01
X-BeenThere: cga-ext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: CGA and SeND Extensions <cga-ext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cga-ext>
List-Post: <mailto:cga-ext@ietf.org>
List-Help: <mailto:cga-ext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Dec 2009 00:10:00 -0000

Hi Julian,

> 
> So in terms of prefix I agree that you want to use right of use rather than ownership, but in terms of CG-addresses, IMHO we do want to say ownership.
> 

The distinction is not so clear for me but I am fine with "no innovating". 

>> That is something I made clear in the CERT draft.
> 
> But the focus of the CERT draft is on delegating authorization to advertize/use prefixes or addresses that are NOT cryptographically generated, thus there's no ownership involved.
> 
>>> The lack of algorithm agility is generic to SEND and not specific to the Secure Proxy ND mechanism. When the WG concludes on how to move forward with algorithm agility, we can publish an RFC updating both RFC3971 and this to be RFC to add algorithm agility. 
>> 
>> So, we know there is a problem and probably know that SEC ADs are looking at these particular issues, however we would to advance this draft to the IESG hopping that it passes their LC with the promise to solve the issue later on? I only have been in CSI for a couple of months but does not sound proper IETF process to me.
>> 
>> The agility discussion also included a signaling between the parties in order to select which algorithm to use. What we can do while that discussion is not over in the WG is to make sure that new SEND options have the possibility of identifying which algorithms each party are using, leaving the signaling part for later. This is similar to DNSSEC where in order to change from SHA-1 to SHA-256 probably all signatures will be for a while duplicated in the zone files.
> 
> Would inclusion of an algorithm field in the PSO solve your concern?

IMHO, it will help to move the document through the next step.

Roque.

> --julien

-------------------------------------------------------------
Roque Gagliano
LACNIC
roque@lacnic.net
GPG Fingerprint: E929 06F4 D8CD 2AD8 9365  DB72 9E4F 964A 01E9 6CEE