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

Miika Komu <mkomu@cs.hut.fi> Fri, 08 October 2010 11:34 UTC

Return-Path: <mkomu@cs.hut.fi>
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 23A023A688A for <shim6@core3.amsl.com>; Fri, 8 Oct 2010 04:34:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.259
X-Spam-Level:
X-Spam-Status: No, score=-6.259 tagged_above=-999 required=5 tests=[AWL=0.340, 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 eKwp+YawbCWD for <shim6@core3.amsl.com>; Fri, 8 Oct 2010 04:34:18 -0700 (PDT)
Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by core3.amsl.com (Postfix) with ESMTP id 76E183A6884 for <shim6@ietf.org>; Fri, 8 Oct 2010 04:34:17 -0700 (PDT)
Received: from hutcs.cs.hut.fi ([130.233.192.10] helo=[127.0.0.1]) by mail.cs.hut.fi with esmtp (Exim 4.54) id 1P4BEM-0000rA-7u; Fri, 08 Oct 2010 14:35:18 +0300
Message-ID: <4CAF01F6.3030905@cs.hut.fi>
Date: Fri, 08 Oct 2010 14:35:18 +0300
From: Miika Komu <mkomu@cs.hut.fi>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8
MIME-Version: 1.0
To: Jari Arkko <jari.arkko@piuha.net>
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> <4CAEDEAD.9060407@piuha.net>
In-Reply-To: <4CAEDEAD.9060407@piuha.net>
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 11:34:19 -0000

Hi,

On 10/08/2010 12:04 PM, Jari Arkko wrote:
> 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.

I believe an unknown destination locator means here a locator that is 
new to the SHIM layer (i.e. not yet included in the SHIM context).

> 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.

Good point.

> 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?

(There has to be a successful return routability check before any 
traffic is transported)

There's two use cases:

1. No HIP session (i.e. SHIM context) yet and application knows the IP 
address of the peer.
2. An existing HIP session, connectivity lost but the application (with 
the assistance from the user) can help to rediscover the peer.

Now remembering this "unknown" part again, I think the MAY was referring 
to the first case described above. It should be ok for the application 
give a hint especially in the absence of better knowledge from the SHIM.

Regarding to the case two, it is true that RFC5206 basically assumes 
that the peer has to announce it's locator set before the local host can 
use them. I believe the peer can refuse to answer if the local host 
triggers a return routability check to an unannounced locator of the 
peer. However, the situation may be changing in RFC5206-bis due to the 
recent advancements in IPv4-IPv6 handovers [1] which are not yet 
included in RFC5206.

Tom, care to comment if I am too proactive here?

[1] Secure and efficient IPv4/IPv6 handovers using host-based 
identifier-locator Split, Samu Varjonen et al, 2009