Re: [shim6] AD review of draft-ietf-shim6-multihome-shim-api
Miika Komu <mkomu@cs.hut.fi> Wed, 13 October 2010 04:57 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 D6CA83A68A8 for <shim6@core3.amsl.com>; Tue, 12 Oct 2010 21:57:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.387
X-Spam-Level:
X-Spam-Status: No, score=-6.387 tagged_above=-999 required=5 tests=[AWL=0.212, 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 w3x667YQnmJs for <shim6@core3.amsl.com>; Tue, 12 Oct 2010 21:57:04 -0700 (PDT)
Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by core3.amsl.com (Postfix) with ESMTP id 6E0C03A6B37 for <shim6@ietf.org>; Tue, 12 Oct 2010 21:57:04 -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 1P5tPt-00065q-C5; Wed, 13 Oct 2010 07:58:17 +0300
Message-ID: <4CB53CCC.3080903@cs.hut.fi>
Date: Wed, 13 Oct 2010 07:59:56 +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: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
References: <20100816114202.1241.59079.idtracker@localhost> <4C692876.60802@ cs.hut.fi> <4535F52C-8E78-4CBE-8983-DD7195722865@apnic.net> <4C69DE84.80107 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.ne t> <4CAA425E.2070906@piuha.net> <4CAEB35B.3020107@cs.hut.fi> <4CAEDEAD.9060407@piuha.net> <4CAF01F6.3030905@cs.hut.fi> <7CC566635CFE364D87DC5803D4712A6C4CEC451999@XCH-NW-10V.nw.nos.boeing.com>
In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4CEC451999@XCH-NW-10V.nw.nos.boeing.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: shim6 <shim6@ietf.org>, "kristian.slavov@ericsson.com" <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: Wed, 13 Oct 2010 04:57:08 -0000
Hi, On 12/10/10 20:54, Henderson, Thomas R wrote: >> -----Original Message----- From: Miika Komu >> [mailto:mkomu@cs.hut.fi] Sent: Friday, October 08, 2010 4:35 AM To: >> Jari Arkko Cc: Shinta Sugimoto; shim6; >> kristian.slavov@ericsson.com; Henderson, Thomas R Subject: Re: >> [shim6] AD review of draft-ietf-shim6-multihome-shim-api >> > <snip> > >>> 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. > > I agree; that was my understanding of the main intent of this clause > (to allow the application to provide the shim with a hint of the > binding to IP address). > > However, in reviewing section 6.2, it seems like this would fail > since there is no shim context for the socket. If I'm not mistaken, > the draft seems to forbid applications running in opportunistic HIP > mode because this API requires that shim context be associated with > the socket for the ancillary data to be accepted. right: http://tools.ietf.org/html/draft-ietf-hip-native-api-12#section-4.6 "Another use case is to use the opportunistic mode.." >> 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 > > The paper does point out a use case for sending data to a previously > unknown locator-- however, it seems to be slightly different than the > use case here. In the paper, the node learns of the address change > and it seems that the HIP daemon sends an Echo request-- I take this > to mean that the HIP daemon does this proactively. Here, we are > talking about applications triggering this directly and using this > API to do so since they may have learned of the address out of band? I stand corrected, setting the destination address should be possible only in the beginning of HIP communications between two hosts.
- [shim6] IESG submission: draft-ietf-shim6-multiho… Geoff Huston
- Re: [shim6] IESG submission: draft-ietf-shim6-mul… Jari Arkko
- [shim6] AD review of draft-ietf-shim6-multihome-s… Jari Arkko
- Re: [shim6] AD review of draft-ietf-shim6-multiho… Miika Komu
- Re: [shim6] AD review of draft-ietf-shim6-multiho… Jari Arkko
- Re: [shim6] AD review of draft-ietf-shim6-multiho… Miika Komu
- Re: [shim6] AD review of draft-ietf-shim6-multiho… Jari Arkko
- Re: [shim6] AD review of draft-ietf-shim6-multiho… Miika Komu
- Re: [shim6] AD review of draft-ietf-shim6-multiho… Shinta Sugimoto
- Re: [shim6] AD review of draft-ietf-shim6-multiho… Brian E Carpenter
- Re: [shim6] AD review of draft-ietf-shim6-multiho… Miika Komu
- Re: [shim6] AD review of draft-ietf-shim6-multiho… Henderson, Thomas R
- Re: [shim6] AD review of draft-ietf-shim6-multiho… Miika Komu
- Re: [shim6] AD review of draft-ietf-shim6-multiho… Shinta Sugimoto
- Re: [shim6] AD review of draft-ietf-shim6-multiho… Henderson, Thomas R
- Re: [shim6] AD review of draft-ietf-shim6-multiho… Henderson, Thomas R
- Re: [shim6] AD review of draft-ietf-shim6-multiho… Shinta Sugimoto
- Re: [shim6] AD review of draft-ietf-shim6-multiho… Miika Komu
- Re: [shim6] AD review of draft-ietf-shim6-multiho… Henderson, Thomas R
- Re: [shim6] AD review of draft-ietf-shim6-multiho… Shinta Sugimoto
- Re: [shim6] AD review of draft-ietf-shim6-multiho… Miika Komu
- Re: [shim6] AD review of draft-ietf-shim6-multiho… Miika Komu
- Re: [shim6] AD review of draft-ietf-shim6-multiho… Shinta Sugimoto
- Re: [shim6] AD review of draft-ietf-shim6-multiho… Miika Komu
- Re: [shim6] AD review of draft-ietf-shim6-multiho… Shinta Sugimoto
- Re: [shim6] AD review of draft-ietf-shim6-multiho… Miika Komu
- Re: [shim6] AD review of draft-ietf-shim6-multiho… Shinta Sugimoto
- Re: [shim6] AD review of draft-ietf-shim6-multiho… Henderson, Thomas R
- Re: [shim6] AD review of draft-ietf-shim6-multiho… Shinta Sugimoto
- Re: [shim6] AD review of draft-ietf-shim6-multiho… Jari Arkko
- Re: [shim6] AD review of draft-ietf-shim6-multiho… Shinta Sugimoto