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

Shinta Sugimoto <shinta@sfc.wide.ad.jp> Sat, 16 October 2010 14:59 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 C0EAF3A67A3 for <shim6@core3.amsl.com>; Sat, 16 Oct 2010 07:59:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.045
X-Spam-Level: ****
X-Spam-Status: No, score=4.045 tagged_above=-999 required=5 tests=[AWL=-0.847, 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 QZ81fCLb8eqN for <shim6@core3.amsl.com>; Sat, 16 Oct 2010 07:59:44 -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 D1A023A68E4 for <shim6@ietf.org>; Sat, 16 Oct 2010 07:59:44 -0700 (PDT)
Received: from imac.local (softbank126018084155.bbtec.net [126.18.84.155]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 8A99A27809F; Sun, 17 Oct 2010 00:01:05 +0900 (JST)
Message-ID: <4CB9BE31.5020501@sfc.wide.ad.jp>
Date: Sun, 17 Oct 2010 00:01:05 +0900
From: Shinta Sugimoto <shinta@sfc.wide.ad.jp>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; ja-JP-mac; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4
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>
In-Reply-To: <4CB982D3.8080904@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: Sat, 16 Oct 2010 14:59:45 -0000

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.

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

Regards,
Shinta