Re: [PATCH 0/3] nf_conntrack: fixes for nf_ct_attach in IPv6 stack

Re: [PATCH 0/3] nf_conntrack: fixes for nf_ct_attach in IPv6 stack

[Patrick McHardy]

Yasuyuki KOZAKAI wrote:
> Hi,
> 
> These patches make nf_ct_attach work fine in IPv6 stack.
> 
> The locally generated reply packets in IPv6 stack, such as ICMPv6 error
> and TCP RST by REJECT target, need to be associated with the connection
> of original packet.

The reason why we manually attach these references (at least for ICMP)
is because the packet might be in the middle of two NAT manips and
unrecognizable for conntrack. For IPv6 this should be irrelevant. I'm
not sure why it is done for TCP RSTs, they should always be properly
tracked anyway.

Re: [PATCH 0/3] nf_conntrack: fixes for nf_ct_attach in IPv6 stack

[Yasuyuki KOZAKAI]

From: Patrick McHardy <kaber@trash.net>
Date: Mon, 13 Feb 2006 17:44:30 +0100

> Yasuyuki KOZAKAI wrote:
> > Hi,
> > 
> > These patches make nf_ct_attach work fine in IPv6 stack.
> > 
> > The locally generated reply packets in IPv6 stack, such as ICMPv6 error
> > and TCP RST by REJECT target, need to be associated with the connection
> > of original packet.
> 
> The reason why we manually attach these references (at least for ICMP)
> is because the packet might be in the middle of two NAT manips and
> unrecognizable for conntrack. For IPv6 this should be irrelevant. I'm
> not sure why it is done for TCP RSTs, they should always be properly
> tracked anyway.

It's common case for me that the conntrack of original TCP packet is
unconfirmed at processing in REJECT target. In this case, TCP RST
generated by REJECT causes to create new conntrack. I don't think
that is good behavior. That can be said about sending ICMPv6 error.

-- Yasuyuki Kozakai

Re: [PATCH 0/3] nf_conntrack: fixes for nf_ct_attach in IPv6 stack

[Patrick McHardy]

Yasuyuki KOZAKAI wrote:
> From: Patrick McHardy <kaber@trash.net>
> Date: Mon, 13 Feb 2006 17:44:30 +0100
> 
>>
>>The reason why we manually attach these references (at least for ICMP)
>>is because the packet might be in the middle of two NAT manips and
>>unrecognizable for conntrack. For IPv6 this should be irrelevant. I'm
>>not sure why it is done for TCP RSTs, they should always be properly
>>tracked anyway.
> 
> 
> It's common case for me that the conntrack of original TCP packet is
> unconfirmed at processing in REJECT target. In this case, TCP RST
> generated by REJECT causes to create new conntrack. I don't think
> that is good behavior. That can be said about sending ICMPv6 error.

Unless I'm missing something, that shouldn't happen.
__{ip,nf}_conntrack_confirm check that the packet is in direction
IP_CT_DIR_ORIGINAL before confirming the conntrack.

Re: [PATCH 0/3] nf_conntrack: fixes for nf_ct_attach in IPv6 stack

[Yasuyuki KOZAKAI]

From: Patrick McHardy <kaber@trash.net>
Date: Tue, 14 Feb 2006 17:26:32 +0100

> > It's common case for me that the conntrack of original TCP packet is
> > unconfirmed at processing in REJECT target. In this case, TCP RST
> > generated by REJECT causes to create new conntrack. I don't think
> > that is good behavior. That can be said about sending ICMPv6 error.
> 
> Unless I'm missing something, that shouldn't happen.
> __{ip,nf}_conntrack_confirm check that the packet is in direction
> IP_CT_DIR_ORIGINAL before confirming the conntrack.

IIRC, __{ip,nf}_conntrack_confirm is called at POSTROUTING and INPUT,
after all processing of packet filter. If I do

	ip6tables -A FORWARD -p tcp --dport 22 -j REJECT

on my router, the conntrack of TCP SYN packet of ssh will never confirmed
and then nf_conntrack will create new conntrack for TCP RST at OUTPUT.

-- Yasuyuki Kozakai

Re: [PATCH 0/3] nf_conntrack: fixes for nf_ct_attach in IPv6 stack

[Patrick McHardy]

Yasuyuki KOZAKAI wrote:
> IIRC, __{ip,nf}_conntrack_confirm is called at POSTROUTING and INPUT,
> after all processing of packet filter. If I do
> 
> 	ip6tables -A FORWARD -p tcp --dport 22 -j REJECT
> 
> on my router, the conntrack of TCP SYN packet of ssh will never confirmed
> and then nf_conntrack will create new conntrack for TCP RST at OUTPUT.

RSTs and ICMP errors without existing connections should be ignored
by conntrack (and marked as INVALID). Are you sure the RSTs create
new conntracks?

Re: [PATCH 0/3] nf_conntrack: fixes for nf_ct_attach in IPv6 stack

[Yasuyuki KOZAKAI]

From: Patrick McHardy <kaber@trash.net>
Date: Tue, 14 Feb 2006 19:13:16 +0100

