Re: IPv6 fragmentation and IPv6 header parsing

[Brad Chapman <kakadu@xxxxxxxxxxxxx>]

Mr. Harald,

Harald Welte wrote:

> On Mon, Jul 30, 2001 at 12:54:35PM -0400, Brad Chapman wrote:
>
> >    That's exactly what I was afraid of. The problem is that in order to 
> > implement connection tracking _without_ fragment handling for IPv6, one would
> > have to implement something like the options below:
> >
> >    - No fragment handling; just configure your PMTU to a proper link size and
> >      NF_DROP fragmented packets; they belong to a broken implementation.
> >      This one is probably the most compliant with RFC2460, but if you must
> >      have fragmenting, you would need to run ip6_conntrack on an internal
> >      gateway and configure an external one to do relevant source fragging.
>
>
> I guess you misunderstood something about IPv6. Having fragments is totally
> legal, just routers don't fragment on-the-fly. But if one of the end nodes
> of the connections want to fragment, they are allowed (but discouraged)
> to do so.

    Well, okay. I was under the impression that if you configured your 
low-level
hardware to a decent PMTU size and somebody was doing fragmenting, that 
it was
broken and didn't deserve to be tracked. What do you mean by "discouraged" ?

> >    - skb_clone() packets. Hold original; defrag copy, push into 
> >      connection tracking subsystem. If packet makes it through, delete copy
> >      and release original. This one is not as bad as defragging original
> >      packets, but it is in violation of RFC2460 and sounds kludgy and bloaty.
>
>
> well... it is a hack, yes.  If it really is in violation of the RFC - I'm not
> sure.  
>
> As long as the conntrack does not send the defragmented copy of the packet,
> but just delays the delivery of the fragmented original packets it could be
> ok, IMHO.  (The defragmented packet would only be used for conntrack 
> internally).

   That could be a major problem. How much of a delay would be reasonable?
Something like (time to pass through conntrack) + (time to skb_clone() 
packet) ?

> Another idea would be to defragment the packet internally while forwarding
> all fragments which don't have the 'final fragment' bit in the IPv6 header
> set.  After we receive the last fragment of the packet, we send the 
> internally defragged copy of the whole packet through conntrack.  If the
> decision of some policy says the packet is to be DROPPEd, we just never send
> the last fragment, in which case the receiver has to drop all fragments after
> 60 seconds (or something like that, RFC2460 is more precise).

    Ahhh. That makes sense. So you just grab the fragment header, and 
look for
the final fragment bit. Thus, the code path would be:

  - fragmented packet arrives at ip6_conntrack_in()
  - ip6_conntrack_in() scans frag header, looking for `final fragment' bit
  - not there: send it onward         there: stop forwarding
  - ip6_conntrack_in() calls ip6_ct_gather_frags(), who calls 
ip6_reassembly()
  - we send the defragmented packet through conntrack
  - NF_ACCEPT: send the final fragment onward        NF_DROP: drop the 
final fragment

  Is this correct? If not, then please point me in the correct 
direction ;-)

> I don't think that this is a good solution either, but just needs to be
> taken into consideration.
>
> >    - Rewrite the entire codebase to work properly with fragmented packets.
> >      Add functions like ip6_frag_scan() to scan fragmented packets, and
> >      change all packet-related stuff to use fragment functions to locate
> >      relevant packet data. TBH, that sounds frightening and personally, I
> >      wouldn't want to implement it.
>
>
> Yes. This is what I would like to see in a 2.5.x rework of the whole 
> conntrack, while also lifting it to a layer-3-protocol independent layer
> (which would be needed for IPv4 <-> IPv6 NAT needed by lots of transition
> scenarios).

  Well, that's another thing entirely, and would have to wait until 2.5 
is mandated.
OT1: does anybody know if Linus thinks it's time to open a 2.5 tree?

> >    If given a choice, and told that doing constant defrag/refrag of IPv6
> >    packets is slow, inefficient, and in violation of the RFCs (as I have been
> >    told), I would choose the first option.
>
>
> I would most likely go for the 'defragment internally, delay fragments'
> approach.  You have to take care of possible DoS attacks, be aware.

  I agree. Anything like what we've just discussed would have to wait 
until you
(or someone on the list) figured out a good way to select packets for 
trackage.
OT2: any ideas? I can think of one already, but Henrik Nordstrom told me 
it would
add some overhead.

> >    BTW, what about header parsing? Am I at least doing that correctly?
>
>
> sorry, didn't have the time to go through that.

  Please have a look. Kis-Szabo Andras helped me out a lot on this, but 
I would
also like to ask someone who lives, breathes, and eats IPv6 ;-)

> > Brad
> >
> > P.S.: Mr. Harald, I didn't know you subscribed to netdev....
>
>
> ;) well, I guess everybody related to linux networking development is 
> subscribed here. And certainly all netfilter core team members fit within
> that group...

    Maybe I should subscribe as well..... ;-) Anyway, AOTB is great 
discussion
for now, but I have started to play with the code and have found some 
more bugs
in either ip6_conntrack, the ethertap setup, or the testsuite packet 
generators.
Plus, the ip6t_state module is giving me fits about `unrecognized 
arguments' >:-(
I'll have to compile with -D0 and pore over the logs for a while......

Brad

>