[ipv6hackers] Operational ICMPv6 Filtering

[Fernando Gont]

Hi, Stefan,

On 05/29/2012 12:10 PM, Marksteiner, Stefan wrote:
> in [1] it's stated that most of the ICMPv6 Destination Unreachable
> messages are to be permitted through intermediate devices (i.e.
> firewalls; on p. 33). 

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".



> On the other hand, [2] describes an ICMPv6
> blind connection reset attack based on "hard errors" (p. 12).  I know
> that this is eventually a stack implementer's issue, as host should
> basically not accept "hard errors" in an established connection, but
> my question is: should operators rely on implementers or just block
> Destination Unreachable and the likes and take the drawback of having
> their hosts wait for timeouts instead of getting errors?

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.

My advice would be to allow these messages.

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