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

"Laganier, Julien" <> Mon, 07 December 2009 17:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D88A63A67B5 for <>; Mon, 7 Dec 2009 09:57:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.651
X-Spam-Status: No, score=-103.651 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i3qvRxxChmp0 for <>; Mon, 7 Dec 2009 09:57:34 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B1E523A68DB for <>; Mon, 7 Dec 2009 09:57:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=qcdkim; t=1260208645; x=1291744645; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20<> |To:=20Roque=20Gagliano=20<>,=0D=0A=20=20 =20=20=20=20=20=20"draft-ietf-csi-proxy-send@tools.ietf.o rg"=0D=0A=09<> |CC:=20""=20<>|Date:=20Mo n,=207=20Dec=202009=2009:57:20=20-0800|Subject:=20RE:=20[ CGA-EXT]=20Review=20draft-ietf-csi-proxy-send-01 |Thread-Topic:=20[CGA-EXT]=20Review=20draft-ietf-csi-prox y-send-01|Thread-Index:=20Acp3Rq2zFtsjXsgISK2JTzH/OVvq7gA F/xkw|Message-ID:=20<BF345F63074F8040B58C00A186FCA57F1C65>|References:=20<alpine .LNX.2.00.0911191100150.7833@whitebox>=0D=0A=09<BF345F630 .com>=0D=0A=09<alpine.LNX.2.00.0911201144010.7546@whitebo x>=0D=0A=09<BF345F63074F8040B58C00A186FCA57F1C65FB277D@NA>=0D=0A=09<alpine.LNX.2.00.09112 11025090.11248@localhost.localdomain>=0D=0A=09<BF345F6307 com>=0D=0A=09<alpine.LNX.2.00.0911242317130.11124@localho st.localdomain>=0D=0A=09<BF345F63074F8040B58C00A186FCA57F>=0D=0A=09<alpine.L NX.2.00.0911260951580.7596@whitebox>=0D=0A=20<37915D90-B2>|In-Reply-To:=20<379> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 400,1158,5825"=3B=20a=3D"29285777"; bh=xJXnEcKpltLUmSjH1VPtOSv8+p0K6+0sYuCA3WhQ7ZA=; b=tlcTGeNSNW40udQ9TkT9GCYa4If/6RxvA7Za+vYBYzhEtHxQiYhWtICO noGrpWHVhKOuRlblFn5Cbu4ZRAwmw/9a/vL+cL6wQ4vBEbdtLSogdIhMi 0SL4K/efQNjGXVuHC+AyVfQeV7Mj7WdfTrp1o+rpETP8C4AFMKT8VqsXp o=;
X-IronPort-AV: E=McAfee;i="5400,1158,5825"; a="29285777"
Received: from (HELO ([]) by with ESMTP; 07 Dec 2009 09:57:24 -0800
Received: from ( []) by (8.14.2/8.14.2/1.0) with ESMTP id nB7HvOkg024533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 7 Dec 2009 09:57:24 -0800
Received: from ( []) by (8.14.2/8.14.2/1.0) with ESMTP id nB7HvLF1032277 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 7 Dec 2009 09:57:24 -0800
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 7 Dec 2009 09:57:21 -0800
Received: from ([]) by ([]) with mapi; Mon, 7 Dec 2009 09:57:21 -0800
From: "Laganier, Julien" <>
To: Roque Gagliano <>, "" <>
Date: Mon, 7 Dec 2009 09:57:20 -0800
Thread-Topic: [CGA-EXT] Review draft-ietf-csi-proxy-send-01
Thread-Index: Acp3Rq2zFtsjXsgISK2JTzH/OVvq7gAF/xkw
Message-ID: <>
References: <alpine.LNX.2.00.0911191100150.7833@whitebox> <> <alpine.LNX.2.00.0911201144010.7546@whitebox> <> <alpine.LNX.2.00.0911211025090.11248@localhost.localdomain> <> <alpine.LNX.2.00.0911242317130.11124@localhost.localdomain> <> <alpine.LNX.2.00.0911260951580.7596@whitebox> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [CGA-EXT] Review draft-ietf-csi-proxy-send-01
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: CGA and SeND Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 07 Dec 2009 17:57:35 -0000

Roque Gagliano wrote:
> I reviewed the documents and here are my comments. Overall I found it
> clear and easy to read.

Sounds good. Thank you for taking the time to review the document. Some comments inline below: 

> --------------------------------------------
> 1)
> Abstract:
> As specified today SEND assumes that the node advertising
>                      ^^^^^^
>                     in RFC 3971

Ok. How about?

As specified in the current SEND specification [RFC3971], it is assumed that the node advertising...

> 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.

Well, actually that's a feature of CGA's, one can show proof-of-ownership by signing with the CGA's private key. I own my CGA because I generated it and the corresponding key pair, and you do not own it and you can't show proof of ownership because you don't have the private key.

So I think we want to keep using that term.

I can agree that we don't want to talk about a prefix owner, though, but I don't think we're doing that in the document. 

> 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.

The section 4.1. describe the RFC4389 use case. In this use case Router Solicitations (RS's) negotiate no link layer address and thus they do not require specific treatment compared to regular IPv6 data packets, as opposed to the messages listed above, NS, NA, RA and Redirect.

> 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:
> s/krishnan-cgaext-send-cert-eku/ietf-csi-send-cert-01
> The document is now a WG item.
> Bullet 2:
> s/has/hash
> 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.

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. 
> 6) Normative references:
> s/krishnan-cgaext-send-cert-eku/ietf-csi-send-cert-01
> The document is now a WG item.