IPv6 Firewall on CPEs - Default on or off

[Philipp Kern]

Hi,

On Tue, Nov 27, 2012 at 08:06:55PM +0000, Benedikt Stockebrand wrote:
> to get this absolutely straight: If the filtering is done at the CPE,
> and if it can be turned off, why do I "shove another stateful box into
> the path"?

the CPE could be stateless, but true, if it could be turned off, you wouldn't.
Still you argued to do not do that by default. :-)

> > At a university deployment I've got a proprietary firewall that does NAT
> > for all the students.  It does barely manage the bandwidth that's
> > available[1]. 
> What *exactly* do you mean with "firewall" in this context?

It's a firewall appliance that does NAT. So it does application level
inspection for some known protocols to do proper NAT connection tracking. And
it does do the same with IPv6 traffic with the default "nothing goes from
outside to inside unless whitelisted" configuration.

> Comparing a packet filter/application level gateway/packet filter
> cascade with a minimalistic packet filter configuration (where TCP
> enters the game it might even be sufficient to filter SYN packets
> without maintaining state) doesn't make sense.

You cannot just provide TCP to students at home. So yeah, it's stateful
connection tracking for IPv4 because it has to be for NAT, and then you get the
same for IPv6 as well. If you argue that a stateful firewall is needed just
filtering SYNs doesn't cut it, given that you're then not prepared to just
whitelist UDP either.

True, you might be able to just handle UDP statefully, but that's not what such
an appliance usually does.

> > For IPv6 I'm now faced with the requirement imposed by some that we
> > "of course" need stateful firewalling (despite the fact that the
> > mechanisms to whitelist yourself are not in place).
> So, your reason to have a configurable diode style setup disabled by
> default at some other place is because at your place they didn't
> make it configurable at all?
> 
> Sorry, but this is ridiculous.

You think? Can you tell me how to make it configurable given that we do not
have any relationship with the end users at all? I'd be happy to set something
up that lets users whitelist their IPs, but as it is, only very few are able to
provide routed subnets to their students. The others use one large broadcast
domain where all users are stuffed into. The source IPv6 might then be a
privacy address, or some sort of static IPv6 or a SLAAC one. So it's highly
unclear to me how to whitelist them.

> > There are no CPEs, it's all just Ethernet.
> Maybe you should have a bit of a talk with the people in charge at the
> local university data center about the reasons why they actually
> bother to set up a firewall at all.
> 
> I've been dealing with a few of these people over the years, and
> considering the peculiarities of academic environments in general and
> student dormitories in particular I consider their approach
> heavy-handed (because it's not configurable) but generally prudent.

They don't want the student machines be abused to gain access to the internal
network. (Why it's not separated is another important question that's not
easily solvable either.) I'd tend to argue that infected machines are there
nevertheless, participating in a IPv4 botnet.

Obviously the point is that we're currently trying to establish if we need it
for the dormitories or not. For the general network there is and will be a
stateful firewall for both IPv4 and IPv6 (with all the bad performance
implications; we really do suffer with a bunch of applications).

> > If I pipe it across the firewall IPv6 is not more performant than IPv4,
> > while it could be, given that there's no requirement for NAT. For the
> > eyeballs there would be a *reason* to switch to IPv6 given that you
> > avoid the crowded NAT.  (And IPv6 transit is basically free, still.)
> So how much of an impact does NAT, or in that case a simple two-rule
> (depending on the implementation used) filter rule on a CPE, actually
> have?  I haven't managed to measure any.

Well, I said that we here do not have any CPE. We provide raw Ethernet.
In this case to the dorm infrastructure and we don't have anything to do with
their internal structure. But we hand out enough private IPs so that they don't
need to NAT within the internal network.

> CGN at carrier grade bandwidths is an entirely different league in
> pretty much any respect.

True. It's not that 1G/1G CGN would be hard with Linux hardware of any sort.
It's just that we're lacking in (permanent) people with Linux skills. Hence
it needs to be proprietary hardware.

> > Firewalls do have additional costs. Why do I have to bear them as an
> > transit provider that happens to do NAT because of IPv4 address
> > exhaustion?
> Once again: You don't have to if they can be turned off.
> And to my understanding transit providers don't do CGN; it's the ISPs.

True. I formulated that badly. The question who's the ISP in this scenario is
an important one that hasn't been solved yet. (With all the legal
implications.)

> > (I cannot shove that responsibility down to the "customers" either.)
> I really don't understand what you want to say here.  Sorry.

Our customers are the dorms. Not all of them could do the NAT. The largest
customer just deployed one subnet per room, and they didn't plan with
NAT-capable devices, for instance.

> I know a bit about the situation in German university dormitory
> networks and the problems they have with historic flat network
> topologies---and occasionally the staff running them---but maybe you
> should check out IEEE 802.1x for example.  Just because they don't
> deploy a solution, for whatever reason, doesn't mean there isn't any.

We don't have access to the individual switch ports. Not at all.

> And beyond that, there's also an option to actually clean up the
> network topology and provide all rooms/students with individual
> subnets.  Puts some extra load on the routing engines (the in-house
> traffic between students), but that's all it takes.

Yeah, we still don't have enough public IPv4 for them. My question was
firewall related. And given that we can hand out public IPv6 to them,
I'd rather like to get them to the internet in a performant manner
than to maintain state myself. And those routing engines in the dorms
won't be capable of doing any kind of stateful tracking.

> Filtering by MAC addresses isn't particularly clever, either.
> *Especially* not when students with some technical affinity are
> around.

Yep. But it's not the abuse point I'm talking about here but how to
organize the firewall whitelisting. And I don't particularly care about
people abusing other people's whitelist entries if they could setup one
by themselves. ;-)

But at that point in the network I cannot access this information and
hence don't have any means to check if somebody is trying to setup a
whitelist entry for his own computer or someone else's. The MAC
address would help if one could automatically whitelist any address
that's associated with it instead of every individual address at once.

Kind regards
Philipp Kern
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20121202/50410f7f/attachment.sig>