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

Tony Cheneau <tony.cheneau@it-sudparis.eu> Sat, 21 November 2009 09:52 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 00D613A691C for <cga-ext@core3.amsl.com>; Sat, 21 Nov 2009 01:52:58 -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 3VXV8V-UZ4vf for <cga-ext@core3.amsl.com>; Sat, 21 Nov 2009 01:52:56 -0800 (PST)
Received: from smtp4.int-evry.fr (smtp4.int-evry.fr [157.159.10.71]) by core3.amsl.com (Postfix) with ESMTP id 5F26A3A691E for <cga-ext@ietf.org>; Sat, 21 Nov 2009 01:52:55 -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 DA517FE1942; Sat, 21 Nov 2009 10:52:51 +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 1D030404FA7; Sat, 21 Nov 2009 10:52:47 +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 B0F3290004; Sat, 21 Nov 2009 10:52:46 +0100 (CET)
Date: Sat, 21 Nov 2009 10:52:48 +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: <BF345F63074F8040B58C00A186FCA57F1C65FB277D@NALASEXMB04.na.qualcomm.com>
Message-ID: <alpine.LNX.2.00.0911211025090.11248@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>
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: 1D030404FA7.A9773
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: Sat, 21 Nov 2009 09:52:58 -0000

Hi Julien

On Fri, 20 Nov 2009, Laganier, Julien wrote:

> Tony,
>
> If a router is compromised, it can send a RA containing a PIO with the L bit set to zero, and thus two hosts on the link trying to communicate will sends their packets to the router and will not attempt to resolve each others' address. Doing so, it can mount a MiTM attack of siphon off packets sent by a host. This is acknowledged in section 4.2.1. of RFC 3756.
Indeed, I forgot this L flag. You're right.


> Regarding the fe80::/64 prefix, it does not need to be advertized by the router or proxy. It should be assumed that a ND proxy is always authorized to proxy signaling for the fe80::/64 prefix. That does not need to be signaled in the certificate, it has to be written down in the draft however :)
This is a good way to go (other way around seems to add the fe80::/64 prefix to
the Secure Proxy ND's certificate). However, can you add a security
consideration specific to this new "rule" ? I see a security issue here.

>From RFC 4861, section 4.6.2 (the Prefix Information Option):
"A router SHOULD NOT send a prefix option for the link-local prefix and a host
SHOULD ignore such a prefix option."

Meaning that the attack in 4.2.1 of RFC 3756 "SHOULD NOT" work on two nodes
communicating directly using their link-local addresses (as the PIOs sent by
the router will more likely be ignored).
Here, the Secure Proxy ND seems to be able to siphon off the communication of
the same two nodes using their link-local addresses (as it is always authorized
to proxy signaling for the fe80::/64 prefix).

Maybe I am (again) missing something here.


Regards,
 	Tony