Re: comment on: draft-ietf-v6ops-unman-scenarios-00.txt

[Keith Moore <moore@cs.utk.edu>]

> >> Is there any reason why we can't recommend strongly that the router
> >> for an unman network should incorporate a firewall with most ports
> >> closed by default, and opened manually on demand, as with most
> >> personal firewall products?
>  
> Yes, there is a reason. On a PFW, you get an API for opening a port. On a
> home gateway, you may get midcom eventually, but you most probably have some
> kind a gateway specific manual configuration interface. 

mumble.  both the API and midcom seem equally unsatisfactory.  if you trust
apps to be secure, what's the purpose of the firewall?  and if you don't trust
the apps to be secure, how is giving them an API going to make them more
secure?  manual configuration is a pain, but at least it puts the trust
decision elsewhere.

> And Keith added:
> > this is similar to what I've been thinking.
> 
> A lot of this discussion is based on the assumption that if a host is
> provided with IPv6 connectivity, all the host services suddenly become
> accessible over IPv6. Well, this is not necessarily the case. (It is
> definitely not the case with Windows XP.) For example, some applications may
> not be accessible over IPv6, or may be programmed to only accept local
> connections, either from a scoped address or from a local prefix. So, in
> practice, the danger is not quite as large as you may think.

well, by the time this stuff gets deployed nobody is going to be using XP
anyway :)

again, if we can't trust the apps to be secure just because they invoke some
API to open up a firewall, I don't think we can trust them to be secure just
because they listen on a v6 socket.

> My main issue with a "firewall all the ports" recommendation is that it
> perpetuates the firewall based security model, and that it also assumes that
> by default an unmanaged host should only behave as a client. This negates
> one of the main advantages of IPv6, i.e. the provision of global addresses
> and the ability for all hosts to behave as "servers" or "peers". 

I share this concern.  And yet the problem of insecure applications is very
real and widespread, and it's not going to go away just because we wish IPv6
to be more flexible.

> The bottom line is, one has to be very cautious with blanket
> recommendations, and we should not necessarily recommend a "client only"
> configuration.

I think there's a difference between recommending that hardware have a certain
capability and recommending that it be used.

Keith