Re: [CGA-EXT] Question on draft-ietf-csi-proxy-send-00

Suresh Krishnan <suresh.krishnan@ericsson.com> Tue, 03 February 2009 21:17 UTC

Return-Path: <suresh.krishnan@ericsson.com>
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 BD80028C147 for <cga-ext@core3.amsl.com>; Tue, 3 Feb 2009 13:17:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.576
X-Spam-Level:
X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 YyQdy09mu4Bv for <cga-ext@core3.amsl.com>; Tue, 3 Feb 2009 13:17:14 -0800 (PST)
Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id C6CAC3A6B9F for <cga-ext@ietf.org>; Tue, 3 Feb 2009 13:17:14 -0800 (PST)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n13LMePL029851; Tue, 3 Feb 2009 15:22:46 -0600
Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 15:15:26 -0600
Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 15:15:26 -0600
Message-ID: <4988B3E5.9060603@ericsson.com>
Date: Tue, 03 Feb 2009 16:15:17 -0500
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
User-Agent: Thunderbird 2.0.0.19 (X11/20090105)
MIME-Version: 1.0
To: Tony Cheneau <tony.cheneau@it-sudparis.eu>
References: <alpine.LNX.2.00.0812191650490.6427@whitebox>
In-Reply-To: <alpine.LNX.2.00.0812191650490.6427@whitebox>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 03 Feb 2009 21:15:26.0696 (UTC) FILETIME=[88C01E80:01C98644]
Cc: draft-ietf-csi-proxy-send@tools.ietf.org, cga-ext@ietf.org, Julien Laganier <julien.laganier.ietf@googlemail.com>
Subject: Re: [CGA-EXT] Question on draft-ietf-csi-proxy-send-00
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, 03 Feb 2009 21:17:15 -0000

Hi Tony,
   Thanks for your comments. Please see responses inline.

Tony Cheneau wrote:
> Hello,
> 
> I've gone through draft-ietf-csi-proxy-send-00 and I have some comments.
> 
> You state in section 5:
>    The Secure Proxy ND becomes part of the trusted infrastructure just
>    like a SEND router.  The Secure Proxy ND is granted a certificate
>    that specifies the range of addresses for which it is allowed to
>    perform proxying of SEND messages.  Hosts can use the same process to
>    discover the certification path between a proxy and one of the host's
>    trust anchors as the one defined for routers in Section 6 of SEND
>    specification [RFC3971].
> 
> As far as I understand, once you authorize a node to act as a Proxy with
> a certificate, if the proxy gets corrupted, it can update Neighbor Cache
> value of all the nodes on the link. Am I right ?

Yes. You are right. This situation needs to be fixed by detecting this 
and revoking the certificate of the proxy.

> 
> If so, maybe you should add a statement in the Security Considerations
> indicating that as specified the protocol is prone to Good Router Gone
> Bad attacks.

OK. Will do.

> 
> I think this attacks should be mitigated by using a Token generated by 
> the proxied node and sent to a proxy to authorize it to actually "proxy" 
> the address. This token will be carried in every proxied messages 
> (modified by the proxy). It will prove the receiver that the proxied 
> node authorized the proxy to act as such.

This is not always possible since the proxied node is not always aware 
of the existence of the proxy. e.g. the ND proxies are transparent to 
the proxied node. That is why we opted to use a certificate issued by 
the trusted infrastructure.

Cheers
Suresh