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

[Shinta Sugimoto <[e-mail]>]

Hi Thomas and Miika,

Thanks for your comments and clarifications. Please find my comments inline.

Henderson, Thomas R wrote:
> 
>> -----Original Message-----
>> From: Miika Komu [mailto:[e-mail]]
>> Sent: Friday, October 08, 2010 4:35 AM
>> To: Jari Arkko
>> Cc: Shinta Sugimoto; shim6; [e-mail];
>> 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?

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

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

Yes, I think you are right. This was pointed out by Jari too and I plan 
to update the draft by defining another error code (to distinguish 
invalid locators in the security (HBA) sense from invalid locators in 
reachability sense).

Regards,
Shinta

> - Tom
> 
>