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

["Henderson, Thomas R" <[e-mail]>]

> >
> > Well, I don't quite understand how an extra locator provided
> > by the upper layer can ever pass the CGA/HBA test. So I don't
> > really understand the unknown locator mechanism, I guess.
> > Maybe it can never work in the case of SHIM6 or HIP but might
> > work with some other kind of shim?

I think it will work with HIP, perhaps not with shim6.  My original read of the draft was that this case of the shim rejecting a locator provided by the application was covered by returning an error EINVALIDLOCATOR (see the very end of Section 5 of the draft).

It seemed to me that the open issue in practice is to be able to pass the knowledge of a new possible locator that was provided by the application to the shim layer, and might then need to be communicated via some kind of upcall to a user-space daemon doing reachability tests, etc.  However, such an upcall is outside the scope of this draft.

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

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

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

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

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

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.

- Tom