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

"Henderson, Thomas R" <> Wed, 13 October 2010 14:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5E8533A6956 for <>; Wed, 13 Oct 2010 07:40:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -104.302
X-Spam-Status: No, score=-104.302 tagged_above=-999 required=5 tests=[AWL=-1.691, 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 QWDcPhMKK82E for <>; Wed, 13 Oct 2010 07:40:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 727A33A6A07 for <>; Wed, 13 Oct 2010 07:38:43 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o9DEdUHn026703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Oct 2010 07:39:35 -0700 (PDT)
Received: from (localhost []) by (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o9DEdTH5008660; Wed, 13 Oct 2010 09:39:29 -0500 (CDT)
Received: from ( []) by (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o9DEdTqC008627 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 13 Oct 2010 09:39:29 -0500 (CDT)
Received: from ([]) by ([]) with mapi; Wed, 13 Oct 2010 07:39:29 -0700
From: "Henderson, Thomas R" <>
To: "'Shinta Sugimoto'" <>
Date: Wed, 13 Oct 2010 07:39:28 -0700
Thread-Topic: [shim6] AD review of draft-ietf-shim6-multihome-shim-api
Thread-Index: Actqsk/nf1RvAll4SLCP6+FV8rSxiwALviyw
Message-ID: <>
References: <20100816114202.1241.59079.idtracker@localhost> <4C692876.60802@> <> <4C69DE84.8010 7> <> <> <> <86C69B19-D385-46A9-B116-5EE198273305@apnic.n e 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: 'Miika Komu' <>, 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: Wed, 13 Oct 2010 14:40:29 -0000

> -----Original Message-----
> From: Shinta Sugimoto []
> Sent: Wednesday, October 13, 2010 1:35 AM
> To: Henderson, Thomas R
> Cc: 'Miika Komu'; Jari Arkko; shim6;
> Subject: Re: [shim6] AD review of draft-ietf-shim6-multihome-shim-api
> Hi Thomas and Miika,
> Thanks for your comments and clarifications. Please find my
> comments inline.
> Henderson, Thomas R wrote:
> >
> >> -----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
> >>
> > <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.
> Yes, that is correct. We specify that there must be shim context
> associated with the socket. Otherwise, the socket option does
> not take
> effect. Removing the requirement (i.e., removing a need to have an
> associated shim context with the socket) will cause problems I think.
> For instance, it is impossible for the kernel to return error code
> (e.g., EINVALIDLOCATOR) when the setsockopt() is called as the kernel
> has no idea about the peer's locator set. So, I think we should not
> change that.
> Another design principle that we applied to the API is that
> the socket
> must be "connected" so that the socket options to take
> effect. This is
> because it is impossible for the kernel (more specifically, the
> multihoming shim sub-layer) to return the result of the
> request made by
> the application because the kernel has no idea about the EID
> pair (note
> that EID pair is known by the kernel when the application
> actually sends
> data in the case of unconnected socket). I don't think we
> should change
> the design principle either.
> Talking about the HIP case we are discussing now, I think there is a
> contradiction. The API requires that the socket must be "connected".
> However, the socket is supposed to be in a unconnected status
> when the
> application issues the API call to specify the peer locator
> because the
> HIP exchange has not been taken place yet. Maybe I am missing
> something
> here. If so, please correct me.
> For the above reason, I think that we cannot use SHIM_LOC_LOCAL_SEND
> socket option (or ancillary data) for the purpose of specifying the
> initial peer locator for the HIP case.
> If there is a need for application to specify the initial locator, it
> should be a defined separately, I think. And that is HIP
> specific. The
> scope of this document is to define a *common* set of API
> required for
> HIP and SHIM6, so I think it's outside the scope of this
> document. Comments?

My sense is that it would be OK to proceed in that manner but that
we probably need to take a pass through this document and the
HIP API document to make sure that the scope and relationship
between the documents is clearer.

An analogous situation is present in normal sockets in which
the common socket API has different semantics when the underlying
transport is datagram or stream.  In that case, there is a family
of functions (e.g. getprotoent) that can report to the client
what type of socket it is.  I am wondering whether SHIM_ASSOCIATED
should be expanded along those lines to tell the client what
underlying shim type is present (or whether the rules for
shim context apply or not).

> >> 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 wonder how the kernel does not know about the peer locator (IP
> address) but the application does. You mentioned that
> application could
> know the address out-of-band, but how? Do you have good examples?

I don't have any concrete examples since I don't know of
any (presently) shim-aware applications, but it is not hard
to conceive of one in which well-known IP/HIT bindings are
added to an application configuration file for bootstrapping

- Tom