Subject: [homenet] Tunnels to home

From: Brian E Carpenter <[email-masked]>
Date: Thu, 09 Aug 2012 11:01:30 +0100

All this talk about tunnels and names made me think that people
might be interested in the Signpost project, mainly based at
the Computer Lab in Cambridge where I am currently a visitor.
I think this project is a proof of concept for ideas being
discussed here.

http://conferences.sigcomm.org/sigcomm/2012/paper/sigcomm/p83.pdf

(10MB file) http://conferences.npl.co.uk/satin/presentations/satin2012slides-Madhavapeddy.pdf

Regards
   Brian Carpenter

---

From: Michael Richardson <[email-masked]>
Date: Thu, 09 Aug 2012 11:01:25 -0400

I think that this research is bang: the reason we couldn't do
Opportunistic Encryption (RFC4322) was because we had no identity, not
even local identity.
(The fact that reverse DNS was hard to get control of was a clue
to this.  The fact that NAT makes reverse DNS ambiguous was just
an additional complexity, but for many it seemed like the initial
complexity) 

>>>>> "Brian" == Brian E Carpenter <[email-masked]> writes:
    Brian> All this talk about tunnels and names made me think that people
    Brian> might be interested in the Signpost project, mainly based at
    Brian> the Computer Lab in Cambridge where I am currently a visitor.
    Brian> I think this project is a proof of concept for ideas being
    Brian> discussed here.

    Brian> http://conferences.sigcomm.org/sigcomm/2012/paper/sigcomm/p83.pdf

    Brian> (10MB file) http://conferences.npl.co.uk/satin/presentations/satin2012slides-Madhavapeddy.pdf

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 12 Aug 2012 15:34:18 -0400

In message <[email-masked]>
 
> (10MB file) http://conferences.npl.co.uk/satin/presentations/satin2012slides-Madhavapeddy.pdf

Remove NAT and the work has no purpose.

Curtis

---

From: Michael Richardson <[email-masked]>
Date: Sun, 12 Aug 2012 17:09:43 -0400

>>>>> "Curtis" == Curtis Villamizar <[email-masked]> writes:

    Curtis> Remove NAT and the work has no purpose.

I don't quite agree.
The external rendezvous is *FORCED* by NAT.

The need for a rendezvous goes away with IPv6 end to end, assuming that
security policies allow.  

But, if we assume that end users should never type IPv6 addresses, then
a rendezvous (which might now, be hosted by one or more devices at the
home, rather than in the cloud!!!) is something that very much
facilitates use by regular users.

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 12 Aug 2012 18:07:49 -0400

In message <[email-masked]>
Michael Richardson writes:
 
> >>>>> "Curtis" =3D=3D Curtis Villamizar <[email-masked]> writes:
>     >>=20
>     >>=20
>     >> (10MB file) http://conferences.npl.co.uk/satin/presentations/satin20=
> 12slides-Madhavapeddy.pdf
>     >>=20
>     >> Regards
>     >> Brian Carpenter
>  
> security policies allow.=20=20
>  
> Michael Richardson <[email-masked]>, Sandelman Software Works=20

You are assuming that DNS would never be available to the home when
you state that "But, if we assume that end users should never type
IPv6 addresses".

This is technically solvable with IPv6, no NAT, and DNS.  If some
users end up typing IPv6 addresses for lack of DNS cooperation from
their provider, they may consider switching providers.

Even without cooperation from the provider, a device can have the
resolver pointed at the home DNS server as a means of rendezvous if
you want a rendezvous in the home.

Curtis

---

From: Richard Mortier <[email-masked]>
Date: Mon, 13 Aug 2012 09:37:09 +0100

hi all; i'm coming into this discussion partway through, so apologies
if i miss/repeat anything. i'm one of the collaborators on signpost
(the non-cambridge collaborator in fact :)

>> >>>>> "Curtis" =3D=3D Curtis Villamizar <[email-masked]> writes:
....
>> facilitates use by regular users.

yes- "regular users" is precisely the constituency we're aiming for :)
 i guess we're also assuming that the move to ipv6 will continue to
happen for some time yet, though i think that some of the other
motivations for signposts will persist even in a fully ipv6 world (see
below).

> their provider, they may consider switching providers.

part of -- perhaps the main part of -- the motivation for signposts is
making things easy enough for the regular users who don't know what
any of that means.

> you want a rendezvous in the home.

