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 :)
On 12 August 2012 23:07, Curtis Villamizar <[email protected]> wrote: > > In message <[email protected]> > Michael Richardson writes: > >> >>>>> "Curtis" =3D=3D Curtis Villamizar <[email protected]> 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. 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). > 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. 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. > 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. 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 protected] _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
