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

From: "Christian Huitema" <[email-masked]>
Date: Sun, 19 Jan 2003 13:35:59 -0800

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

---

From: Alain Durand <[email-masked]>
Date: Sun, 19 Jan 2003 14:41:33 -0800

On Sunday, January 19, 2003, at 01:35 PM, Christian Huitema wrote:

> 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.

A lot of this discussion is based on the observation that hosts are 
often
ill-configured (or their default configuration is not secure) and the
application running on them are often not as secure as they should be.

Now, that said,some systems are better than others, and I'm willing
to accept that system and application designer can do the right thing.

However, IMHO, the issue should be documented in
draft-ietf-v6ops-unman-scenarios.

	- Alain.

---

From: Keith Moore <[email-masked]>
Date: Mon, 20 Jan 2003 06:35:52 -0500

> 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.

> 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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 20 Jan 2003 14:48:29 +0100

Philosophically, I agree with Christian. But in the real
world (where we see a fair amount of FUD and paranoia), I
think I agree with myself and Keith. Indeed, such a router
would have to come with a distributed GUI so that to the
user, it looks exactly like today's personal firewalls.

I agree we should be cautious about recommendations, but
at the minimum we must describe at least one solution that
is safer than NAT.

   Brian