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

[Shinta Sugimoto <[e-mail]>]

Hi Thomas,

Thanks for your comments and please find my responses inline. 

> -----Original Message-----
> From: Henderson, Thomas R [mailto:[e-mail]] 
> Sent: Sunday, December 20, 2009 1:34 AM
> To: Shinta Sugimoto; Brian E Carpenter
> Cc: [e-mail]; Kristian Slavov; [e-mail]
> Subject: RE: Unknown locator [WG Last Call 
> fordraft-ietf-shim6-multihome-shim-api]
> 
> 
> 
> > >
> > > 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.

1) means that application sends data by specifying source (or destination) locator, e.g., by using SHIM_LOC_*_SEND socket options.  Of course, the socket is bound to identifiers.  But the app can optionally specify source and/or desination locator(s).  This is what we call "locator management" and we define socket API extensions for enabling this function.

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

I understand.  I am not quite sure if we should say MAY or SHOULD here, but I think application should be fine as far as it knows if the requested locator was accepted or not (by the multihoming shim sub-layer).  The acceptance means the result of the first check, i.e., availability of the source locator.  Reachability from the source locator in question to the peer's locator, is another issue, IMO.  So, what about this:

- the multihoming shim sub-layer MUST return the result to the application (whether the request for updating the source locator was accepted or not. When it is accepted, it means that the locator list is updated accordingly. When it's rejected, no changes to the locator list).
- when the request for updating the source locator was accepted, the multihoming shim sub-layer SHOULD initiate the procedure to update the locator list accordingly.

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

Ok, I think this point is where we have significant difference with HIP and SHIM6.  Identifiers are non-routable in case of HIP.

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

Ok, I understand.

Then we should probably prepare an exceptional case for HIP when the app requests to use specific destination locator(s) for a given application session even when there is no context associated with the socket.  Such a case should be the initial case where the app starts communication with the peer using HIP.
 
> 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.

Ok.  Let me come back with a proposal soon (tomorrow at the latest).  I guess we should have separate email thread for this topic.

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

Well, the conflict actually does not matter.  The IP address used for bind() is the source identifier, and the IP address used for connect() is the destination identifier.  As you mentioned, identifier and locator could be identical, or could be different.  SHIM_LOC_LOCAL_SEND will give the source locator and SHIM_LOC_PEER_SEND will give the destination locator.

Regards,
Shinta