> Yasuyuki KOZAKAI wrote:
> > IIRC, __{ip,nf}_conntrack_confirm is called at POSTROUTING and INPUT,
> > after all processing of packet filter. If I do
> > 
> > 	ip6tables -A FORWARD -p tcp --dport 22 -j REJECT
> > 
> > on my router, the conntrack of TCP SYN packet of ssh will never confirmed
> > and then nf_conntrack will create new conntrack for TCP RST at OUTPUT.
> 
> RSTs and ICMP errors without existing connections should be ignored
> by conntrack (and marked as INVALID). Are you sure the RSTs create
> new conntracks?

Yes.

OK, I'll stop to mind the behavior - allocating conntrack at once and destroy
it after all.

But INVALID is appropriate mark for them ?

-- Yasuyuki Kozakai

Re: [PATCH 0/3] nf_conntrack: fixes for nf_ct_attach in IPv6 stack

[Jozsef Kadlecsik]

On Tue, 14 Feb 2006, Patrick McHardy wrote:

> Yasuyuki KOZAKAI wrote:
> > IIRC, __{ip,nf}_conntrack_confirm is called at POSTROUTING and INPUT,
> > after all processing of packet filter. If I do
> >
> > 	ip6tables -A FORWARD -p tcp --dport 22 -j REJECT
> >
> > on my router, the conntrack of TCP SYN packet of ssh will never confirmed
> > and then nf_conntrack will create new conntrack for TCP RST at OUTPUT.
>
> RSTs and ICMP errors without existing connections should be ignored
> by conntrack (and marked as INVALID). Are you sure the RSTs create
> new conntracks?

Marking packets created by the REJECT target as INVALID would break
the functionality of the target itself. Even if there is no real
"master" connection, RELATED was more appropriate.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: [PATCH 0/3] nf_conntrack: fixes for nf_ct_attach in IPv6 stack

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1432 bytes --]

On Tue, Feb 14, 2006 at 09:41:59PM +0100, Jozsef Kadlecsik wrote:
> On Tue, 14 Feb 2006, Patrick McHardy wrote:
> 
> > Yasuyuki KOZAKAI wrote:
> > > IIRC, __{ip,nf}_conntrack_confirm is called at POSTROUTING and INPUT,
> > > after all processing of packet filter. If I do
> > >
> > > 	ip6tables -A FORWARD -p tcp --dport 22 -j REJECT
> > >
> > > on my router, the conntrack of TCP SYN packet of ssh will never confirmed
> > > and then nf_conntrack will create new conntrack for TCP RST at OUTPUT.
> >
> > RSTs and ICMP errors without existing connections should be ignored
> > by conntrack (and marked as INVALID). Are you sure the RSTs create
> > new conntracks?
> 
> Marking packets created by the REJECT target as INVALID would break
> the functionality of the target itself. Even if there is no real
> "master" connection, RELATED was more appropriate.

I totally agree.  Also, we have to keep 100% semantic compatibility with
the existing ip_conntrack setups, otherwise we'd confuse users and
create lots of broken packet filters.

-- 
- Harald Welte <laforge@netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 0/3] nf_conntrack: fixes for nf_ct_attach in IPv6 stack

[Patrick McHardy]

Harald Welte wrote:
> On Tue, Feb 14, 2006 at 09:41:59PM +0100, Jozsef Kadlecsik wrote:
> 
>>>RSTs and ICMP errors without existing connections should be ignored
>>>by conntrack (and marked as INVALID). Are you sure the RSTs create
>>>new conntracks?
>>
>>Marking packets created by the REJECT target as INVALID would break
>>the functionality of the target itself. Even if there is no real
>>"master" connection, RELATED was more appropriate.
> 
> 
> I totally agree.  Also, we have to keep 100% semantic compatibility with
> the existing ip_conntrack setups, otherwise we'd confuse users and
> create lots of broken packet filters.

Now I get it :) I assumed conntrack should recognize the ICMP or RST
as belonging to the original connection just as for forwarded packets,
but since it is not confirmed yet, this doesn't happen. So the patches
make perfect sense and I'm going to apply them now.

Re: [PATCH 0/3] nf_conntrack: fixes for nf_ct_attach in IPv6 stack

[Patrick McHardy]

Yasuyuki KOZAKAI wrote:
> These patches make nf_ct_attach work fine in IPv6 stack.
> 
> The locally generated reply packets in IPv6 stack, such as ICMPv6 error
> and TCP RST by REJECT target, need to be associated with the connection
> of original packet.

All three patches applied, thanks. I'll push them to Dave for 2.6.16
today.

[PATCH 0/3] nf_conntrack: fixes for nf_ct_attach in IPv6 stack

[Yasuyuki KOZAKAI]

Hi,

These patches make nf_ct_attach work fine in IPv6 stack.

The locally generated reply packets in IPv6 stack, such as ICMPv6 error
and TCP RST by REJECT target, need to be associated with the connection
of original packet.

Please review and apply.

-- Yasuyuki Kozakai