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
|