IPv6 content experiment

[Rémi Denis-Courmont]

Le mardi 10 avril 2007 14:06, Colm MacCarthaigh a écrit :
> > Which break as the first thing most people do is put a firewall
> > in place. Why do people carry on insisting open end to end
> > connectivity is the holy grail and designing protocols that don't
> > tolerate firewalls. Why would they not have a firewall for v6 too?
>
> No reason at all.

Sure, they will put firewalls (see 
http://docs.info.apple.com/article.html?artnum=305366 for a recent 
example). We can argue whether they'll be useful or not, but I'm pretty 
sure they'll be there anyway.

> But you'll find that the majority of firewalls do not blanket filter
> inbound connections by default, and there's no good reason for them to
> either. In fact most end user firewalling products these days detect
> listen()'s and ask the user if they would like to allow or disallow
> inbound connectivity to that application.

Yes... But, this only works for host-firewalls. NATs are not found on 
hosts, and it's likely that IPv6-enabled SOHO CPE (if they ever hit the 
market) will ship with stateful IPv6 firewalls that will block incoming 
connections. And even if they wanted to, they would not be able to 
catch listen() system calls :(

> The point is that that flexibility becomes optional again, rather
> than restricted mandatorily.

It might be optional. "Hopefully" these would-be IPv6 CPEs will have a 
big "firewalled on/off" button that will break so many cool apps that 
people will always set the firewall to off... maybe. Afterall, my cable 
modem has a "Internet data security" button (but it stops EVERYTHING 
when pressed - that's extremely secure indeed).

> Personally I don't think it is the job of protocol designers to
> tolerate firewalls, that just gets us a billion protocols which all
> tunnel over HTTP.

I disagree. There has to be a tradeoff between everything on top of 
HTTP, and "no security".

For UDP, we have discovered hole punching which works nicely around most 
stateful firewalls. And in fact, any protocol should do some kind of 
hole punching, not only to pass through firewalls, but also to make 
sure one end is not sending piles of packets toward an unwilling other 
end.

Unfortunately, I am yet to see any widespread/agreed way of doing this 
for TCP (whether TCP/IPv4 or TCP/IPv6). Big bonus if it works for "any" 
layer-4 protocol so we don't doom any new transport to failure on IPv6 
as NAT did on IPv4 (think DCCP, SCTP, UDP-Lite...).

> Internet security is better served by discrete protocols which are
> possible to filter and allow on a more granular basis.

Yes. Though apps vendor will continue to ship stuff that uses (or can 
fallback through) HTTP, if only because there is demand for bypassing 
firewalls, whether legitimately or not. Many people have no control 
over the firewall(s) on their Internet access (e.g. in corporate 
Intranets).

> > Most end users have an OS that really shouldn't be left open to
> > access by all,
>
> NAT is not a firewall, and does not meaningfully protect these users.

I completely agree. However I have seen many people call NAT what is 
really a NAT plus a stateful firewall (since both functions are more 
often than not in the same box). However, a stateful firewall does 
protect some kind of protection. And it is also used to prevent 
unsolicited traffic from filling up limited last mile bandwidth - a 
problem end-to-end principle cannot address. Which is why I'm asking 
for a layer-4 independant hole punching mechanism (end-to-end really 
starts at layer-4).

> It's not like we don't already see millions of those bozes
> participating in botnets already. Nor does the removal of NAT leave
> them open to access by all.

I agree. If it can be caught by a worm through open TCP ports, it can 
likely be caught by something running on email, IM or HTTP also.

> > add v6 to a major site (I've looked at this for BBC sites for years
> > and it's never been worth the risk) without black holing users
> > we'll be a big step towards general use.
>
> Why not just have www.ipv6.bbc.co.uk ? Does that really represent
> much risk? Seems like a better idea to iron out those problems before
> hand.

No offense intented, but I think this *.ipv6.example.com thing is very 
useless. Nobody uses it, so nobody finds the problem, so it does not 
make anybody a service. The only way to diagnose IPv6 problems is to 
put it to the normal hostname, and provide *.ipv4.example.com as a 
work-around for people with blackhole IPv6 connections. It is more 
painful and it makes IPv6 a very bad publicity to the affected users 
(see the Ubuntu discussion a few days ago), but at least, it sort of 
works.

-- 
Rémi Denis-Courmont
http://www.remlab.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20070410/d45e9264/attachment.sig>