ip6tables breaks dnssec?

ip6tables breaks dnssec?

[Leo Baltus]

Hi,

When doing recusive dns queries to dnssec-enbled servers it looks like
ip6tables does not assemble udp packets before filtering takes place.
This results in fragments being dropped.

Here's how to reproduce using bind-9.7.x or bind-9.8.x with fedora 14,
kernel 2.6.35.12-88

1. make /tmp/named./conf
        options {
                directory               "/tmp";
                recursion yes;
                listen-on-v6 { ::1; };
        };

2. start named

        named -6 -c /tmp/named.conf

3. my ip6tables filter

        # cleanup
        ip6tables -P INPUT ACCEPT;
        ip6tables -P OUTPUT ACCEPT;
        for table in $(cat /proc/net/ip6_tables_names); do
                ip6tables -t $table -F; 
                ip6tables -t $table -X;
                ip6tables -t $table -Z;
        done
        
        #accept icmp6
        ip6tables -A INPUT -j ACCEPT -p icmpv6
        ip6tables -A OUTPUT -j ACCEPT -p icmpv6
        
        # accept incoming dns
        ip6tables -A INPUT -j ACCEPT -p udp --dport 53
        ip6tables -A OUTPUT -j ACCEPT -p udp --sport 53
        
        # accept outgoing dns
        ip6tables -A INPUT -j ACCEPT -p udp --sport 53
        ip6tables -A OUTPUT -j ACCEPT -p udp --dport 53
        
        # drop policy
        ip6tables -A INPUT  -j LOG --log-level 6 --log-prefix 'drop in: '
        ip6tables -A OUTPUT -j LOG --log-level 6 --log-prefix 'drop out: '
        ip6tables -P INPUT DROP;
        ip6tables -P OUTPUT DROP;

4. Do a query to a dnssec servers, I use this test-setup:
 https://www.dns-oarc.net/oarc/services/replysizetest

        dig @::1  +short  rs.dns-oarc.net txt

5. The result should be
        'DNS reply size limit is at least 4091', or roundabout 4000

However we see fragments being dropped in the logs and a reply size
just under MTU so I assume no fragments get assembled:

Apr 27 10:43:38 leo kernel: [81648.003267] drop in: IN=eth0 OUT= MAC=00:--:--:--:--:--:--:--:--:--:--:--:--:-- SRC=2001:04f8:0003:02bc:0002:0000:0000:0135 DST=2a02:0458:0101:----:----:----:----:---- LEN=1496 TC=0 HOPLIMIT=56 FLOWLBL=0 FRAG:1448 INCOMPLETE ID:88b59425 PROTO=UDP 
Apr 27 10:43:38 leo kernel: [81648.003289] drop in: IN=eth0 OUT= MAC=00:--:--:--:--:--:--:--:--:--:--:--:--:-- SRC=2001:04f8:0003:02bc:0002:0000:0000:0135 DST=2a02:0458:0101:----:----:----:----:---- LEN=1243 TC=0 HOPLIMIT=56 FLOWLBL=0 FRAG:2896 ID:88b59425 PROTO=UDP 


-- 
Leo Baltus, internetbeheerder                         /\
NPO ICT Internet Services                            /NPO/\
Sumatralaan 45, 1217 GP Hilversum, Filmcentrum, west \  /\/
beheer@omroep.nl, 035-6773555                         \/

Re: ip6tables breaks dnssec?

[Jan Engelhardt]

On Wednesday 2011-04-27 10:57, Leo Baltus wrote:

>Hi,
>
>When doing recusive dns queries to dnssec-enbled servers it looks like
>ip6tables does not assemble udp packets before filtering takes place.
>This results in fragments being dropped.

You need to have nf_defrag_ipv6 loaded for automatic defragmentation. 
There are only a few components that depend on it - nf_conntrack and 
TPROXY, so it may not be autoloaded if you do not use either.

Re: ip6tables breaks dnssec?

[Ulrich Weber]

Each fragmented IPv6 packets will traverse netfilter separately,
in contrast to IPv4, where its only one refragmented packet.

"ip6tables -A INPUT -j ACCEPT -p udp --dport 53" will only match the
first fragment, where the UDP header can be found. To match the
additional fragments, you have to insert these rules:

ip6tables -I INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
ip6tables -I OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Cheers
 Ulrich

On 04/27/2011 12:08 PM, Jan Engelhardt wrote:
> On Wednesday 2011-04-27 10:57, Leo Baltus wrote:
> 
>> Hi,
>>
>> When doing recusive dns queries to dnssec-enbled servers it looks like
>> ip6tables does not assemble udp packets before filtering takes place.
>> This results in fragments being dropped.
> 
> You need to have nf_defrag_ipv6 loaded for automatic defragmentation. 
> There are only a few components that depend on it - nf_conntrack and 
> TPROXY, so it may not be autoloaded if you do not use either.
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ip6tables breaks dnssec?

