[nbs] Name->Locator validation. (Was: Re: A suggestion for an "on-demand API".)

[Javier Ubillos <[e-mail]>]

On Fri, 2010-12-17 at 18:13 -0500, [e-mail] wrote:
> > I don't think names should be re-verified. However, if there would
> be a
> > reason for doing this, it could either be triggered/configured by
> the
> > application or be a default for whichever name-resolution mecanism
> one
> > chooses. In the DNS/FQDN case, I don't see why one would need to
> > re-verify the mapping during the session. If it is due to
> impersonation
> 
> If we store name(A)  with IP(A) for a connection what assertion can we
> make about the state of the system at any instant in time: if
> name(A) and IP(A) diverge, how does one make sense of the 
> observed internal state?
> 
> Stepping back a bit, in your original mail, you had said:
> 
> > At IETF79, at some point after the name-based sockets BoF.
> > Together with Erik Nordmark and Christian Vogt, we sat down,
> discussed a
> > bit about name-oriented APIs and gravitated towards this idea:
> > The cost for behavior and an API should be incremental and optional,
> in
> > the sense that; you should only pay the price for a feature if you
> > really want to have it.
> > E.g.
> > * A web-server only requires a session-handle, the web-server will
> reply
> > to any-one initiating a session. No "extras" are asked for.
> >
> > * Some other application might require authenticity of name->IP
> binding,
> > and is also prepared to pay the cost for that authenticity
> (typically a
> > round-trip).
> 
> I'd interpret that as 
> 
> - a vanilla version of AF_NAME would just move the DNS and addr
>   resolution (currently done in user space, to obtain the addrs needed
>   for setting up AF_INET[6] sockets) under the hood (i.e., behind the
>   socket(..AF_NAME) implementation)
> 
> - if the application desires, the API should allow the socket
>   end-points to exchange names and do any authentication needed, but
>   afaict this can only be done after any intial connection
>   setup/validation etc steps have been completed. Also, it seems to me
>   that if we associate a name with any connection, that name must
> also 
>   be tied to a "last verified timestamp" of some sort, in order for it
>   to be meaningful- that would allow then applications to decide the 
>   when/where/how-often of authentication.  Does that make sense?
> 
> --Sowmini 

I think this is a very sensible idea.

The basic question is, is it enough with the name->locator binding being
OK in the beginning of the connection or must it be valid throughout the
connection.

Having a "last verified time-stamp" makes it very explicit that the
name->locator binding was valid at that given point in time.

This leaves it open for a continual polling to the nameing system if
that is what is required by that nameing system and the application.

It also leaves it open to the application to decide whether or not it is
OK to have a valid name->locator binding at the beginning of the
connection or not.

// Javier