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

Shinta Sugimoto <shinta@sfc.wide.ad.jp> Mon, 18 October 2010 10:20 UTC

Return-Path: <shinta@sfc.wide.ad.jp>
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 ED8A33A6A71 for <shim6@core3.amsl.com>; Mon, 18 Oct 2010 03:20:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.895
X-Spam-Level: ***
X-Spam-Status: No, score=3.895 tagged_above=-999 required=5 tests=[AWL=-0.997, BAYES_00=-2.599, FRT_STOCK2=3.988, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994]
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 cEbOtgiuTlN9 for <shim6@core3.amsl.com>; Mon, 18 Oct 2010 03:20:03 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id C82A83A6D53 for <shim6@ietf.org>; Mon, 18 Oct 2010 03:20:02 -0700 (PDT)
Received: from localhost.localdomain (unknown [IPv6:2001:380:633:2:20b:cdff:fefb:2a8]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id C4D66278086; Mon, 18 Oct 2010 19:21:27 +0900 (JST)
Message-ID: <4CBC1E45.1010608@sfc.wide.ad.jp>
Date: Mon, 18 Oct 2010 19:15:33 +0900
From: Shinta Sugimoto <shinta@sfc.wide.ad.jp>
User-Agent: Thunderbird 2.0.0.6 (X11/20070809)
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.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> <4CBBEB88.4070704@cs.hut.fi>
In-Reply-To: <4CBBEB88.4070704@cs.hut.fi>
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 10:20:04 -0000

Hi Miika,

(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:

The exceptional case needs to be distinguished from the normal case 
because we accept SHIM_LOC_PEER_SEND when there is no shim context 
associated with the socket. And we have good reason to limit the usage 
of the socket option to the cases where there is a shim context 
associated with the socket.

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

To WG members: please note that I had phone discussion with Miika and 
came to a common understanding that the following text would suffice:

There is, however, an exceptional case where the HIP layer SHOULD accept 
the request provided that the HIP association 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.

OK. I now understand that you are talking about the case where 
application provides a kind of hints to the HIP daemon about the initial 
locator by writing data to the socket.

Regards,
Shinta