Re: [ANNOUNCE] NF-HIPAC: High Performance Packet Classification for Netfilter

Re: [ANNOUNCE] NF-HIPAC: High Performance Packet Classification for Netfilter

[James Morris]

On Wed, 25 Sep 2002, David S. Miller wrote:

> If you have things that must happen in a sequence to flow through
> your path properly, that's where the "stackable" bit comes in.  You
> do that one bit, skb->dst = dst_pop(skb->dst), then your caller
> will pass the packet on to skb->dst->{output,input}().
> 
> Is it clearer now the kind of things you'll be able to do?
> 

So, this could be used for generic network layer encapsulation, and be 
used for GRE tunnels, SIT etc. without the kinds of kludges currently in 
use?  Sounds nice.


- James
-- 
James Morris
<jmorris@intercode.com.au>

Re: [ANNOUNCE] NF-HIPAC: High Performance Packet Classification for Netfilter

[James Morris]

On Thu, 26 Sep 2002, James R. Leu wrote:

> I missed the original post.  Is there a patch availble for testing?

I don't think so, you can follow the lkml thread from 
http://marc.theaimsgroup.com/?l=linux-kernel&m=103299391126734&w=2

(Jamal asked for the discussion to be cc'd to netdev).


- James
-- 
James Morris
<jmorris@intercode.com.au>

Re: [ANNOUNCE] NF-HIPAC: High Performance Packet Classification for Netfilter

[James R. Leu]

I missed the original post.  Is there a patch availble for testing?

Jim

On Fri, Sep 27, 2002 at 01:27:41AM +1000, James Morris wrote:
> On Wed, 25 Sep 2002, David S. Miller wrote:
> 
> > If you have things that must happen in a sequence to flow through
> > your path properly, that's where the "stackable" bit comes in.  You
> > do that one bit, skb->dst = dst_pop(skb->dst), then your caller
> > will pass the packet on to skb->dst->{output,input}().
> > 
> > Is it clearer now the kind of things you'll be able to do?
> > 
> 
> So, this could be used for generic network layer encapsulation, and be 
> used for GRE tunnels, SIT etc. without the kinds of kludges currently in 
> use?  Sounds nice.
> 
> 
> - James
> -- 
> James Morris
> <jmorris@intercode.com.au>
> 
> 

-- 
James R. Leu

Re: [ANNOUNCE] NF-HIPAC: High Performance Packet Classification for Netfilter

[David S. Miller]

   From: James Morris <jmorris@intercode.com.au>
   Date: Fri, 27 Sep 2002 01:27:41 +1000 (EST)
   
   So, this could be used for generic network layer encapsulation, and be 
   used for GRE tunnels, SIT etc. without the kinds of kludges currently in 
   use?  Sounds nice.

Such IPIP tunnels have very real problems though, since only 64-bits
of packet quoting are required in ICMP errors, it is often impossible
to deal with PMTU requests properly, see "#ifndef
I_WISH_WORLD_WERE_PERFECT" in net/ipv4/ip_gre.c

Re: [ANNOUNCE] NF-HIPAC: High Performance Packet Classification for Netfilter

[Michael Richardson]

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "David" == David S Miller <davem@redhat.com> writes:
    David>    From: James Morris <jmorris@intercode.com.au>
    David>    Date: Fri, 27 Sep 2002 01:27:41 +1000 (EST)
   
    David>    So, this could be used for generic network layer encapsulation, and be 
    David>    used for GRE tunnels, SIT etc. without the kinds of kludges currently in 
    David>    use?  Sounds nice.

    David> Such IPIP tunnels have very real problems though, since only 64-bits
    David> of packet quoting are required in ICMP errors, it is often impossible
    David> to deal with PMTU requests properly, see "#ifndef
    David> I_WISH_WORLD_WERE_PERFECT" in net/ipv4/ip_gre.c

  IPsec tunnels are even worse, because, not only is there not enough
info returned, but, being paranoid, one should really not even trust it.
  ICMP Port not reachable for UDP port 500 are even more nasty, because
sometimes they indicate a REAL problem :-)

  Eons ago, I proposed a way to deal with this problem, see:
  http://www.sandelman.ottawa.on.ca/SSW/ietf/draft-richardson-ipsec-pmtu-discovery-00.txt

  I think that now that Linux doesn't linearize skbuff's prior to passing
