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

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

Shinta, some more responses inline below

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

Yes, but I meant that applications send data by send, sendto, or sendmsg, and SHIM_LOC_*_SEND are set as socket options, not as ancillary data to sendmsg().  So it seemed to me that case 1) becomes case 2).

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

Can you explain the difference between SHIM_LOC_LOCAL_PREF and SHIM_LOC_LOCAL_SEND?  To me, it is the difference between SHOULD and MUST.  It seems to me that if you make SHIM_LOC_LOCAL_SEND either a MAY or a SHOULD, it becomes basically the same as SHIM_LOC_LOCAL_PREF, and applications can't tell the shim that they insist on specific locators being used (regardless of what REAP, ICE, etc. may learn).

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

If SHIM_LOC_*_SEND are not possible to be set before a shim6 context is set up, then I agree that it seems to not make a difference.

- Tom