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

Miika Komu <mkomu@cs.hut.fi> Mon, 18 October 2010 06:35 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 C20EE3A6C58 for <shim6@core3.amsl.com>; Sun, 17 Oct 2010 23:35:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level:
X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[AWL=-1.710, BAYES_00=-2.599, FRT_STOCK2=3.988, 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 VSYGuLNYColk for <shim6@core3.amsl.com>; Sun, 17 Oct 2010 23:35:30 -0700 (PDT)
Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by core3.amsl.com (Postfix) with ESMTP id 2BB2E3A683F for <shim6@ietf.org>; Sun, 17 Oct 2010 23:35:29 -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 1P7jL5-00058F-U4; Mon, 18 Oct 2010 09:36:55 +0300
Message-ID: <4CBBEB88.4070704@cs.hut.fi>
Date: Mon, 18 Oct 2010 09:39:04 +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: Shinta Sugimoto <shinta@sfc.wide.ad.jp>
References: <20100816114202.1241.59079.idtracker@localhost> <4C692876.60802@ cs.hut.fi> <4535F52C-8E78-4CBE-8983-DD7195722865@apnic.net> <4C69DE84.8010 7 06@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. n e t> <4CAA425E.2070906@piuha.net> <4CAEB35B.3020107@cs.hut.fi> <4CAEDEAD.9060407@piuha.net> <4CAF01F6.3030905@cs.hut.fi> <7CC566635CFE364D87DC5803D4712A6C4CEC451999@X CH-NW-10V.nw.nos.boeing.com> <4CB53CCC.3080903@cs.hut.fi> <7CC566635CFE364D87DC5803D4712A6C4CEC4519A4@XCH-NW-10V.nw.nos.boeing.com> <4CB68883.7070408@cs.hut.fi> <7CC566635CFE364D87DC5803D4712A6C4CEC4519C0@XCH-NW-10V.nw.nos.boeing.com> <4CB6951F.7040103@sfc.wide.ad.jp> <4CB76C19.208@cs.hut.fi> <4CB7DB72.4010800@sfc.wide.ad.jp> <4CB982D3.8080904@cs.hut.fi> <4CB9BE31.5020501@sfc.wide.ad.jp>
In-Reply-To: <4CB9BE31.5020501@sfc.wide.ad.jp>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: shim6@ietf.org
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: Mon, 18 Oct 2010 06:35:31 -0000

Hi Shinta,

On 16/10/10 18:01, Shinta Sugimoto wrote:
> Hi Miika,
>
> (10/10/16 19:47), Miika Komu wrote:
>
> (snip)
>
>>> What about updating the texts for Section 13.1.2 (replacing the second
>>> paragraph) as follows:
>>>
>>> If the shim sub-layer turns out to be HIP, the HIP implementation MUST
>>> reject the request (SHIM_LOC_PEER_SEND as cmsg_type) for using a unknown
>>> destination locator. There is, however, an exceptional case where the
>>> HIP implementation SHOULD accept the request provided that the message
>>> to be sent by sendmsg() contains an I1 packet. In this exceptional case,
>>> the kernel SHOULD accept the request even if there is no shim context
>>> associated with the socket.
>>>
>>> Does this sound reasonable?
>>
>> It does, except why do we need to restrict to sendmsg()?
>
> Because it is possible to distinguish the exceptional case from the
> normal case. Suppose you allow it by setsockopt(). How do you
> distinguish the two cases? I have no idea how to do it.

can you remind why it needs to be distinguished? If there's no reason, 
what about:

There is, however, an exceptional case where the HIP layer SHOULD accept 
the request. The case occurs when there is no context or the HIP state 
machine is in UNASSOCIATED state. In this exceptional case,
the socket layer SHOULD accept the request.

>> I would also
>> suggest the following changes:
>>
>> * s/implementation/layer/
>> * s/kernel/HIP layer/
>
> OK.
>
>> * s/constains an I1 packet/would be used to initiate a key exchange by
>> the HIP layer/
>
> Let me clarify. Do you foresee other data than I1 packet which would
> trigger the HIP key exchange? I thought it is the HIP daemon who uses
> the ancillary data (SHIM_LOC_PEER_SEND as cmsg_type) to send the I1
> packet to a designated locator. Or, is it the application that uses the
> socket option to send user data to a designated locator? If so, how can
> the kernel distinguish the exceptional case from the normal case? Note
> that the suggested text is saying that normally the kernel must reject
> the request if there is no shim context associated with the socket.

Please note that I1 in this context is misleading because it sounds like 
the application is sending the I1 (where as it should hipd sending it).

There's actually a case where there's no need to send I1:

https://tools.ietf.org/html/draft-ietf-hip-hiccups-05

I believe the suggested text above should cover it too, but we shouldn't 
be too specific about it because it's functionality uncommon between 
SHIM6 and HIP.