i should also point out that we thought there were more
motivations/uses for signposts that simply nat punching, or even
security acl punching, etc.  though i'll admit some of these got
rather compressed in the 2 pager brian pointed to - that's the
abstract for the demo we should have tomorrow at sigcomm (for anyone
who's here in helsinki! :) as we don't have a better, more detailed
paper published yet.

i guess the other two main motivations from our perspective were:
better support for mobility; and secure identities for users. (both
may be a bit tangential to the purpose of this list though.)

by the former i mean: as you move around between home, work, town,
public transport, etc you want to be using the best available path, or
paths (fsvo "best") -- the way signposts uses dns should help ensure
that your device selects among available paths based on metrics like
throughput, latency, jitter as you move between wifi, 3G, or whatever
else network. the motivating scenario here was when travelling with
laptop and mobile phone or tablet which may well end up being visible
to each other on the same (third party) network. we've also thought a
bit about using this to support interesting uses of tcp multipath.

by the latter i mean: using dnssec as a way to bootstrap secure
internet identities for individuals. being able to authenticate the
person (as represented by a dnssec domain entry) at the other end of
the connection (whether the initiator or the target) seems like it
would be useful. and dnssec seems a more secure basis for this than
relying on plain old email. ideally we would also then use the secret
material that is used to register in dnssec to automatically derive
other secrets for ssh etc, but we're still working out the details of
that.

-- 
Richard Mortier
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Mon, 13 Aug 2012 13:04:10 -0400

One of the things that I was thinking about years ago when DNSSEC was
young, and mDNS was first talked about was using mDNS to exchange DNSSEC
chains for FQDNs.

So, you and I, sitting in a meadow (I always think about Bloom
County... in this context) change use mDNS to find each other, and then,
I can give you an additional area like this:

.                       172800  IN      DNSKEY  256 3 8 AwEA...
gov.			86400   IN      DNSKEY  256 3 7 AQO+tGAvoICmi...
whitehouse.gov.		7200    IN      DNSKEY  257 3 7 Av//sEnVpZw40...
billthecat.whitehouse.gov.  60  IN      DNSKEY  257 3 7 FOOBAR

which would permit you to validate who I am, even though neither of
have connectivity at the time.. I would cache my DNSSEC path, and of
course, we each would already have the root DNSSEC key. (no different
than how PKIX works...)

I see signposts as being additional local trust anchors that can be
used.

---

From: Richard Mortier <[email-masked]>
Date: Wed, 15 Aug 2012 14:07:39 +0300

On 13 August 2012 20:04, Michael Richardson <[email-masked]> wrote:
...
> I see signposts as being additional local trust anchors that can be

yes, i think we would too :)

specifically: in the "common case" we'd envisage that each person
would have at least one publicly visible signpost, probably hosted in
the cloud (whether or not operated directly by them, or through some
"signpost-as-a-service" provider) unless they have suitable local
resources.

but we have certainly discussed supporting suitable state
replication/caching among signpost instances so that any
locally-connected collection of signpost-enabled clients can do all of
this without recourse to the public internet (eg., for cases where you
still want to be able to interconnect your own devices and you're
travelling, or you're at home your broadband uplink has gone down).

-- 
Richard Mortier
[email-masked]

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 15 Aug 2012 14:30:46 -0400

In message <[email-masked]>
 
> yes, i think we would too :)

You did trim out the example, where due to the trust, whitehouse.gov
and billthecat.whitehouse.gov are all DNSSEC signed domains.  I
suppose that is why the smiley.

> "signpost-as-a-service" provider) unless they have suitable local

... and the difference between signed untrustworthy source of
information and an unsigned untrustworthy is ... what?

This is putting yet another service in the cloud that need not be
there, though global DNS could be considered "in the cloud" as
commonly practiced for the home user.

What we are trying to accomplish is getting a local name service that
is somehow authoritative for the local site, and optionally can be
made global.

Putting the mapping to the local printer in the cloud would break
printing if the cloud were not accessible (hopefully temporarily) but
for some devices, like home alarms, utility metering, the fridge,
... the kitchen sink, with low power wireless, the cloud might often
not be there.

> travelling, or you're at home your broadband uplink has gone down).

Please give us a good reason to reinvent the wheel.  I don't see one.
You need to say what DNS can't do, possibly with some extension. that
signpost offers.

> [email-masked]

Regards,

Curtis

---

From: Anil Madhavapeddy <[email-masked]>
Date: Sat, 18 Aug 2012 10:46:02 -0700

> You need to say what DNS can't do, possibly with some extension. that

I think you're missing the point.  Signposts *is* a DNS(SEC)-based
implementation and not trying to invent a new protocol, but has a
very different focus from conventional DNS servers (personal tailored
DNS for the individual).

The server currently distributes presence information out-of-band
to the other authoritative server for that domain (using the tunnels
it has setup between devices).  This means that you can have an
authoritative server for your domain within your home network, which
continues to function offline if disconnected from the wider Internet.
When reconnected, it will resync with other nodes (in a loosely
consistent way, which may result in a few tunnels being non-optimal,
but only briefly).

This'll be much more obvious as soon as we release some working code,
which we're furiously hacking on at the moment.

-anil

---

From: Richard Mortier <[email-masked]>
Date: Sat, 1 Sep 2012 07:36:13 +0100

(apologies for the delay replying, have been catching up after a trip away.)

> suppose that is why the smiley.

the smiley is because (as anil's reply said), signpost uses dnssec
precisely to get that trust. a smiley of agreement if you will.

> information and an unsigned untrustworthy is ... what?

not sure what you mean here - could you expand?

> ... the kitchen sink, with low power wireless, the cloud might often

we view both the local and global (ie., visible to the public,
probably hosted in the cloud in most cases) as part of the same
federated service. the local service (eg., at home) will continue to
work if you are disconnected. the global service provides for access
to the "local" services from outside that physical network.

-- 
Richard Mortier
[email-masked]