Re: [savi] About draft-dong-savi-cga-header-02.txt

Alberto García <alberto@it.uc3m.es> Fri, 17 July 2009 08:16 UTC

Return-Path: <alberto@it.uc3m.es>
X-Original-To: savi@core3.amsl.com
Delivered-To: savi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 614D03A683B for <savi@core3.amsl.com>; Fri, 17 Jul 2009 01:16:27 -0700 (PDT)
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 R4g8ADQ7fM-1 for <savi@core3.amsl.com>; Fri, 17 Jul 2009 01:16:26 -0700 (PDT)
Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 1FFD33A696D for <savi@ietf.org>; Fri, 17 Jul 2009 01:16:25 -0700 (PDT)
Received: from bombo (bombo.it.uc3m.es [163.117.139.125]) by smtp02.uc3m.es (Postfix) with ESMTP id 45D976C1473; Fri, 17 Jul 2009 10:16:57 +0200 (CEST)
From: Alberto García <alberto@it.uc3m.es>
To: 'Dong Zhang' <zhangdong_rh@huaweisymantec.com>, 'Christian Vogt' <christian.vogt@ericsson.com>, 'SAVI Mailing List' <savi@ietf.org>
References: <4CB1C400-9A7F-435D-9B7A-B6B1B259E997@ericsson.com><200907151050081554172@huaweisymantec.com><75998D9056424F94A34294F878EF8958@bombo><200907161018350396693@huaweisymantec.com><16C7F3CCDE434470AF2D409B79B70A8E@bombo> <200907171450265993512@huaweisymantec.com>
Date: Fri, 17 Jul 2009 10:16:54 +0200
Message-ID: <4EB312B4DC044B6DB99E8E16EFEA72D7@bombo>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
In-Reply-To: <200907171450265993512@huaweisymantec.com>
Thread-Index: AcoGqwvDagW6cGwuQQuV2gX+Ke2fjQAA4UEg
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16768.004
Cc: 'Padmanabha Nallur 73868' <pnallur@huawei.com>
Subject: Re: [savi] About draft-dong-savi-cga-header-02.txt
X-BeenThere: savi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mailing list for the SAVI WG <savi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/savi>, <mailto:savi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/savi>
List-Post: <mailto:savi@ietf.org>
List-Help: <mailto:savi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/savi>, <mailto:savi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jul 2009 08:16:27 -0000

Hi

|  -----Mensaje original-----
|  De: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] En nombre de Dong
|  Zhang
|  Enviado el: viernes, 17 de julio de 2009 8:50
|  Para: Alberto_Garc?; 'Christian Vogt'; 'SAVI Mailing List'
|  CC: 'Padmanabha Nallur 73868'
|  Asunto: Re: [savi] About draft-dong-savi-cga-header-02.txt
|  
|  Alberto_Garc韆 2009-07-16 Wrote:
|  >|  I do not think it is a conflict. The difference is just how to
|  >|  use CGA. For instance, the CGA proposal can be used in e2e, even between
|  >the
|  >|  host
|  >|  and the first-hop router. It can depend on the destination option header.
|  >
|  >Shim6 allows transporting CGA information end-to-end. It does that now, in a
|  >standard way. Why you should want to generate a yet-another-protocol to
|  >transport CGA information end-to-end?
|  Thank you for the information.
|  We will read Shim6. If it really does the relative job, we will be glad to use it.
|  >
|  >Besides, what does such a protocol would have to do with SAVI?
|  >If you want to use CGAs for providing security in the link of the host and
|  >the first-hop router, you should probably use the SEND protocol (see
|  >draft-ietf-savi-send-00). Do you think there is something in the SEND
|  >protocol that does not suit with binding IPv6 addresses and link layer
|  >anchors, that could be improved?
|  >And if you want to use the CGA for address validation further than the first
|  >hop routers, I see some reasons why you should not:  at that point you need
|  >to validate prefixes, not host addresses, and CGA provides no protection for
|  >prefixes: any host can generate a valid CGA with whichever prefix it wanted.
|  >So just validating a CGA does not assure that the host is authorized to use
|  >that prefix.
|  In the CGA-related information, it contains the signature. We think it can
|  protect the prefix. Right?

Well, it does not prove that a host has been legitimately assigned a prefix. 
CGAs, with a protocol transporting signatures made with the private key, only assure that once a host generates a given address, it is very very difficult for another host to use the same address. And yes, the protection includes the prefix: it is just not enough to find a key pair whose hash generates a given interface identifier, and then you can impersonate any host with the same interface identifier in any network (i.e. with any prefix).

But that says nothing about the legitimacy of ah host to use that prefix.
For example, give the prefix of your network, and I can generate immediately an CGA that claims to belong to your prefix: CGA = hash ( prefix | public key | etc). And I can use from my network, if the router (and some routers above) does not check source prefixes. Looking only at the CGA nobody can know if my host is authorized to use a prefix or not.
So, CGA does not add anything to prefix protection. You have to provide other means to protect that. 


|  >
|  >|  >
|  >|  >What does this type of solutions has to do with SAVI, considering that
|  >the
|  >|  >charter says: "No changes to hosts are allowed."? Isn't your solution
|  >|  >proposing a change to hosts?
|  >|  Yes, the CGA proposal does not fit for the current charter quit well to
|  >some
|  >|  extend.
|  >|  The reason why we put the CGA-related info in the extension header is
|  >that it
|  >|  has
|  >|  the ability to provide a basic security for the source address like AH &
|  >ESP. The
|  >
|  >The CGA security model does not have much relationship with AH & ESP. Well,
|  >all use keys, but besides that...
|  I mean if we could take the CGA-related information in the extension header,
|  the packet will have AH, ESP and CGA for the basic security characteristics,
|  including integrity, confidentiality, and authentication.

This is completely different stuff. It seems like generating an opportunistic IKE security context (a la SSL) for a communication, starting with the public/private key pair associated to the CGAs of two hosts. Then you should look at http://tools.ietf.org/id/draft-laganier-ike-ipv6-cga-02.txt

Regards
Alberto

|  >
|  >|  we
|  >|  get the whole security in IP layer, including integrity, confidentiality
|  >and
|  >|  authentication.
|  >
|  >I think this is completely different stuff than SAVI.
|  In any case, we are trying to see if someone else is impersonating (or using)
|  the address. So savi is the closest in the current WGs. Of course, we are open to
|  looking at this and looking for interset in any related WG.
|  >
|  >Regards,
|  >Alberto
|  >
|  
|  Thanks
|  ------------------
|  Dong Zhang
|  2009-07-17