REC-10: IPv6 gateways SHOULD NOT forward ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing IP headers that do not match generic upper-layer transport state records.
Meanwhile, we have the following default firewall rule in OpenWrt:
# Allow essential forwarded IPv6 ICMP traffic
config rule
option name Allow-ICMPv6-Forward
option src wan
option dest *
option proto icmp
list icmp_type echo-request
list icmp_type echo-reply
list icmp_type destination-unreachable
list icmp_type packet-too-big
list icmp_type time-exceeded
list icmp_type bad-header
list icmp_type unknown-header-type
option limit 1000/sec
option family ipv6
option target ACCEPT
This rule allows the forwarding of both destination-unreachable and packet-too-big. Does this mean that it does not take the state into account unlike what REC-10 recommends should be done?
No, it doesn't mean that. Why do you think it does?
(Your question actually seems to imply that you may be unsure of what the phrase "upper-layer transport" means. Are you seeking clarity on the term?)
It simply means for example:
If a new TCP connection, but the first packet is an invalid ACK (instead of a SYN), there's no need to forward destination-unreachable or packet-too-big errors sent form a host about the ACK packet - because the ACK was invalid anyways - hence the TCP state is closed (i.e. not matching) - and no packets should be sent.
I’m very ignorant when it comes to firewalls, so please bear with me.
The reason I think that is because I assume a forward rule just forwards traffic to a given client as long as it’s adressed to that client. Is my thinking wrong?
Yes, it’s confusing to me. Do forward rules keep track of upper-layer levels too? Will they not forward a stray ICMPv6 packet, i.e. one where a prior session with the client hasn’t been established?
I think it is a fairly reasonable question to ask whether the default firewall policies (as defined within OpenWRT) follow the recommendation set out in RFC 6092. As it currently stands it doesn't look like there's anything within the firewall which would block either an ICMPv6 "Destination Unreachable" and "Packet Too Big" packet if there isn't an existing conntrack state for the traffic. But I might be missing something...
No, not really. How does questioning whether the current firewall implementation blocks certain ICMPv6 messages for traffic that doesn't have an existing conntrack state lead to a 'test by allowing everything'?
What code?
If you look at the whole sentence then it's clear the recommendation in RFC 6092 is intended to add to those made in RFC 4890. I'm not sure if you're trying to claim otherwise??
Also, see all the dialogue of another master heading,which 3.1.
It's title?
3.1. Stateless Filters
(Our firewalls are stateful, correct?)
Certain kinds of IPv6 packets MUST NOT be forwarded
~ (Emphasis Added) RFC6092-3.1
Who make sure it MUST NOT?
Confirm please.
Lastly, master heading of 3.2:
3.2. Connection-Free Filters
Some Internet applications use connection-free transport protocols with no release semantics, e.g., UDP. These protocols pose a special difficulty for stateful packet filters because most of the application state is not carried at the transport level. State records are created when communication is initiated and are abandoned when no further communication is detected after some period of time.
I would respond more fully, but if I'm honest your responses make very little sense. I'm no closer to understanding what you're trying to get at then I was several responses ago.
The closest I can get is you're implying that netfilter is written to implicity drop any ICMPv6 "Destination Unreachable" and "Packet Too Big" messages that don't have a matching transport state record, regardless of any actual rules that might appear in the firewall. Which would raise the question of why RFC 4890 appears to provide specific examples of how you would construct iptables rules to only allow ICMPv6 messages when there is an existing session.
Because the specific recommendation in RFC 6092 expands on what is in RFC 4890 and is therefore about the firewall... If you're not grasping that then there's really nothing further to discuss.
It's not about the IP stack. It's recommendations for how you should configure residential CPE to provide for "simple security" capabilities.
Yes, within the context of filtering, i.e. firewalls... The whole point of that section is to identify they've already made recommendations about filtering ICMPv6 (in RFC 4890) so don't need to repeat it, but are adding an additional recommendation.
Anyway, @jow has already confirmed the recommendation isn't followed by OpenWRT so anything further is kinda moot.
The state matching should be straightforward to implement (would come handy for other user rules as well) but the restriction to only allow actually delegated prefixes will be trickier, we would need to maintain some kind of set and frequently update it from netifd/odhcpd whenever something changes in the local prefix situation. Doable but a lot of work, so unlikely to happen soon. I could look into state matching though
You really need to go back and read what the RFC are about. And really try hard to understand this time. They are both recommendations for filtering, i.e. implementation of firewall. RFC 4890 provides recommendations for ICMPv6, RFC 6092 goes further and provides recommendations for other traffic. But they are both about firewalls.
That doesn't even make sense..
Look, we're clearly not going to come to an agreement about this. Probably best to leave this aspect of the discussion here. Let's just leave the rest of the thread to discuss what it was originally about (i.e. whether changes should be made to the firewall).
That would be useful, and even just having that state matching would probably get close to implementing the recommendation.
I mean the developers make no such claim for it to be a firewall, do they???
I'll do that...I lat taught a class on it a few weeks ago...
It makes sense, a firewall meet specifications. Anything else, isn't.
A lot of this code is upstream,and has nothing to do with OpenWrt -nonetheless, I recall seeing no guarantee that the combination of software/packages/modules/etc. will result in all the specifications of a complaint firewall. And no single person/group could guarantee that, without (well... code).
Great. But the RFCs are simply recommendations for what packet filters should be implemented within equipment. That's all about the rules you implement, not about the underlying code of the firewall (unless the firewall is so poorly written that any constructed rules don't do what they should). But we can rule that out as, afaik, netfilter works pretty well so it's back to just being a discussion around rules.
This whole discussion should've simply been the response @jow provided, i.e. the current implementation of rules in OpenWRT does not block the forwarding of ICMPv6 "Destination Unreachable" and "Packet Too Big" messages if there is no existing established or related state for the traffic, and therefore it doesn't follow that specific recommendation.
I'm not sure what you're getting at here. The recommendations in RFC 6092 are for Customer Premises Equipment which includes devices such as the sort of routers that people would use OpenWRT on. The RFC itself makes this clear:
The whole point of the RFC is to provide recommendations for how the firewall on such devices should be configured to function in order to provide 'simple security' capabilities.
...lol...get my point :wink-
