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

Javier Ubillos <> Tue, 19 October 2010 13:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7B1243A6802 for <>; Tue, 19 Oct 2010 06:01:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, HELO_EQ_SE=0.35]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r3arH5M9AMkZ for <>; Tue, 19 Oct 2010 06:01:34 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8005D3A67F8 for <>; Tue, 19 Oct 2010 06:01:34 -0700 (PDT)
Received: from [] ( []) (Authenticated sender: by (Postfix) with ESMTPSA id 7763B402BB; Tue, 19 Oct 2010 15:03:04 +0200 (CEST)
From: Javier Ubillos <>
To: Brian E Carpenter <>
In-Reply-To: <>
References: <> <>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-y7oWsI9JL65Tx1Zo9Zmx"
Date: Tue, 19 Oct 2010 15:03:03 +0200
Message-ID: <1287493383.2189.89.camel@bit>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3
Subject: Re: [nbs] I-D Action:draft-ubillos-name-based-sockets-03.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Name based sockets discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 Oct 2010 13:01:35 -0000

Hi Brian!
Thanks for the comments :)

On Sun, 2010-10-17 at 16:49 +1300, Brian E Carpenter wrote:
> 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?

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.

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

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

> > 
> >    o  Using one of the hosts interfaces addresses as a name.
> 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.

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

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.

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

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

Again, thanks for the comments!

// Javier