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

Tony Cheneau <tony.cheneau@it-sudparis.eu> Tue, 24 November 2009 22:40 UTC

Return-Path: <tony.cheneau@it-sudparis.eu>
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 7ECAC3A68C3 for <cga-ext@core3.amsl.com>; Tue, 24 Nov 2009 14:40:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35]
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 CnKXw-ZBraFS for <cga-ext@core3.amsl.com>; Tue, 24 Nov 2009 14:40:26 -0800 (PST)
Received: from smtp4.int-evry.fr (smtp4.int-evry.fr [157.159.10.71]) by core3.amsl.com (Postfix) with ESMTP id 669C33A67D9 for <cga-ext@ietf.org>; Tue, 24 Nov 2009 14:40:26 -0800 (PST)
Received: from smtp2.int-evry.fr (smtp2.int-evry.fr [157.159.10.45]) by smtp4.int-evry.fr (Postfix) with ESMTP id 2DBC2FE1C1B; Tue, 24 Nov 2009 23:40:21 +0100 (CET)
Received: from smtp-ext.int-evry.fr (smtp-ext.int-evry.fr [157.159.11.17]) by smtp2.int-evry.fr (Postfix) with ESMTP id B9215405392; Tue, 24 Nov 2009 23:40:09 +0100 (CET)
Received: from alf94-6-82-226-232-167.fbx.proxad.net (alf94-6-82-226-232-167.fbx.proxad.net [82.226.232.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-ext.int-evry.fr (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 <tony.cheneau@it-sudparis.eu>
X-X-Sender: shad@localhost.localdomain
To: "Laganier, Julien" <julienl@qualcomm.com>
In-Reply-To: <BF345F63074F8040B58C00A186FCA57F1C65FB2942@NALASEXMB04.na.qualcomm.com>
Message-ID: <alpine.LNX.2.00.0911242317130.11124@localhost.localdomain>
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>
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)
X-INT-MailScanner-From: tony.cheneau@it-sudparis.eu
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] Comments on 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: 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
    node."
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.


Regards,
 	Tony