[ipv6hackers] Operational ICMPv6 Filtering

[Marksteiner, Stefan]

Hi Fernando,

________________________________________
Von: Fernando Gont [fgont at si6networks.com]
Gesendet: Samstag, 02. Juni 2012 03:07
An: IPv6 Hackers Mailing List
Cc: Marksteiner, Stefan
Betreff: Re: [ipv6hackers] Operational ICMPv6 Filtering

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

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.

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

That's exactly what I meant. Should an *on-field* Operator rely on vendor implementations?

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

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

Thank you,

Stefan