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

Tony Cheneau <> Tue, 24 November 2009 22:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7ECAC3A68C3 for <>; Tue, 24 Nov 2009 14:40:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CnKXw-ZBraFS for <>; Tue, 24 Nov 2009 14:40:26 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 669C33A67D9 for <>; Tue, 24 Nov 2009 14:40:26 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2DBC2FE1C1B; Tue, 24 Nov 2009 23:40:21 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id B9215405392; Tue, 24 Nov 2009 23:40:09 +0100 (CET)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTP id 8B5769012D; Tue, 24 Nov 2009 23:40:09 +0100 (CET)
Date: Tue, 24 Nov 2009 23:40:13 +0100 (CET)
From: Tony Cheneau <>
X-X-Sender: shad@localhost.localdomain
To: "Laganier, Julien" <>
In-Reply-To: <>
Message-ID: <alpine.LNX.2.00.0911242317130.11124@localhost.localdomain>
References: <alpine.LNX.2.00.0911191100150.7833@whitebox> <> <alpine.LNX.2.00.0911201144010.7546@whitebox> <> <alpine.LNX.2.00.0911211025090.11248@localhost.localdomain> <>
User-Agent: Alpine 2.00 (LNX 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-INT-MailScanner-Information: Please contact the ISP for more information
X-INT-MailScanner-ID: B9215405392.A7FDD
X-INT-MailScanner: Found to be clean
X-INT-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=0.805, requis 6.01, BAYES_00 -2.60, FH_HELO_EQ_D_D_D_D 0.00, HELO_DYNAMIC_IPADDR 2.43, RCVD_IN_SORBS_DUL 0.88, RDNS_DYNAMIC 0.10)
Cc: "" <>, "" <>
Subject: Re: [CGA-EXT] Comments on 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: Tue, 24 Nov 2009 22:40:27 -0000

Hi Julien,

> I had overlooked the proxy ND siphoning off traffic exchanged between two on-link link-local addresses. I agree that this is a difference with the compromised router threat and should be acknowledged in the document. How about the following?
>   Thanks to the authorization certificate it is provisioned with, a proxy ND
>   is authorized to issue ND signaling on behalf of nodes on the subnet.
>   Thus, a compromised proxy is able, like a compromised router, to siphon off
>   traffic from the host, or mount a man-in-the-middle attack. However, when
>   two on-link hosts communicate using their respective link-local addresses,
>   the threats involved with a compromised router and a compromised proxy ND
>   differs because the router is not able to siphon off traffic exchanged
>   between the hosts or mount a man-in-the-middle attack, while the proxy ND
>   can.
>   As for SEND which does not protect against attacks involved with the compromise
>   of a router, as described in Sections 9.2.4 of [RFC3971], Secure Proxy ND Support
>   for SEND does not protect against similar attacks involved with the
>   compromise of the proxy ND. However, the additional threat of siphoning off or
>   mounting a man-in-the-middle attack between two link-local addresses is countered
>   by having SEND nodes receiving both unproxied and proxied messages give priority to
>   unproxied ones.  Here, the "unproxied" messages are those that contain a valid signature
>   option as specified per the SEND specification [RFC3971], and "proxied"
>   messages are those that contain a valid proxy signature option (PSO) as
>   specified in this document.
I think the text is good now.

> As to specifying that the proxy ND is always authorized to proxy for addresses in the fe80::/64 prefix vs. inclusion in the certificate of either a list of node's link local addresses that the proxy ND is authorized to proxy, or of the whole fe80::/64 prefix, I have no strong opinion and would like to ask the WG participant what is their preference there?
I would prefer a "prefix or inclusion in the certificate" based solution, as 
I think there is some scenario where you may want to proxy global 
addresses and not the Link-Local ones at all.

I haven't read RFC 3775 recently. Please correct me if I'm wrong, but,
I think, RFC3775 (section 10.4.1) allows this kind of behavior:
"  In order to do this, when a node begins serving as the home agent it
    MUST multicast onto the home link a Neighbor Advertisement message
    [12] on behalf of the mobile node.  For the home address specified in
    the Binding Update, the home agent sends a Neighbor Advertisement
    message [12] to the all-nodes multicast address on the home link to
    advertise the home agent's own link-layer address for this IP address
    on behalf of the mobile node.  If the Link-Layer Address
    Compatibility (L) flag has been specified in the Binding Update, the
    home agent MUST do the same for the link-local address of the mobile
I assume that if the flag is turned off, you do not defend the
Link-Local addresses. The Home Agent does not need to act as a secure
proxy ND for this address either. Meaning you can disallow the secure
proxy ND on the fe80::/64 prefix/address and lessen the effect of a
compromised secure proxy ND.