ICMPv6 Type 1 Code 5 and 6 missing in iptables REJECT target and icmpv6 match

ICMPv6 Type 1 Code 5 and 6 missing in iptables REJECT target and icmpv6 match

[Andreas Herz]

Hi,

as i read the RFC 7084 i found the following suggestion:

> L-14:   The IPv6 CE router MUST send an ICMPv6 Destination Unreachable
>         message, code 5 (Source address failed ingress/egress policy)
>         for packets forwarded to it that use an address from a prefix
>         that has been invalidated.

And in RFC 4443 they are defined as:

> 5 - Source address failed ingress/egress policy
> 6 - Reject route to destination

Is there a reason for that?

If i look into the "extensions/libip6t_icmp6.c" i just see the codes 0,1,2,3,4
for type 1. And in "include/linux/netfilter_ipv6/ip6t_REJECT.h" it's
"IP6T_ICMP6_ECHOREPLY" which doesnt' sound like the one in the RFC.

Or is it just missing, so i might add it?

Thanks

-- 
Andreas Herz

Re: ICMPv6 Type 1 Code 5 and 6 missing in iptables REJECT target and icmpv6 match

[Jan Engelhardt]

On Wednesday 2015-08-19 16:51, Andreas Herz wrote:
>And in RFC 4443 they are defined as:
>
>> 5 - Source address failed ingress/egress policy
>> 6 - Reject route to destination
>
>Is there a reason for that?
>
>If i look into the "extensions/libip6t_icmp6.c" i just see the codes 0,1,2,3,4
>for type 1. And in "include/linux/netfilter_ipv6/ip6t_REJECT.h" it's
>"IP6T_ICMP6_ECHOREPLY" which doesnt' sound like the one in the RFC.
>
>Or is it just missing, so i might add it?

It would appear fine to just add it.

Re: ICMPv6 Type 1 Code 5 and 6 missing in iptables REJECT target and icmpv6 match

[Andreas Herz]

On 20/08/15 at 10:13, Jan Engelhardt wrote:
> 
> On Wednesday 2015-08-19 16:51, Andreas Herz wrote:
> >And in RFC 4443 they are defined as:
> >
> >> 5 - Source address failed ingress/egress policy
> >> 6 - Reject route to destination
> >
> >Is there a reason for that?
> >
> >If i look into the "extensions/libip6t_icmp6.c" i just see the codes 0,1,2,3,4
> >for type 1. And in "include/linux/netfilter_ipv6/ip6t_REJECT.h" it's
> >"IP6T_ICMP6_ECHOREPLY" which doesnt' sound like the one in the RFC.
> >
> >Or is it just missing, so i might add it?
> 
> It would appear fine to just add it.

I just tested around and icmpv6 is already working but that's caused by
rather optimistic parsing:

> if (!xtables_strtoui(slash+1, NULL, &number, 0, UINT8_MAX))

So --icmpv6-type 1/255 is also possible. Is this intended to make those
types and codes work although they don't match the names defined in
"static const struct icmpv6_names icmpv6_codes"?

Since it doesn't harm i guess keeping it non restrictive might be good
(since checking every type and code number exactly would result in a
little bit more complex code) or should i also straiten this check in
parse_icmpv6?

If no, the patch will just add the missing icmpv6 parts for the name
based configuration.

-- 
Andreas Herz

Re: ICMPv6 Type 1 Code 5 and 6 missing in iptables REJECT target and icmpv6 match

[Jan Engelhardt]

On Thursday 2015-08-20 11:06, Andreas Herz wrote:
>
>I just tested around and icmpv6 is already working but that's caused by
>rather optimistic parsing:
>
>> if (!xtables_strtoui(slash+1, NULL, &number, 0, UINT8_MAX))
>
>So --icmpv6-type 1/255 is also possible.

Specifying raw numbers for packet fields should always be possible, 
exactly because some local name mapping database may be out of date or 
because new things get invented at IETF over time.

However, since you are concerned about the REJECT target, and 
--reject-with takes a mnemonic that is only used to communicate with the 
kernel module, rather than a value that is directly placed into a 
network packet, the above would not apply.

Re: ICMPv6 Type 1 Code 5 and 6 missing in iptables REJECT target and icmpv6 match

[Andreas Herz]

On 20/08/15 at 11:16, Jan Engelhardt wrote:
> 
> On Thursday 2015-08-20 11:06, Andreas Herz wrote:
> >
> >I just tested around and icmpv6 is already working but that's caused by
> >rather optimistic parsing:
> >
> >> if (!xtables_strtoui(slash+1, NULL, &number, 0, UINT8_MAX))
> >
> >So --icmpv6-type 1/255 is also possible.
> 
> Specifying raw numbers for packet fields should always be possible, 
> exactly because some local name mapping database may be out of date or 
> because new things get invented at IETF over time.

Sounds reasonable, so i will just add the names. Thanks for the
explanation. The icmpv6 match was just something i looked into while i
saw the issue with REJECT. So small patch incoming.

> However, since you are concerned about the REJECT target, and 
> --reject-with takes a mnemonic that is only used to communicate with the 
> kernel module, rather than a value that is directly placed into a 
> network packet, the above would not apply.

And i don't even have a chance to "cheat" (as i can with the raw numbers
in the icmpv6 match) so i will work on that part to add those codes.

-- 
Andreas Herz