Re: [shim6] AD review of draft-ietf-shim6-multihome-shim-api

Jari Arkko <jari.arkko@piuha.net> Fri, 08 October 2010 09:03 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: shim6@core3.amsl.com
Delivered-To: shim6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29F5C3A681F for <shim6@core3.amsl.com>; Fri, 8 Oct 2010 02:03:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.443
X-Spam-Level:
X-Spam-Status: No, score=-102.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 Q5THL-DTazdY for <shim6@core3.amsl.com>; Fri, 8 Oct 2010 02:03:43 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 27B113A67A3 for <shim6@ietf.org>; Fri, 8 Oct 2010 02:03:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8BD9D2CC4B; Fri, 8 Oct 2010 12:04:46 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+9xDwoWbx0w; Fri, 8 Oct 2010 12:04:46 +0300 (EEST)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id E6E942CC2F; Fri, 8 Oct 2010 12:04:45 +0300 (EEST)
Message-ID: <4CAEDEAD.9060407@piuha.net>
Date: Fri, 08 Oct 2010 11:04:45 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: Miika Komu <mkomu@cs.hut.fi>
References: <20100816114202.1241.59079.idtracker@localhost> <4C692876.60802@cs.hut.fi> <4535F52C-8E78-4CBE-8983-DD7195722865@apnic.net> <4C69DE84.8010706@sfc.wide.ad.jp> <4C91D119.5010101@cs.hut.fi> <4C91E946.6080807@sfc.wide.ad.jp> <4C920431.2090603@cs.hut.fi> <86C69B19-D385-46A9-B116-5EE198273305@apnic.net> <4CAA425E.2070906@piuha.net> <4CAEB35B.3020107@cs.hut.fi>
In-Reply-To: <4CAEB35B.3020107@cs.hut.fi>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: shim6 <shim6@ietf.org>, kristian.slavov@ericsson.com
Subject: Re: [shim6] AD review of draft-ietf-shim6-multihome-shim-api
X-BeenThere: shim6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SHIM6 Working Group Mailing List <shim6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/shim6>, <mailto:shim6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/shim6>
List-Post: <mailto:shim6@ietf.org>
List-Help: <mailto:shim6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/shim6>, <mailto:shim6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Oct 2010 09:03:44 -0000

Miika,

>>> 13.1.2. Treatment of Unknown Destination Locator
>>>
>>>
>>>    If the shim sub-layer turns out to be SHIM6, the SHIM6 
>>> implementation
>>>    MUST reject the request for using unknown destination locator.
>>>
>>>    If the shim sub-layer turns out to be HIP, the HIP implementation 
>>> MAY
>>>    accept the request for using unknown destination locator.
>>
>> This seems like an insufficiently explained security issue. Why is it OK
>> for HIP to do this, or at least you should describe what are
>> consequences if it does so?
>
> I would suggest to change this text as follows:
>
> If the shim sub-layer turns out to be HIP, the HIP implementation MAY 
> accept the request for using unknown destination locator after a 
> successful address verification procedure.
>
> Does this work for you?
>

Not quite. I think the text has to explain what you mean by unknown 
destination locator, and what principle is used to accept new locators, 
and if it is allowed to deviate from those principles what happens.

Specifically, I *think* that you mean in Shim6 you would never accept an 
address outside the HBA set (or verified by CGA). But what about HIP? I 
think you could accept any locator as long as the other side was OK with 
that. However, IIRC in HIP you cannot propose a locator for the other 
side, only for yourself. Or is your plan that you move the session to 
another locator and that if that node happens to be the wrong one, then 
it cannot decrypt the traffic anyway, so there's no damage?

Jari