[Leo Baltus]

Op 27/04/2011 om 12:43:19 +0200, schreef Ulrich Weber:
> Each fragmented IPv6 packets will traverse netfilter separately,
> in contrast to IPv4, where its only one refragmented packet.
> 

I seem to have missed that.

> "ip6tables -A INPUT -j ACCEPT -p udp --dport 53" will only match the
> first fragment, where the UDP header can be found. To match the
> additional fragments, you have to insert these rules:
> 
> ip6tables -I INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
> ip6tables -I OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
> 

Thanks. That was it.

> On 04/27/2011 12:08 PM, Jan Engelhardt wrote:
> > On Wednesday 2011-04-27 10:57, Leo Baltus wrote:
> > 
> >> Hi,
> >>
> >> When doing recusive dns queries to dnssec-enbled servers it looks like
> >> ip6tables does not assemble udp packets before filtering takes place.
> >> This results in fragments being dropped.
> > 
> > You need to have nf_defrag_ipv6 loaded for automatic defragmentation. 
> > There are only a few components that depend on it - nf_conntrack and 
> > TPROXY, so it may not be autoloaded if you do not use either.
> > --
> > To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Leo Baltus, internetbeheerder                         /\
NPO ICT Internet Services                            /NPO/\
Sumatralaan 45, 1217 GP Hilversum, Filmcentrum, west \  /\/
beheer@omroep.nl, 035-6773555                         \/

Re: ip6tables breaks dnssec?

[Jan Engelhardt]

On Wednesday 2011-04-27 12:43, Ulrich Weber wrote:

>Each fragmented IPv6 packets will traverse netfilter separately,
>in contrast to IPv4, where its only one refragmented packet.

Not really. All fragments enter nf_hook_slow, be it IPv4 or IPv6.
It's just that nf_defrag - which is a netfilter module - collects and 
suppresses fragments before spitting out the unfragmented one.

>"ip6tables -A INPUT -j ACCEPT -p udp --dport 53" will only match the
>first fragment, where the UDP header can be found. To match the
>additional fragments, you have to insert these rules:
>
>ip6tables -I INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
>ip6tables -I OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

That will load nf_conntrack_ipv6, and because conntrack depends on 
nf_defrag_ipv6, will load that too. Once it is loaded, packets should 
be defragmented independetly of whether you actually use -m conntrack 
(or the obsolete -m state) or not.

Re: ip6tables breaks dnssec?

[Leo Baltus]

Op 27/04/2011 om 13:22:57 +0200, schreef Jan Engelhardt:
> On Wednesday 2011-04-27 12:43, Ulrich Weber wrote:
> 
> >Each fragmented IPv6 packets will traverse netfilter separately,
> >in contrast to IPv4, where its only one refragmented packet.
> 
> Not really. All fragments enter nf_hook_slow, be it IPv4 or IPv6.
> It's just that nf_defrag - which is a netfilter module - collects and 
> suppresses fragments before spitting out the unfragmented one.
> 
> >"ip6tables -A INPUT -j ACCEPT -p udp --dport 53" will only match the
> >first fragment, where the UDP header can be found. To match the
> >additional fragments, you have to insert these rules:
> >
> >ip6tables -I INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
> >ip6tables -I OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
> 
> That will load nf_conntrack_ipv6, and because conntrack depends on 
> nf_defrag_ipv6, will load that too. Once it is loaded, packets should 
> be defragmented independetly of whether you actually use -m conntrack 
> (or the obsolete -m state) or not.

my /proc/config.gs says:
CONFIG_NF_CONNTRACK_IPV6=y
so it is already loaded

But is does not defrag.

Also I am a bit worried about using conntrack because of the high
volume dns queries tend to be which would generate a very large
connectiontracking table and/or system load.

-- 
Leo Baltus, internetbeheerder                         /\
NPO ICT Internet Services                            /NPO/\
Sumatralaan 45, 1217 GP Hilversum, Filmcentrum, west \  /\/
beheer@omroep.nl, 035-6773555                         \/

Re: ip6tables breaks dnssec?

[Leo Baltus]

Op 27/04/2011 om 13:41:39 +0200, schreef Leo Baltus:
> Op 27/04/2011 om 13:22:57 +0200, schreef Jan Engelhardt:
> > On Wednesday 2011-04-27 12:43, Ulrich Weber wrote:
> > 
> > >Each fragmented IPv6 packets will traverse netfilter separately,
> > >in contrast to IPv4, where its only one refragmented packet.
> > 
> > Not really. All fragments enter nf_hook_slow, be it IPv4 or IPv6.
> > It's just that nf_defrag - which is a netfilter module - collects and 
> > suppresses fragments before spitting out the unfragmented one.
> > 
> > >"ip6tables -A INPUT -j ACCEPT -p udp --dport 53" will only match the
> > >first fragment, where the UDP header can be found. To match the
> > >additional fragments, you have to insert these rules:
> > >
> > >ip6tables -I INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
> > >ip6tables -I OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
> > 
> > That will load nf_conntrack_ipv6, and because conntrack depends on 
> > nf_defrag_ipv6, will load that too. Once it is loaded, packets should 
> > be defragmented independetly of whether you actually use -m conntrack 
> > (or the obsolete -m state) or not.
> 
> my /proc/config.gs says:
> CONFIG_NF_CONNTRACK_IPV6=y
> so it is already loaded
> 
> But is does not defrag.
> 

