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

Roque Gagliano <roque@lacnic.net> Mon, 07 December 2009 14:08 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 []) by core3.amsl.com (Postfix) with ESMTP id 00EEA28C192 for <cga-ext@core3.amsl.com>; Mon, 7 Dec 2009 06:08:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.928
X-Spam-Level: *
X-Spam-Status: No, score=1.928 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id zDC4+uBH+5Jp for <cga-ext@core3.amsl.com>; Mon, 7 Dec 2009 06:08:03 -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 ABB5B28C191 for <cga-ext@ietf.org>; Mon, 7 Dec 2009 06:08:02 -0800 (PST)
Received: from [] (176-164.1-85.cust.bluewin.ch []) by mail.lacnic.net.uy (Postfix) with ESMTP id 67B183084D2; Mon, 7 Dec 2009 12:07:27 -0200 (UYST)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
From: Roque Gagliano <roque@lacnic.net>
In-Reply-To: <alpine.LNX.2.00.0911260951580.7596@whitebox>
Date: Mon, 7 Dec 2009 02:18:42 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <37915D90-B246-48E4-9C7B-69DAF54FA43A@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>
To: draft-ietf-csi-proxy-send@tools.ietf.org
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-From: roque@lacnic.net
Cc: cga-ext@ietf.org
Subject: [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: Mon, 07 Dec 2009 14:08:04 -0000

I reviewed the documents and here are my comments. Overall I found it clear and easy to read. 





As specified today SEND assumes that the node advertising
                    in RFC 3971

2) General comment on "ownership" of IP addresses:
The documents mentions in several parts that a host "owns" an address or a prefix. Coming from the registry world, I can say that it is not the correct terminology. IP addresses are not owned, they are allocated or assigned. Then configured (dynamically or statically) in an interface. Ownership has a meaning of property that should not be used.

3) Section 4.1
A ND Proxy shall parse any IPv6 packet it receives on a proxy interface to check whether it contains one of the following ICMPv6 messages: Neighbor Solicitation (NS), Neighbor Advertisement (NA), Router Advertisement (RA), or Redirect.
Router Solicitation messages are missing, these are needed in example 3.

4) Section 5.

Paragraph 1: 
It is written as if Proxy SEND only applies to RA and RS as it mentions "assume that the owner of the address was the one who was advertising the prefix". I rather say: "the address or prefix was configured in the node originating the ND message".

Bullet 1: 
The document is now a WG item.

Bullet 2:

5) Section 6.1 Proxy Signature Option.
Here is my biggest issue, there is no possibility of transitioning from one algorithm to another, the document sticks with SHA-1 as hashing algorithm  and RSA/SHA-1 for signature. Working in another protocol, the SEC ADs made it clear that they are looking at documents to make sure that there is a way to change the crypto algorithms if needed. The host receiving the NDP message from the SEND Proxy needs to know the signature alg. that is being used. One solution to this issue is to define 8 bits of the Reserved bits where 4 of them define the hash algorithms and the other 4 the  signing algorithm. A transition mechanism could be to include two PSOs extensions, one with each set of algorithms.

I know this may also have to do with the protocol agility discussion. Again, you could check with the SEC ADs if this would be an issue for them.

6) Normative references:
The document is now a WG item.