Re: [nbs] A suggestion for an "on-demand API".

[[e-mail]]

On (12/16/10 12:48), Javier Ubillos wrote:
> > >    * B requires authenticated connections.
> >=20
> > If B is the passive side of the connection, how would it mandate that
> > it requires authenticated connections e.g., if it got a SYN without
> > a name, what should it do? (I think this also brings us back to Erik's
> > original point about exposure to DOS)
> 
> In the TCP scenario, the SYNACK would include a name-extension header
> (or some similar mechanism) with some flag requiring the initiator to
> send whatever is necessary for authentication. In the simplest-case this
> could be a name-extension header with a resolvable name (FQDN).
> As we are still using IP "on-the-wire", and I think the syn-cookies may
> not use the names in the hashes, I don't think any new weaknesses are
> introduced.=20

I'm not sure I see what you have in mind since the details have to be
fleshed out, but I dont see how, for example, B can require authenticatation
of, e.g., udp. 

> 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