Message-Id: <200209270300.g8R30CX2027449@marajade.sandelman.ottawa.on.ca>
To: "David S. Miller" <davem@redhat.com>
cc: jmorris@intercode.com.au, rusty@rustcorp.com.au, nf@hipac.org,
       linux-kernel@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: [ANNOUNCE] NF-HIPAC: High Performance Packet Classification for Netfilter 
In-reply-to: Your message of "Thu, 26 Sep 2002 13:52:59 PDT."
             <20020926.135259.62665945.davem@redhat.com> 
Mime-Version: 1.0 (generated by tm-edit 1.8)
Content-Type: text/plain; charset=US-ASCII
Date: Thu, 26 Sep 2002 23:00:12 -0400
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3179
Lines: 68

-----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-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/