Re: [RFC] SIP conntrack handler and TCP fragmentation

[Ulrich Weber <uweber.linux@gmail.com>]

Hi Florian,

On 12.10.2016 09:52, Florian Westphal wrote:
> Ulrich Weber <ulrich.weber@gmail.com> wrote:
>> I know the proper solution would be TCP defragmentation
>> in the nf_conntrack_sip kernel module. However I'm not
>> sure if this is worth the effort.
> 
> I think an even better solution would be a SIP proxy that can
> inject expectations to keep datapath in kernel and only deals with
> the signalling traffic.
Yes your right, is there already one capable of doing this?
But then again, I dont want to put a proxy on an embedded box ;)

> 
>> What about just accepting unparsable TCP SIP packets?
> 
> I wonder why this patch did not fix your problem:
> 
> 3a7b21eaf4fb3c971bdb47a98f570550ddfe4471
> Author: Patrick McHardy <kaber@trash.net>
> netfilter: nf_ct_sip: don't drop packets with offsets pointing outside the packet
> 
> It specifically deals with this problem (l7 size larger than packet
> size).
>From reading the code this fixed the problem when Content-Length
points to one of the next TCP fragments.

In our case Content-Length is always 0 with a couple of SUBSCRIBE calls.
E.g. a TCP packet starting with this will break the SIP connection tracking:

INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE
Content-Length: 0

The previous TCP packet was accepted by SIP connection tracking
because it had no Content-Length field.

Cheers
 Ulrich