netfilter TCP/UDP conntrack RELATED state with ICMP / ICMPv6

Question

Netfilter connection tracking is designed to identify some packets as "RELATED" to a conntrack entry.

I'm looking to find the full details of TCP and UDP conntrack entries, with respect to ICMP and ICMPv6 error packets.

Specific to IPv6 firewalling, RFC 4890 clearly describes the ICMPv6 packets that shouldn't be dropped

http://www.ietf.org/rfc/rfc4890.txt

4.3.1. Traffic That Must Not Be Dropped

Error messages that are essential to the establishment and maintenance of communications:

Destination Unreachable (Type 1) - All codes

Packet Too Big (Type 2)

Time Exceeded (Type 3) - Code 0 only

Parameter Problem (Type 4) - Codes 1 and 2 only

Appendix A.4 suggests some more specific checks that could be performed on Parameter Problem messages if a firewall has the

necessary packet inspection capabilities.

Connectivity checking messages:

Echo Request (Type 128)

Echo Response (Type 129)

For Teredo tunneling [RFC4380] to IPv6 nodes on the site to be possible, it is essential that the connectivity checking messages are

allowed through the firewall. It has been common practice in IPv4 networks to drop Echo Request messages in firewalls to minimize the risk of scanning attacks on the protected network. As discussed in Section 3.2, the risks from port scanning in an IPv6 network are much less severe, and it is not necessary to filter IPv6 Echo Request messages.

4.3.2. Traffic That Normally Should Not Be Dropped

Error messages other than those listed in Section 4.3.1:

Time Exceeded (Type 3) - Code 1
    Parameter Problem (Type 4) - Code 0

In the case of a linux home router, is the following rule sufficient to protect the WAN interface, while letting through RFC 4890 ICMPv6 packets? (ip6tables-save format)

*filter
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Addendum: of course, one needs other rules for NDP and DHCP-PD:

-A INPUT -s fe80::/10 -d fe80::/10 -i wanif -p ipv6-icmp -j ACCEPT
-A INPUT -s fe80::/10 -d fe80::/10 -i wanif -p udp -m state --state NEW -m udp --sport 547 --dport 546 -j ACCEPT

In other terms, can I safely get rid of the following rules to comply with RFC 4980, keeping only the "RELATED" rule first?

-A INPUT -i wanif -p icmpv6 --icmpv6-type destination-unreachable -j ACCEPT
-A INPUT -i wanif -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT
-A INPUT -i wanif -p icmpv6 --icmpv6-type ttl-exceeded -j ACCEPT
-A INPUT -i wanif -p icmpv6 --icmpv6-type parameter-problem -j ACCEPT

Answer 1

I don't know the answer, but you can find out yourself.

Use these rules (creates an empty chain "NOOP" for accounting purposes):

*filter
...
:NOOP - [0:0]
...
-A INPUT -i wanif -p icmpv6 --icmpv6-type destination-unreachable -j NOOP
-A INPUT -i wanif -p icmpv6 --icmpv6-type packet-too-big -j NOOP
-A INPUT -i wanif -p icmpv6 --icmpv6-type ttl-exceeded -j NOOP
-A INPUT -i wanif -p icmpv6 --icmpv6-type parameter-problem -j NOOP
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i wanif -p icmpv6 --icmpv6-type destination-unreachable -j ACCEPT
-A INPUT -i wanif -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT
-A INPUT -i wanif -p icmpv6 --icmpv6-type ttl-exceeded -j ACCEPT
-A INPUT -i wanif -p icmpv6 --icmpv6-type parameter-problem -j ACCEPT
...

Then sometimes later, use ip6tables-save -c to see the counters for the above rules. If the counters are > 0 for the NOOP rules above the "RELATED" line but 0 for the ACCEPT rules below, you know the "RELATED" match has taken care of accepting them. If the counter for some NOOP rule is 0, then you can't tell yet for that particular icmpv6 type whether RELATED does it or not. If some ACCEPT line has its counter > 0, then you do need that explicit rule.