RE: CPEs -- security

[Christian Huitema <huitema@windows.microsoft.com>]

In a fairly large message, Iljitsch asks questions on multiple topics. I will focus here on the security subset of these questions:

> Security
>
> 1. Do we all agree that a model where there is stateful filtering by
> default, but applications can request incoming sessions is what we
> should aim for?
>
> 2. Or should the opening up of incoming ports go through the OS,
> rather than be signalled directly from applications to the CPE?
>
> 3. Should a host have the option of signalling to a CPE that it
> doesn't require any filtering?

I agree with Iljitsch assessment of the state of the market. Stateful filtering in the CPE is technically useless and gets in the way, but there is probably no way to sell a CPE today that doesn't do it. So, whatever model we have has better assume that there is filtering by default in the gateway. The debate should then go on the possible ways to bypass that filtering. So the answer to the questions would be:

1) Assume that there is stateful filter somewhere in the network, because we cannot anymore stop it than stop the rain from falling. (On the other hand, the IETF should not encourage rain to fall and routers to meddle with traffic.) As a corollary, assume that there need to be a way to empower all applications.

2a) The decision to empower applications rightly belong to the user. The user should make a conscious arbitration between the benefits derived from the application, and the exposure created by running that application. Whether the application uses its own code to achieve that or whether it is built using system components is irrelevant. As a matter of fact, modern operating systems incorporate built-in firewalls and can control which applications are exposed to the network, or not. In any case, the IETF should not be concerned with the internal architecture of end systems, and should not engage in a debate on the split of functions between application, OS, libraries, host firewalls and other common services.

2b) The solutions that do work well in practice, like STUN and Teredo, are those that do not require any explicit signaling between the end system and the gateways or firewalls. Explicit signaling has a mediocre record of working when the system is directly connected to the gateway -- UPNP, for example, ends up working in maybe two thirds of such deployments. Explicit signaling just does not work when the router is several hops away. If the problem is "how to cross stateful filtering routers", the solution has to be "create state", probably by sending sacrificial packets along the path in order to "open the filters".

3) Yes, there should be an option for hosts to signal that they have implemented their own "internal firewall", and would rather not use the services of the router. In the design team discussions, two options where raised to that effect. One was to allow IPSEC through by default, with the reasoning that a host implementing IPSEC also has its own internal firewall. The other was to allow communication with privacy addresses, with the reasoning that privacy addresses are randomized, and thus are least likely to be attacked by Internet scanning worms.


-- Christian Huitema