[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: comment on: draft-ietf-v6ops-unman-scenarios-00.txt
Brian asked:
>> 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.
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.
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".
There are other security models than port filtering at a server. One of them is precisely the "personal firewall" that Brian mentions. If the host is equipped with a personal firewall, then adding a firewall in the gateway is redondant, and in fact becomes a source of problems -- the user opens a port in the personal firewall, but the application still fails. The other security model is end-to-end IPSEC, which is arguably more powerful than port filtering.
The bottom line is, one has to be very cautious with blanket recommendations, and we should not necessarily recommend a "client only" configuration.
-- Christian Huitema