netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>, netdev@vger.kernel.org
Subject: Re: [PATCH 7/12] [IPSEC]: Remove xfrmX_tunnel_check_size
Date: Tue, 16 Oct 2007 16:38:04 +0200	[thread overview]
Message-ID: <4714CCCC.2040504@trash.net> (raw)
In-Reply-To: <E1IhnHJ-0003A4-00@gondolin.me.apana.org.au>

Herbert Xu wrote:
> [IPSEC]: Remove xfrmX_tunnel_check_size
> 
> These functions have always been causing trouble by sending ICMP errors
> back to the local host which was totally confused about how to deal with
> it and most often ended up causing a downward spiral which only finishes
> when the MTU is so small that you can't send packets out anymore.
> 
> They're also wrong now that we have inter-family transforms.  They'll
> end up trying to shove an IPv4 packet into the IPv6 ICMP stack and vice
> versa.
> 
> In fact, I've just realised that they are totally unnecessary.  The reason
> is that whoever calls us should have already checked the MTU.  In particular,
> there are two cases:
> 
> 1) The packet is forwarded in which case the forwarding function would've
> performed the check.
> 
> 2) The packet is local in which case whoever generated it should've checked.
> If they didn't check then us sending back an ICMP error wouldn't do any good
> anyway since the next time they transmit they'll still get it wrong.
> 
> So the only time this function has an effect is when the MTU happens to
> change between the caller checking it and us checking it.  This is useless
> because if we did catch such a change there's nothing stopping a further
> MTU change between us checking it and the packet actually getting to the
> device.


Thats true, but for the first case we actually have something in the
stack doing that, which is NAT and routing by fwmark. Maybe netfilter
should just send an ICMP error back, that would also solve the problem
of silently dropped packets when rerouting to an unreachable
destination.

  parent reply	other threads:[~2007-10-16 14:38 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-16 14:18 [0/12] Trying to merge xfrm input path before I got side-tracked Herbert Xu
2007-10-16 14:33 ` [PATCH 1/12] [IPSEC]: Fix pure tunnel modes involving IPv6 Herbert Xu
2007-10-16 14:33 ` [PATCH 2/12] [IPSEC]: Move tunnel parsing for IPv4 out of xfrm4_input Herbert Xu
2007-10-16 14:33 ` [PATCH 3/12] [IPSEC]: Get nexthdr from caller in xfrm6_rcv_spi Herbert Xu
2007-10-16 14:33 ` [PATCH 4/12] [IPSEC]: Move ip_summed zapping out of xfrm6_rcv_spi Herbert Xu
2007-10-16 14:33 ` [PATCH 5/12] [IPSEC]: Fix length check in xfrm_parse_spi Herbert Xu
2007-10-16 14:33 ` [PATCH 6/12] [IPSEC]: Move type and mode map into xfrm_state.c Herbert Xu
2007-10-16 14:33 ` [PATCH 7/12] [IPSEC]: Remove xfrmX_tunnel_check_size Herbert Xu
2007-10-16 14:33 ` [PATCH 8/12] [IPSEC]: Store afinfo pointer in xfrm_mode Herbert Xu
2007-10-16 14:33 ` [PATCH 9/12] [IPSEC]: Use the top IPv4 route's peer instead of the bottom Herbert Xu
2007-10-16 14:33 ` [PATCH 10/12] [IPSEC]: Disallow combinations of RO and AH/ESP/IPCOMP Herbert Xu
2007-10-16 14:33 ` [PATCH 11/12] [IPSEC]: Reinject packet instead of calling netfilter directly on input Herbert Xu
2007-10-16 15:05   ` YOSHIFUJI Hideaki / 吉藤英明
2007-10-16 15:12     ` Herbert Xu
2007-10-16 14:33 ` [PATCH 12/12] [NET]: Add netif_rerx_secpath Herbert Xu
     [not found] ` <E1IhnHJ-0003A4-00@gondolin.me.apana.org.au>
2007-10-16 14:38   ` Patrick McHardy [this message]
2007-10-16 15:17     ` [PATCH 7/12] [IPSEC]: Remove xfrmX_tunnel_check_size Herbert Xu
2007-10-16 14:39 ` [0/12] Trying to merge xfrm input path before I got side-tracked Patrick McHardy
2007-10-16 14:44   ` Herbert Xu

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=4714CCCC.2040504@trash.net \
    --to=kaber@trash.net \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=netdev@vger.kernel.org \
    /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).