Re: [shim6] Unknown locator [WG Last Call fordraft-ietf-shim6-multihome-shim-api]

[Miika Komu <[e-mail]>]

Henderson, Thomas R wrote:

Hi,

>> After re-thinking, I think we need to handle two cases: 1)
>> application sending data with unknown source/destination
>> locator, 2) application requesting for using unknown
>> source/destination locator.
>>
>> As to the former case, the multihoming shim sub-layer must
>> reject the request and send an error message to the
>> application.  The reason is simply because the packet with
>> unknown source locator will be dropped by the peer and
>> sending packet to unknown destination locator should be
>> prohibited for security reasons.
> 
> Can you clarify what you mean by 1)?  I thought that applications sent data to identifiers in this framework.

I think this means that e.g. application has cached a ULID (HIT, etc) 
and starts just sending data to it.

>> As to the latter case, the multihoming shim sub-layer should
>> do the following:
>>
>> In response to the request for using unknown source locator:
>>
>> - check if the requested source locator is available on any
>> of the local interface
> 
> (I would add that "available" means that it is configured on some interface and it satisfies whatever requirements are placed on its usage by the shim, such as hba).

Right.

>> - if the source locator is available, then the multihoming
>> shim sub-layer MAY initiate procedure to update its own
>> locator list with the peer
> 
> By specifying as a MAY, applications will have a hard time relying on it being available.  Applications may know best about what locators they want to use with the shim.  I'd rather see API that supported two cases:  1) locators provided as hints to the shim (where the MAY would apply), and 2) locators provided as application policy that should not be ignored; i.e. the connection should perhaps fail if the locators provided cannot be used

This could be returned in the return value of setsockopt().

At least in HIP, an unkown source locator could trigger an UPDATE with 
LOCATOR parameter being sent. An unknown peer locator, could trigger an 
ECHO_REQUEST being sent. Thomas, is the latter part going to be included 
in the new revision of RFC5206 (this was also mentioned in different 
context in the cross-family handover paper)?

(Shinta: I don't think we need to go this detailed with the API draft)

>> In response to the request for using unknown destination
>> locator, the situation is a bit tricky because it means that
>> the application somehow knows another locator (IP address) to
>> reach the peer while the multihoming shim sub-layer does not.
>>  I am not sure if we have such a case in reality, but in
> 
> this seems to me to be potentially a very common case for locator- and shim-aware applications

HIP needs this. I would assume that the application is giving hints 
because the system is unable to find a locator matching to the ULID. So, 
just saying "no" does not work for HIP even though it may work for 
routable ULIDs in SHIM6.

To be more specific, the native API for HIP assumes that the SHIM layer 
can cache locators in the following sections:

http://tools.ietf.org/html/draft-ietf-hip-native-api-09
4.1.1. HIP Wildcard Addresses
4.2.1. Resolver Usage
4.6. Explicit Handling of Locators

The native API for HIP is in IESG evaluation, so I think it would be 
nice to resolve this issue quickly.

>> theory, I think the multihoming shim sub-layer must reject
>> the request at least in the case of SHIM6.  In the case of
>> HIP, I am clarifying this with HIP experts what to do.
> 
> For HIP, I would suggest to accept it.  I think it will probably be a common case because it allows the application to provide locators to HIP so that HIP doesn't have to do an address lookup based on the HIT.

+1. I think it should be technically feasible check in the SHIM socket 
handler if the socket is bound to a AF_INET6 or or AF_HIP socket.

> I suggest to clarify what is meant by "unknown locator" perhaps in the terminology section.  I think that what is meant by the text is that there is an existing context and a locator is provided that was not announced in the context handshake or subsequent signaling.  However, what about providing a locator before any context is set up?  In this case, all locators are potentially "unknown" at this stage.  I think it is a very important piece of the API for HIP to be able to have an application associate a destination locator with a destination HIT (and also source locator for policy or reachability purposes) before the HIP handshake starts.  For shim6, before context is set up, it seems that identifiers are initial contact locators too. In this case, it should be defined what should be the behavior if bind(address) conflicts with SHIM_LOC_LOCAL_SEND or if connect(address) conflicts with SHIM_LOC_PEER_SEND.