[ipv6hackers] Operational ICMPv6 Filtering

[daniel.bartram at bt.com]

Stefan,

I take the viewpoint of allowing the following:

Permit icmp any any packet-too-big
Permit icmp any any time-exceeded
Permit icmp any any echo-reply
Permit icmp any any echo request
Permit icmp any any destination-unreachable
Permit icmp any any time-exceeded

And blocking everything else.

I don't think it's a good idea to completely block destination-unreachable completely to preserve end-user experience.

Dan.

-----Original Message-----
From: ipv6hackers-bounces at lists.si6networks.com [mailto:ipv6hackers-bounces at lists.si6networks.com] On Behalf Of Marksteiner, Stefan
Sent: 29 May 2012 16:11
To: 'IPv6 Hackers Mailing List'
Subject: [ipv6hackers] Operational ICMPv6 Filtering

Hi,

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). 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?

Cheers,

Stefan

[1] http://tools.ietf.org/html/draft-ietf-opsec-icmp-filtering-03
[2] http://tools.ietf.org/html/rfc5927
_______________________________________________
Ipv6hackers mailing list
Ipv6hackers at lists.si6networks.com
http://lists.si6networks.com/listinfo/ipv6hackers