linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Richardson <mcr@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
Date: Thu, 26 Sep 2002 23:00:12 -0400	[thread overview]
Message-ID: <200209270300.g8R30CX2027449@marajade.sandelman.ottawa.on.ca> (raw)
In-Reply-To: Your message of "Thu, 26 Sep 2002 13:52:59 PDT." <20020926.135259.62665945.davem@redhat.com>

-----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-----

  reply	other threads:[~2002-09-27  2:55 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-25 22:41 [ANNOUNCE] NF-HIPAC: High Performance Packet Classification for Netfilter nf
2002-09-25 22:52 ` David S. Miller
2002-09-26  0:10   ` Rik van Riel
2002-09-26  0:25     ` David S. Miller
2002-09-26  0:38   ` nf
2002-09-26  0:37     ` David S. Miller
2002-09-26  1:44       ` nf
2002-09-26  3:30         ` David S. Miller
2002-09-26  5:19   ` Rusty Russell
2002-09-26  5:40     ` David S. Miller
2002-09-26 15:27       ` James Morris
2002-09-26 20:52         ` David S. Miller
2002-09-27  3:00           ` Michael Richardson [this message]
2002-09-27 14:12           ` jamal
2002-09-28  1:30             ` David S. Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200209270300.g8R30CX2027449@marajade.sandelman.ottawa.on.ca \
    --to=mcr@sandelman.ottawa.on.ca \
    --cc=davem@redhat.com \
    --cc=jmorris@intercode.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@oss.sgi.com \
    --cc=nf@hipac.org \
    --cc=rusty@rustcorp.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).