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

"Henderson, Thomas R" <> Tue, 12 October 2010 17:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD47D3A68DA for <>; Tue, 12 Oct 2010 10:53:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -104.418
X-Spam-Status: No, score=-104.418 tagged_above=-999 required=5 tests=[AWL=-1.807, BAYES_00=-2.599, FRT_STOCK2=3.988, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9k43EbgKVxcS for <>; Tue, 12 Oct 2010 10:53:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C11723A6A0F for <>; Tue, 12 Oct 2010 10:53:57 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o9CHsgKS023250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Oct 2010 10:54:47 -0700 (PDT)
Received: from (localhost []) by (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o9CHsggj017951; Tue, 12 Oct 2010 10:54:42 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o9CHsgTu017938 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 12 Oct 2010 10:54:42 -0700 (PDT)
Received: from ([]) by ([]) with mapi; Tue, 12 Oct 2010 10:54:41 -0700
From: "Henderson, Thomas R" <>
To: "'Miika Komu'" <>, Jari Arkko <>
Date: Tue, 12 Oct 2010 10:54:40 -0700
Thread-Topic: [shim6] AD review of draft-ietf-shim6-multihome-shim-api
Thread-Index: Actm3PZjU71NZIcsRwqgaIQf3TeOcQDUR9tA
Message-ID: <>
References: <20100816114202.1241.59079.idtracker@localhost> <4C692876.60802@> <> <4C69DE84.80107> <> <> <> < t> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: shim6 <>, "" <>
Subject: Re: [shim6] AD review of draft-ietf-shim6-multihome-shim-api
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SHIM6 Working Group Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Oct 2010 17:53:59 -0000

> -----Original Message-----
> From: Miika Komu []
> Sent: Friday, October 08, 2010 4:35 AM
> To: Jari Arkko
> Cc: Shinta Sugimoto; shim6;;
> Henderson, Thomas R
> Subject: Re: [shim6] AD review of draft-ietf-shim6-multihome-shim-api

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

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

Regarding Section 13.1.2 (also sections 5.9, 5.11, 6.2-- anywhere that EINVALIDLOCATOR is being returned on a destination address), this discussion triggered some questions in my mind as to how this is assumed to work.  If an application proposes some peer locators to the shim, should the setsockopt or sendmsg calls block until the addresses are verified?  If the socket is non-blocking, should sendmsg() return EWOULDBLOCK if the locator is unverified?  Note that it may be clearer to refer to them as unverified rather than unknown locators, in the case of destination addresses.

- Tom