me at benedikt-stockebrand
Aug 7, 2012, 4:03 AM
Post #9 of 15
Hi Doug and list,
Doug Barton <dougb [at] dougbarton> writes:
> On 08/03/2012 05:39, Benedikt Stockebrand wrote:
>> yes, in some cases you may want to filter e.g. routing headers and
> Do you have references to this issue?
as Cameron pointed out there is a chance that there are still type 0
routing header implementations around; especially with long-lived
embedded devices (think network printers if nothing else) this can be
Plus, I have network printer here which actually supports some basic
IPv6 but it didn't tell anywhere in the specs when I bought it (about
5--7 years ago); while I can protect its possibly rather buggy
implementation by simply keeping it inaccessible from anywhere except
trusted clients, other people may not be as lucky.
Additionally, I still remember at least one ICMP6 type being assigned
by IANA that was implemented in at least some BSD kernels but never
reached RFC status; the draft has long since expired, but the
implementation may still be out there.
And if you're connecting devices to untrusted networks (think
auditorium WLANs in a college/university), then you should consider
(and I mean "consider", not "just do without further thought")
filtering router advertisements and ICMP6 redirects as well.
>> More generally speaking, with new ICMP6 types possibly coming
>> up you may want to whitelist rather than blacklist individual ICMP6
> This is the opposite of what should be done, for 2 reasons. First, you
> should only blacklist things you know you're having problems with.
> Second, but taking the approach you suggest you miss out if the protocol
> changes and you don't update your filters.
> The whole concept of blanket ICMP restrictions in v4 was bad, doing it
> for ICMPv6 is really bad.
In an ISP or similar context, basically whenever I am providing
unrestricted network connectivity for others, I'd do absolutely
nothing about ICMP6 filtering for my users/customers, and only rate
limit ICMP6 for my own equipment. That's an extreme case, even if it
is fairly common for a lot of people on this list.
But if you need to maintain security in a tightly controlled
(e.g. corporate or governmental) network with strictly defined
functionality, then that's a different situation; in that case you
effectively have to find a balance between micro-managing anything
that's allowed ("in triplicate, and signed by the entire management
board"), preserving flexibility for changing network usage, support
for devices outside your administrative control, and the capability to
quickly fix problems.
I personally consider filtering echo requests/replies rather extreme,
but from what I've learned from some customers these extreme cases do
exist and sometimes require such extreme measures. And, to reply on
Philipp's comment, no, Teredo is not an issue in such environments.
Think about it another way: There are people out there who actually
understand IPv6 well enough to implement it; if these people bother to
add filters of some kind, then there's a chance they've run into some
installation that actually made that filter useful---it's not always
done just due to customer pressure.
Business Grade IPv6
Consulting, Training, Projects
Benedikt Stockebrand, Dipl.-Inform. http://www.benedikt-stockebrand.de/