So is this a bug? Given the state ip6tables is now in the only way to
make defrag work is to set '--state RELATED,ESTABLISHED'. As I
understand it, this should not be the case, right?

> Also I am a bit worried about using conntrack because of the high
> volume dns queries tend to be which would generate a very large
> connectiontracking table and/or system load.
> 

I am not sure if this is true or not for fragments, but for heavy tcp
traffic (http) we use raw/NOTRACK to avoid conntrack, how would that work
with ip6tables considering heavy fragmented (http or dns) traffic?

-- 
Leo Baltus, internetbeheerder                         /\
NPO ICT Internet Services                            /NPO/\
Sumatralaan 45, 1217 GP Hilversum, Filmcentrum, west \  /\/
beheer@omroep.nl, 035-6773555                         \/

Re: ip6tables breaks dnssec?

[Ulrich Weber]

On 04/27/2011 01:22 PM, Jan Engelhardt wrote:
> On Wednesday 2011-04-27 12:43, Ulrich Weber wrote:
> 
>> Each fragmented IPv6 packets will traverse netfilter separately,
>> in contrast to IPv4, where its only one refragmented packet.
> 
> Not really. All fragments enter nf_hook_slow, be it IPv4 or IPv6.
> It's just that nf_defrag - which is a netfilter module - collects and 
> suppresses fragments before spitting out the unfragmented one.

nf_ct_frag6_output() sends each fragment itself through netfilter.

Personally I don't like this and would rather see, that IPv6 behaves the
same way as IPv4, sending the unfragmented packet through netfilter...


Cheers
 Ulrich

Re: ip6tables breaks dnssec?

[Stephen Clark]

On 04/27/2011 07:22 AM, Jan Engelhardt wrote:
> On Wednesday 2011-04-27 12:43, Ulrich Weber wrote:
>
>    
>> Each fragmented IPv6 packets will traverse netfilter separately,
>> in contrast to IPv4, where its only one refragmented packet.
>>      
> Not really. All fragments enter nf_hook_slow, be it IPv4 or IPv6.
> It's just that nf_defrag - which is a netfilter module - collects and
> suppresses fragments before spitting out the unfragmented one.
>
>    
>> "ip6tables -A INPUT -j ACCEPT -p udp --dport 53" will only match the
>> first fragment, where the UDP header can be found. To match the
>> additional fragments, you have to insert these rules:
>>
>> ip6tables -I INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
>> ip6tables -I OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
>>      
> That will load nf_conntrack_ipv6, and because conntrack depends on
> nf_defrag_ipv6, will load that too. Once it is loaded, packets should
> be defragmented independetly of whether you actually use -m conntrack
> (or the obsolete -m state) or not.
>    
Jan,

are you saying we should be using -m conntrack now instead of -m state 
and that -m state is going away?

> --
> To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>    


-- 

"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty
decreases."  (Thomas Jefferson)

Re: ip6tables breaks dnssec?

[Jan Engelhardt]

On Wednesday 2011-04-27 14:54, Stephen Clark wrote:

> On 04/27/2011 07:22 AM, Jan Engelhardt wrote:
>> On Wednesday 2011-04-27 12:43, Ulrich Weber wrote:
>>
>>   
>>> Each fragmented IPv6 packets will traverse netfilter separately,
>>> in contrast to IPv4, where its only one refragmented packet.
>>>     
>> Not really. All fragments enter nf_hook_slow, be it IPv4 or IPv6.
>> It's just that nf_defrag - which is a netfilter module - collects and
>> suppresses fragments before spitting out the unfragmented one.
>>
>>   
>>> "ip6tables -A INPUT -j ACCEPT -p udp --dport 53" will only match the
>>> first fragment, where the UDP header can be found. To match the
>>> additional fragments, you have to insert these rules:
>>>
>>> ip6tables -I INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
>>> ip6tables -I OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
>>>     
>> That will load nf_conntrack_ipv6, and because conntrack depends on
>> nf_defrag_ipv6, will load that too. Once it is loaded, packets should
>> be defragmented independetly of whether you actually use -m conntrack
>> (or the obsolete -m state) or not.
>>   
> Jan,
>
> are you saying we should be using -m conntrack now instead of -m state and that
> -m state is going away?

-m state is old, redundant (since at least 2.6.12..), - and as such 
ignored whenever possible - but others think removing xt_state is too 
much a message to people..