writing a fragmentation-needed patch

writing a fragmentation-needed patch

[Martijn Lievaart]

Hello,

I have written a patch for ipt_REJECT that enables iptables to send back 
fragmentation-needed. This is useful for testing PMTUD problems. It 
works for me now, but needs some polishing before I release it.

Questions:
- Would such a patch have a chance to be submitted to pom?
- If so, where can I find information on how to submit such a patch

If not, I'll just post it to the list and on my website so others can 
still take advantage of it.

BTW, this patch is completely incompatible with the fake-source patch. 
ipt_REJECT would need major surgery to enable both patches. Imo this is 
not a problem (just don't apply both patches), but I'ld like to know how 
others think about this.

Martijn Lievaart

Re: writing a fragmentation-needed patch

[Patrick Schaaf]

> I have written a patch for ipt_REJECT that enables iptables to send back 
> fragmentation-needed. This is useful for testing PMTUD problems. It 
> works for me now, but needs some polishing before I release it.
> 
> Questions:
> - Would such a patch have a chance to be submitted to pom?

Two questions:

- why is it a patch against REJECT, instead of a standalone target?
- how would you concretely use it to test PMTUD problems?

best regards
  Patrick

Re: writing a fragmentation-needed patch

[Martijn Lievaart]

Patrick Schaaf wrote:

>>I have written a patch for ipt_REJECT that enables iptables to send back 
>>fragmentation-needed. This is useful for testing PMTUD problems. It 
>>works for me now, but needs some polishing before I release it.
>>
>>Questions:
>>- Would such a patch have a chance to be submitted to pom?
>>    
>>
>
>Two questions:
>
>- why is it a patch against REJECT, instead of a standalone target?
>

Because it feels (felt) right. It's the only subtype of 
icmp-dest-unreach that is not handled in REJECT.

Advantage:
- 99% of the code of a new target would be identical to ipt_REJECT, so 
we avoid a lot of code replication.
Disadvantage:
- uncompatible with fake-source patch. Note that ipt_REJECT should imho 
be rewritten anyhow, it's to rigid now. I guess this is not a real 
option as that would invalidate the fake-source patch so we would get 
patch on patch.

What do you think?

>- how would you concretely use it to test PMTUD problems?
>  
>

I need this because we use a firewall that does not document how it 
handles-fragmentation needed. Going through tech-support did not give 
satisfactory answers, besides I want to see it on the wire before I 
believe what really happens. (And no, replacing the firewall with a 
better one is not an option :-( ). As out webservers run on HP/UX that 
seems to have some problems with fragmentation-needed if not handled 
correctly by the firewall (this may be lore, I intend to prove it 
doesn't have these problems).

 So we need to really know that it really works before we fully enable 
pmtud on our servers, it was disabled because it caused /strange/ 
problems with the webservers with a previous version of the firewall 
(that probably just dropped the frag-neededs). And I mean /strange/ 
problems, once pmtud kicked in for one connection, all connections on 
that interface where affected, until finally the traffic just stopped. 
As this was before I worked there I think much of what is known about 
the problems, and possibly even the description of the problems 
themselves, may be incorrect and/or lore.

An alternative was to set up a test situation with a small mtu somewhere 
in the path. However it is easier for me to write this patch and apply 
it to the endpoint used for testing. Note that you cannot just set the 
mtu of the link at the endpoint smaller, as this will then be advertised 
in the mss for tcp therefore avoiding pmtud with tcp.

Concretely:

Take the following rule(s).

LENGTH=1000
iptables -F INPUT
iptables -A INPUT -s ! 10.0.2.3 -m length --length $((LENGTH + 
1)):0xffff -j REJECT --reject-with icmp-fragmentation-needed --mtu $LENGTH

(10.0.2.3 is the address I use to ssh in to the box, I exclude it in 
case there are problems with the patch. It is not needed now the patch 
works, yet it doesn't hurt either).

Now wget from the webserver, or telnet or do something else to get 
packets flowing. Sniff the wire on all relevant points. Works like a 
charm :-)

Martijn Lievaart

P.S. Replacing HP/UX with another OS is also not an option :-(

Re: writing a fragmentation-needed patch

[Harald Welte]

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

On Sun, Mar 30, 2003 at 12:14:49PM +0200, Martijn Lievaart wrote:

> >- why is it a patch against REJECT, instead of a standalone target?
> 
> Because it feels (felt) right. It's the only subtype of 
> icmp-dest-unreach that is not handled in REJECT.

Please re-read the whole discussion about reject-with-type-13.

We _cannot_ change the structure layout/valid value ranges/etc of any
target in the stable kernel series.  We always need to make sure
backwards- and forwards-compatibility between old/new kernel and old/new
iptables userspace.

> What do you think?

I think the solution is to create an ICMP target, which has the
parameters 'icmp type' and 'icmp code', where the kernel would accept
any values.  detecting invalid icmp code/types should be done in  the
libipt_ICMP.c userspace plugin.

> Martijn Lievaart

-- 
- Harald Welte <laforge@netfilter.org>             http://www.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: 232 bytes --]

Re: writing a fragmentation-needed patch

[Martijn Lievaart]

Harald Welte wrote:

>On Sun, Mar 30, 2003 at 12:14:49PM +0200, Martijn Lievaart wrote:
>
>  
>
>>>- why is it a patch against REJECT, instead of a standalone target?
>>>      
>>>
>>Because it feels (felt) right. It's the only subtype of 
>>icmp-dest-unreach that is not handled in REJECT.
>>    
>>
>
>Please re-read the whole discussion about reject-with-type-13.
>  
>

/me searches archives.

Ahhh, yes I read that, but it didn't register at the time.  (And I was 
wrong, it also doesn't handle that subtype, maybe more).

>We _cannot_ change the structure layout/valid value ranges/etc of any
>target in the stable kernel series.  We always need to make sure
>backwards- and forwards-compatibility between old/new kernel and old/new
>iptables userspace.
>  
>
I see the point and had I remembered this beforehand I would have 
created a seperate target. I still may, but the solution I have now 
works for me. Effectively you are saying that the fake-source patch 
should also not have been in pom as it changes the userspace<->kernel 
interface?

OTOH, there could be an "incompatible" part of pom, for useful, but 
backwards incompatible changes. Just make clear that these are optional 
patches that will not make it into the kernel and need both a patched 
kernel and userspace. This is probably not the major goal of pom, but it 
could be a convenient repository for such patches.

>>What do you think?
>>    
>>
>
>I think the solution is to create an ICMP target, which has the
>parameters 'icmp type' and 'icmp code', where the kernel would accept
>any values.  detecting invalid icmp code/types should be done in  the
>libipt_ICMP.c userspace plugin.
>  
>

I'll have a look at the this aproach, but effectively this would just be 
a clone of libipt_REJECT with minor changes. Also it probably should not 
do the tcp-reset thingy as that is not ICMP (or think of a better 
name.... hmmmm, REJECT, no that is taken ;^>). It would give a chance to 
encode all the icmp error messages. Maybe DENY would be a better name 
although this would create major confusion for newbies.

But for me it is not all that important in the end. I have a patched 
kernel that does what I want, patch will not make pom, ok, I publish it 
somewhere else for those that want it. If I feel like it, I will have a 
look at a FRAGNEEDED and/or DENY/ICMP/Whatever target.

BTW, there does not seem to be an existing match for the DF-bit? Hmmm 
more work to do. :-)

Martijn Lievaart

Re: writing a fragmentation-needed patch

[Harald Welte]

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

On Mon, Mar 31, 2003 at 05:10:31PM +0200, Martijn Lievaart wrote:

> I see the point and had I remembered this beforehand I would have 
> created a seperate target. I still may, but the solution I have now 
> works for me. Effectively you are saying that the fake-source patch 
> should also not have been in pom as it changes the userspace<->kernel 
> interface?

the fake-source patch will never be submitted to the kernel.  It can,
however, remain in something else than base/pending/submitted of
patch-o-matic.

> OTOH, there could be an "incompatible" part of pom, for useful, but 
> backwards incompatible changes. Just make clear that these are optional 
> patches that will not make it into the kernel and need both a patched 
> kernel and userspace. This is probably not the major goal of pom, but it 
> could be a convenient repository for such patches.

yes. I think we should merge this 'incompatible' with 'userspace'

> I'll have a look at the this aproach, but effectively this would just be 
> a clone of libipt_REJECT with minor changes. Also it probably should not 
> do the tcp-reset thingy as that is not ICMP (or think of a better 
> name.... hmmmm, REJECT, no that is taken ;^>). 

sure, TCP RST has no relation to ICMP. So just forget about it in the
ICMP target.

> It would give a chance to encode all the icmp error messages. Maybe
> DENY would be a better name although this would create major confusion
> for newbies.

DENY used to be the name for DROP in ipchains/ipfwadm, so this will
certainly caus confisuion.

> But for me it is not all that important in the end. I have a patched 
> kernel that does what I want, patch will not make pom, ok, I publish it 
> somewhere else for those that want it. If I feel like it, I will have a 
> look at a FRAGNEEDED and/or DENY/ICMP/Whatever target.
> 
> BTW, there does not seem to be an existing match for the DF-bit? Hmmm 
> more work to do. :-)

sure, we're always open for contributions.

> Martijn Lievaart

-- 
- Harald Welte <laforge@netfilter.org>             http://www.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: 232 bytes --]