On Sun, Mar 11, 2012 at 5:40 PM, Michael Richardson <m...@sandelman.ca> wrote:
>
>>>>>> "Cameron" == Cameron Byrne <cb.li...@gmail.com> writes:
> >> It's good to see some traction in service discovery and naming.
> >>
> >> We also have a fifth area, security. The text as it stands says
> >> a few things that apply to this area, e.g.
> >>
> >> a) An assumption of "Simple Security" with default deny on the
> >> CER. This implies PCP or uPnP to support punching holes. The
> >> text also talks about addressability vs reachability.
> >>
>
> Cameron> I still disagree with this premise that we must default
> Cameron> deny and have a mess of inadequate and complex signalling
> Cameron> to compensate . Can someone articulate a threat model that
> Cameron> requires this default deny and state tracking ? Or must we
> Cameron> put the cart before the horse without facts presented
>
> +1
>
> I think that the question as to whether or not "Simple Security"
> defaults to on is a seperate question as to whether or not "Simple
> Security" MUST be available to be turned on.
>
> Cameron> Or, can homenet simply say home devices must be
> Cameron> independently secure, may have host based firewalls, or
> Cameron> they must be placed in a properly screened subnet of
> Cameron> fundamentally flawed devices that require network security
> Cameron> controls and multi device port coordination ?
>
> so, if such a subnet is to exist (and it could be virtual thanks to
> things like NEA), then Simple Security still needs to be implemented.
>
> In my mind, to get around the "NAT is security, e2e is bad" CROWD, which
> is ALL OVER THE PLACE out there (not here at the IETF, where we are much
> more clueful. I'm talking about people with phony letters after their titles
> who have never heard of the IETF), we need to have an answer, and that
> answer must be very clearly labelled, such that it can be turned off by
> people who want it.
I have a tendency to drag discussions down into implementation details,
and I apologize in advance here for not having a high level viewpoint,
on what could be, vs what is.
I recently sat down with jg to try and implement a useful amount of ipv6,
with a useful amount of security.
The biggest problem I ran into was that nearly every useful service
had an acl that required enabling before it could be used inside the
network in the first place. In a dynamically (PD assigned) world,
this would mean that trigger scripts would have to be fired off
to alter these on every change, and daemons restarted, and
there are related problems....
the list:
polipo web proxy: acl needed to access it at all via ipv6,
needed to be blocked from the outside
bind9 - acl needed in order to distinguish between 'us' and 'them' queries,
needed a distinct ipv6 address for 'external' queries
radvd - dnssl is not widely supported on clients
dhcp - helpful to have an autoconfiguration based naming scheme -
(assign an ipv4 address, force an ra message, ping6 to see
if the device has it,
if so, add the autoconfed ipv6 address to dns)
mrd6 - specific addresses/interfaces assigned
pim - I haven't ever seen pim on ipv4 or ipv6, actually work
routing daemon (babel/ospf/whatever) - needs configuration from scratch, almost
web server - things like wpad.domain.wherever should work only on the inside
web server for router configuration - should only be available inside
dhcp-pd - big headache as yet
rsync - I LIKE rsync and don't mind it being entirely open
bidirectionally. That's me.
ssh - I trust ssh, LIKE leaving it open bidirectionally.
And the converse was also a problem:
Several other services (notably samba/cifs) were open to the world
via ipv6 by default.
I'm pretty sure these ports shouldn't be open to the world, and
the simplest way was to block them via the firewall, and not
use acls.
In addition to the above cases, the concept of having a 'guest' network
in the home complicates matters even further, as by what scheme
can you dynamically assign addresses, and retain security.
Certain devices (printers for example) should be available inside
in all cases, your accounting server or home security webcam system,
not so much....
In the polipo case, (I note that a ipv6/ipv4 capable translating web proxy
is darn useful) there is presently no way to distinguish between
an internal guest network and a normal internal network.
So I provide these cases as food for thought only. I too, would like
E2E connectivity restored, but there are some services that
should not be available out to the wild, woolly internet over ipv6.
Requiring that all ipv6 services use PCP or upnp to open an
incoming port is also a can of worms.
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
