Re: [CGA-EXT] Applicability of draft-ietf-csi-proxy-send

Alberto García <alberto@it.uc3m.es> Thu, 04 March 2010 11:35 UTC

Return-Path: <alberto@it.uc3m.es>
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 AFB253A89E3 for <cga-ext@core3.amsl.com>; Thu, 4 Mar 2010 03:35:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 7fnKxlhr4QQT for <cga-ext@core3.amsl.com>; Thu, 4 Mar 2010 03:35:00 -0800 (PST)
Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 7A8CD3A8407 for <cga-ext@ietf.org>; Thu, 4 Mar 2010 03:35:00 -0800 (PST)
X-uc3m-safe: yes
Received: from bombo (bombo.it.uc3m.es [163.117.139.125]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 8C86D7F4281; Thu, 4 Mar 2010 12:35:00 +0100 (CET)
From: =?ISO-8859-15?Q?Alberto_Garc=EDa?= <alberto@it.uc3m.es>
To: "'Erik Nordmark'" <erik.nordmark@sun.com>, <cga-ext@ietf.org>
References: <4B211D2A.2050105@sun.com>
Date: Thu, 4 Mar 2010 12:35:02 +0100
Message-ID: <5EADCE483AD2457EA02193628B5069D6@bombo>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Acp5syRiJyefIE9BTCmqmCPCqtn3sRAOp2Cg
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
In-reply-to: <4B211D2A.2050105@sun.com>
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002
Subject: Re: [CGA-EXT] Applicability of draft-ietf-csi-proxy-send
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: Thu, 04 Mar 2010 11:35:01 -0000

Hi Erik,

|  -----Mensaje original-----
|  De: cga-ext-bounces@ietf.org [mailto:cga-ext-bounces@ietf.org] En nombre
de
|  Erik Nordmark
|  Enviado el: jueves, 10 de diciembre de 2009 17:09
|  Para: cga-ext@ietf.org
|  Asunto: [CGA-EXT] Applicability of draft-ietf-csi-proxy-send
|  
|  
|  The document lists three applicable scenarios, and I don't understand
|  how the ND Proxy (RFC 4389) fits with the proposed solution.
|  
|  My understanding of the usage model for RFC 4389 is that the hosts need
|  not be modified, nor have any specific configuration, to work with 4389
|  proxies.
|  
|  However, csi-proxy-send not only requires that all the SeND hosts be
|  modified, it also makes them aware of the 4389 proxy. If we are going to
|  make host modifications and have the hosts be aware of the proxy, then
|  we can do something more robust than 4389. The desirable feature of 4389
|  was to be transparent to the hosts and routers.
|  
|  The other scenarios are quite different. For instance a Mobile IPv6 host
|  is well aware that the home agent is a proxy on its behalf.

I don't understand properly your point.

Well, if hosts were upgraded to 'Secure Proxy ND' (for example, to benefit
from the MIPv6 scenario), applying these tools to RFC 4389 would be
straightforward. I mean, maybe this would not the solution to build
specifically for 4389, but it could save the day, couldn't it?
The other change required is to have a certificate for the proxy, which
could be propagated by the proxy itself into the proxied segments. Being
strict, router configuration is not performed (RFC 4389, sec 1.3 says that
it is not appropriate for scenarios when configuration of the router can be
done). 
Specific configuration of the hosts (apart from being SEND and secure Proxy
ND aware), i.e. per-host or even per-link configuration, is not required.

Of course, the mechanism is not transparent, since routers or hosts are
aware of which messages have been proxied. 

Is there any flaw on applying this mechanism to the 4389 scenario? 
Do you still think it is not appropriate for the scenario?

Regards,
Alberto

|  
|      Erik
|  
|  _______________________________________________
|  CGA-EXT mailing list
|  CGA-EXT@ietf.org
|  https://www.ietf.org/mailman/listinfo/cga-ext