[ipv6hackers] Operational ICMPv6 Filtering

[Fernando Gont]

On 06/02/2012 06:25 AM, Marksteiner, Stefan wrote:
>> Note: When draft-ietf-opsec-icmp-filtering-03 talks about
>> "intermmediate devices", it is referring to routers, *not*
>> firewalls. -- that's why many of the recommendations are probably
>> more relaxed than if they were to be enforced at a firewall.
>> 
>> Essentially, at a router you "allow everything unless you have a
>> very good reason to block it", whereas at a firewall it's usually
>> the other way around "you block everything unless you have a really
>> good reason to allow it".
> 
> Thanks for clarifying, I perceived the passage generally for *all*
> intermediate devices. Maybe, it might be a good idea to add a small
> note in any next draft version.

Ok, will do.


>> All popular TCP implementations I'm aware of do not reset
>> connections in response to the so-called ICMP/ICMPv6 "hard errors"
>> -- I should double-check with current versions of Windows, since at
>> the time I was working on RFC 5927 they were among the few
>> implementations that would reset TCP connections in response to the
>> so-called hard errors.
> 
> That's exactly what I meant. Should an *on-field* Operator rely on
> vendor implementations?

For *this* particular issue, and considering that most (if not all)
affected vendors published vulnerability advisories and patches in
2004/2005, I'd argue that it's possible to rely on vendor implementations.

However, this is not a "philosophy" that could/should be applied in the
general case (i.e. you usually want to allow something only if you
really need it).



>> My advice would be to allow these messages.
> 
> Are there more practical reasons (appart from better performance by
> "timeout-shortcuts") for this? Or asked differently: do you deem it
> "dangerous" (in terms on keeping the protocol operating) to apply a
> restrictive filtering policy?

When it comes to the so-called ICMP/ICMPv6 hard errors, they are only
useful during the connection-establishment phase, to avoid delays in
connection establishment (see e.g. RFC 5461).

However, if you can control the v6 connectivity in your network, then
your hosts shouldn't suffer from the problems discussed in RFC 5461, and
hence you could safely block the aforementioned ICMPv6 "hard errors"
without any negative effects.

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont at si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492