them to protocol handlers, that I actually could get the fragment info from
the skb chain.

  Excerpt from document:

Gateway G2 upon receiving an ESP or AH packet that needs to be
reassembled, MUST take note of the size largest fragment received. This
value is compared to the previous largest fragment size. If this size
has changed by more than 10%, or more than 2*MSL time (i.e. 2 minutes)
has passed since the previous ICMP message, then an ICMP Datagram Too
Big message is generated. The largest fragment size is initialized to
576 bytes.
          
The ICMP datagram is addressed from gateway G2 to the originating node
C, and gives a size that is based on the maximum fragment size (above),
minus the IPsec overhead. The ICMP datagram is sent via the tunnel on
which the IPsec packet was a member. I.e. the ICMP is encapsulated.
                                                                       
A packet arriving at G1 with the DF bit set, does not cause the DF bit
to be set on the encapsulating datagram.

(proposal two changes the destination IP of the ICMP message) 

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBPZPJt4qHRg3pndX9AQGqYwP+JtDyOhQwV2kiFWqxs8H8QbU0OJmV/krd
rNhapv6/qzxcqHHPWHiypxQLZ3uYHcNKfwdoQFhOgVxdZXivkOnvn9bjoKDIp+EL
JKNNvSrHNZMJ9yQCqUnsI+2XknkR9bCOOK9DfTcJ9e2lSFlH7H1vSTnRo6GOJhVh
arQUa22xoc8=
=VAyj
-----END PGP SIGNATURE-----

Re: [ANNOUNCE] NF-HIPAC: High Performance Packet Classification for Netfilter

[jamal]

Dave,

now that i followed the thread on lk (slrn is great; thanks Jason);
I am actually interested to find out how you are going to pull what
you propose ;-> There are not that many things that will work well
with a dst-cache like idea. I actually considered the stacking idea
when i first was trying to prototype code that i posted. It is much harder
to make use of in practise. At least this is my experience.
If you look at the scheme i posted, youll see that the policy
could be to direct the packets to a IPV4-forwarding block or
totaly bypass it etc (i just didnt wanna jump into that step yet sicne it
is quiet involved architecturaly)
In any case we need to encourage people like the hipac authors to be
putting out things (i only wish theyd incorporate it into the tc
framework!); whatever changes made should consider that there is
more than one way to do things and people will always come with better
ways to do certain portions of the packet path.

cheers,
jamal

On Thu, 26 Sep 2002, David S. Miller wrote:

>    From: James Morris <jmorris@intercode.com.au>
>    Date: Fri, 27 Sep 2002 01:27:41 +1000 (EST)
>
>    So, this could be used for generic network layer encapsulation, and be
>    used for GRE tunnels, SIT etc. without the kinds of kludges currently in
>    use?  Sounds nice.
>
> Such IPIP tunnels have very real problems though, since only 64-bits
> of packet quoting are required in ICMP errors, it is often impossible
> to deal with PMTU requests properly, see "#ifndef
> I_WISH_WORLD_WERE_PERFECT" in net/ipv4/ip_gre.c
>
>
>

Re: [ANNOUNCE] NF-HIPAC: High Performance Packet Classification for Netfilter

[David S. Miller]

   From: jamal <hadi@cyberus.ca>
   Date: Fri, 27 Sep 2002 10:12:26 -0400 (EDT)
   
   whatever changes made should consider that there is more than one
   way to do things and people will always come with better ways to do
   certain portions of the packet path.

Of course.