Subject: Re: [nbs] I-D Action:draft-ubillos-name-based-sockets-03.txt

From: Brian E Carpenter <[email-masked]>
Date: Sun, 17 Oct 2010 16:49:46 +1300

Hi,

A few comments on the draft:

>    Once the name exchange has been performed successfully the complete
>    feature set will be made available to the communication
>    automatically.

That sentence makes me feel very hungry. What are those features
and where are they discussed?

> 4.1.  Name format
> 
>    Names can be provided in any of three ways.
> 
>    o  FQDN.  The Fully Qualified Domain Name of the host.  This will
>       allow e.g.  DNSsec to provide authenticity of the name.

Actually, doesn't DNSSEC prove authenticity of the name==address(es)
equivalence? The name itself is just a character string.

> 
>    o  ip6.arpa.  Using one of the hosts interfaces addresses as a name.

Why would I want to use this?

> 
>    o  Nonce.  A one-use only session identifier.

That really needs a lot more explanation.

In general the draft can't stand alone; it needs an NBS
architecture document to go with. I'm sure that can be built
out of Christian's existing document.

> 6.  Security Considerations

Maybe it doesn't belong here, but we need a threat analysis,
so that we can figure what the security issues are, and
to what extent DNSSEC solves them.

Regards
   Brian Carpenter

---

From: Javier Ubillos <[email-masked]>
Date: Tue, 19 Oct 2010 15:03:03 +0200

Hi Brian!
Thanks for the comments :)

> and where are they discussed?

Hungry is good :)
A good storyteller knows when to stop to keep his audience wanting
more ;)

The short answer is: so far, it is only the potential features mentioned
in e.g. the abstract.

I'm planning to revise the document and make a division between
un-lateral features and bi-latera.
Un-lateral ones are e.g. the API and IPv4/IPv6 agosticism (application
does not need to bother) and bi-lateral are e.g. the shim6 extension or
some future NAT-traversal solution.

> equivalence? The name itself is just a character string.

You're right. I'll make it more clear that what is authenticated is the
name -> address mapping.

> Why would I want to use this?

Another thing I should be more explicit about.
This is a construct for when a host does not have a name associated with
it. Then a name can be synthesized for it.
API-wize, the scenario could be that the IP is provided in a canonical
(sockaddr?) way, and internally is represented by a string.
This is an issue we're discussing.

> out of Christian's existing document.

I agree. I would like to have an architecture draft and a draft for
every separate function (where the API would be its own draft).
I have the intention of doing this, it's on the to-do list.

> to what extent DNSSEC solves them.

I completely agree.
Both on the need and on whether or not this is the correct place for it.
I think such an analysis should cover the situation with and without
DNSSEC.

Again, thanks for the comments!

// Javier

---

From: Rémi Després <[email-masked]>
Date: Tue, 19 Oct 2010 16:03:19 +0200

Le 19 oct. 2010 à 15:03, Javier Ubillos a écrit :
>>> ...

Since translations from addresses to names are generally time consuming, and not necessarily as up to date as those from names to addresses, this should, as  minimum, be an option that applications would have to request.

Regards,
RD

---

From: Javier Ubillos <[email-masked]>
Date: Tue, 19 Oct 2010 16:15:26 +0200

> Since translations from addresses to names are generally time consuming, and not necessarily as up to date as those from names to addresses, this should, as  minimum, be an option that applications…

The whole reverse-resolution/ip6.arpa infrastructure is not very broadly
deployed.

The way I see it, it's comparable with a nonce, but which _might_
contain some valuable extra information (the IP the communication was
started with).

Also, i6.arpa -> name could very well generate multiple answers. How do
you know which one is right.

In other words, this is not a huge deal, the intention is to _maybe_
provide something that _might_ be more informative than an arbitrary
label.
If too many finds that it is just confusing and an eye-sore, we'll have
to reconsider that possibility.

// Javier

---

From: Javier Ubillos <[email-masked]>
Date: Wed, 20 Oct 2010 15:44:30 +0200

Rémi and Jan.

About the whole "synthesized ip" issue.

I have thought about it a lot and I'm curious as what you think about
the methods along the following lines of thought.

The reason I like the synthesized addresses at all is that it's easy to
derive from something innate to the host. You don't need any
pre-negotiation and it _might_ be better than a randomly generated
nonce.

However, two issues have made me rethink a bit:
* When working with TCP, two names on the same host cannot share IP:Port
pairs. The remote host, if it is not upgraded, wouldn't be able to
distinguish the two flows. There for, a host needs some book-keeping
mechanism to keep the 4-tuples unique.
* Locally, we need the session-identifier to be unique as well to be
able to keep the separate sessions distinct, but also manageable so that
sessions who wish to multi-home/multi-path are able to find and re-use
the correct session label.

So, in other words:
We need to be able to keep a record of which sessions use which
srcIP:dstIP:srcIP:dstIP pairs (or whichever identifier a particular
protocol uses)

What needs to be solved is:
* How to name unnamed nodes
* How to generate sensible session-labels
   * To be able to separate sessions
   * And still allow to aggregate "sub-sessions" (e.g. a multi-path
sessions)

Personally, I think "sub-sessions" are a non-issue, as in the multi-path
TCP case, we can still run standard TCP-sockets as each sub-socket to
the master-socket which will need a session-label.

A thought I'm playing with is to use a combination of a synthesized
names and SRV-record syntax. 
This is an incomplete solution, let me show by an example:

Host A communicates with Host B.
Host A has IP(A) and wants to talk TCP/HTTP to B.
So, it generates 

src name: _<sourceport>._tcp.<IP(A)>.ipv6.arpa
dst name: _http._tcp.<IP(B)>.ipv6.arpa
src IP: IP(A)
dst IP: IP(B)
src Port: _<sourceport>
dst Port: 80

This way, when spawning new sockets, one can by just looking at the
local name, avoid ip:port conflicts.

However, this breaks in the mobility case, where this generated name no
longer has a relation to the ip:port pairs used.

Do any of you have any good suggestions on how to achieve the goal?
Perhaps an overlap in session-labels is not a problem at all (maybe we
can separate sockets at an application level, where no two applications
may interfere with each others sockets...

Do you guys have any good ideas/suggestions?

// Javier

---

From: Rémi Després <[email-masked]>
Date: Wed, 20 Oct 2010 16:01:34 +0200

Javier,

What about a face to face discussion in Beijing, with the few people expressing interest for an NBS approach?
(On an issue like this one, I find it difficult to converge by e-mail. At this point, it is still too complex.)

Regards,
RD

---

From: Javier Ubillos <[email-masked]>
Date: Wed, 20 Oct 2010 16:36:51 +0200

> (On an issue like this one, I find it difficult to converge by e-mail. At this point, it is still too complex.)

Face-to-face sounds great :)

I wouldn't use the activity on this list as a gauge for interest in
name-oriented solutions.

I think there are still lost of issues to solve. Perhaps even major
changes.

However, I think the major goals still remain:
* Making usage of network-"stuff" easier for developers
* Finding a different (better?) deployment strategy 

Different from similar solutions who are already out there, providing
similar features.
I'm thinking of e.g. HIP, which does more or less the same, but in a
shimming-layer. Or e.g. LISP, which also provides similar features, but
_in_ the network.

// Javier