Re: CPEs

[Rémi Denis-Courmont <rdenis@simphalempin.com>]

Le Friday 04 January 2008 14:34:38 Iljitsch van Beijnum, vous avez écrit :
> 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?

It is pretty clear at this point, that there will be stateful firewalling in 
many SOHO deployments. As such, we clearly need a hole opening mechanism. Or 
then we close the IETF transport area, and declare that there shall only be 
UDP and client-to-server TCP from now on :o

What I am really worried however is, if we don't clearly state HOW stateful 
firewalling should be done, or if we do, but vendors ignore us, we'll end up 
with the same issues as with IPv4+NAT:
- UDP working "client-to-client", but with battery-hungry short refresh 
timers,
- TCP only works client-to-server only (so client-to-client congestion control 
is non-existent at the transport layer),
- everything else does not work reliably.

> 2. Or should the opening up of incoming ports go through the OS,
> rather than be signalled directly from applications to the CPE?

I don't understand the question. The OS will always be sitting between the 
application and the CPE in any case, by virtue of providing the socket API, 
the network stacks and drivers, and possibly the local firewall.

> 3. Should a host have the option of signalling to a CPE that it
> doesn't require any filtering?

It would probably be useful in some scenarios.

> Address provisioning
>
> 4. Is implementing DHCPv6 snooping and option insertion, similar to
> what currently happens with DHCP for IPv4, a good option for vendors
> of broadband equipment, or is a provisioning solution where this isn't
> necessary preferable?

The CPE should preserve options it does not know, I suppose, for the sake of 
extensibility. OTOH, I expect many end devices will stick to ICMPv6 autoconf.

> 5. Can we assume the presence of DHCPv6 prefix delegation in CPEs?

On the upstream side, I suppose so.
On the downstream side, it would be needed for chaining of CPEs. We'd probably 
need multicast proxying as well for the same reason (see also James 
architecture proposal). 

> 6. Can we assume the presence of DHCPv6 address assignment in clients?

No.

> It's not available in most of them now, so how would we get to such a
> state and how soon?

I think we won't get to such a state that we could assume pervasive DHCPv6. 
What's wrong with giving ICMPv6 autoconf for end nodes anyway?

> 7. Is the model where there is a CPE with modem functionality but not
> router functionality a reasonable one?

Maybe it depends on the definition of CPE. There are non-routing modems, and 
there are SOHO routers without modems, and I assume they'll continue to 
exist.

> 8. Do we want to ISPs to provide RAs to customers in the case where 6
> = no and 7 = yes? If not, then what?

Maybe if the end node is dumb and does not do DHCPv6, it could be required to 
need a CPE? I suppose general purpose computers have or will have DHCPv6 at 
some point. Not sure about, say Apple though.

(...)
> DNS
>
> 16. How do we expect customer devices to enter into the DNS?

I am not sure we need DNS here.

> 18. Should IPv6 hosts be prepared to operate without a working reverse
> DNS entry?

They'd better do it, because there are deployed IPv6 networks without reverse 
DNS. Especially if the host uses privacy addresses.

-- 
Rémi Denis-Courmont
http://www.remlab.net/