From archie@whistle.com Wed Mar 24 14:58:34 1999
Return-Path: <archie@whistle.com>
Received: from bubba.whistle.com (s205m7.whistle.com [207.76.205.7])
	by hub.freebsd.org (Postfix) with ESMTP id 2B44614E53
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 24 Mar 1999 14:58:34 -0800 (PST)
	(envelope-from archie@whistle.com)
Received: (from archie@localhost)
	by bubba.whistle.com (8.9.2/8.9.2) id OAA94806;
	Wed, 24 Mar 1999 14:58:15 -0800 (PST)
Message-Id: <199903242258.OAA94806@bubba.whistle.com>
Date: Wed, 24 Mar 1999 14:58:15 -0800 (PST)
From: Archie Cobbs <archie@whistle.com>
Reply-To: archie@whistle.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: "ipforward_rt" is not cleared when routing table changes
X-Send-Pr-Version: 3.2

>Number:         10778
>Category:       kern
>Synopsis:       "ipforward_rt" is not cleared when routing table changes
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    ru
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Mar 24 15:00:00 PST 1999
>Closed-Date:    Mon Nov 27 15:09:53 GMT 2006
>Last-Modified:  Mon Nov 27 15:09:53 GMT 2006
>Originator:     Archie Cobbs
>Release:        FreeBSD 4.x-current, 3.1
>Organization:
Whistle Communications, Inc.
>Environment:

	FreeBSD 3.1 and 4.x-current

>Description:

	The variable "ipforward_rt" in ip_input.c holds a cached route.
	This cached route should be cleared whenever there is a change
	to the routing table, but this is not being done.

	The affect is that a FreeBSD router could end up mis-routing
	packets for an arbitrarily long time in the future.

	In case the new route being added is for a secure VPN, then
	the result is that private data could suddenly start being
	sent out to the world.

>How-To-Repeat:

>Fix:
	
	Whenever the IP routing table changes, clear the cached route if any.


>Release-Note:
>Audit-Trail:

From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
To: archie@whistle.com
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: kern/10778: "ipforward_rt" is not cleared when routing table changes
Date: Thu, 25 Mar 1999 09:36:16 -0500 (EST)

 <<On Wed, 24 Mar 1999 14:58:15 -0800 (PST), Archie Cobbs <archie@whistle.com> said:
 
 > 	The variable "ipforward_rt" in ip_input.c holds a cached route.
 > 	This cached route should be cleared whenever there is a change
 > 	to the routing table, but this is not being done.
 
 No.  If the route is deleted, it will be marked `down'.  There is no
 need to explicitly clear all references to it.
 
 -GAWollman
 
 --
 Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the same
 wollman@lcs.mit.edu  | O Siem / The fires of freedom 
 Opinions not those of| Dance in the burning flame
 MIT, LCS, CRS, or NSA|                     - Susan Aglukark and Chad Irschick
 

From: Bill Fenner <fenner@research.att.com>
To: freebsd-gnats-submit@freebsd.org
Cc:  
Subject: Re: kern/10778: "ipforward_rt" is not cleared when routing table changes
Date: Fri, 30 Apr 1999 12:09:47 -0700

 I agree with Archie, although it's more like all cached routes should
 be cleared when the routing table changes in a way that affects the
 cached route.  Scenario:
 
 - default route exists.  Start TCP connection, which caches the default
   route.
 - add a host route for the endpoint of the TCP connection pointing
   out a different interface (perhaps a secure VPN interface as Archie
   mentioned).
 - TCP continues to use the default route.  The only way to get TCP to
   stop using the default route is to delete the default route and then
   re-add it, which is a little too disruptive.
 
 (I first saw this problem occur in earnest when I added route caching
 to the kernel multicast tunnel code -- multicast tunnels are pretty
 long-lived)
 
 Unfortunately, the current route cache architecture has no facility
 to deal with this problem.  There is no list of cached routes, and
 there is no way to notify cached routes that a change has occurred.
 
 If anyone cares to work on this, I'd imagine storing the destination
 of each cached route in a patricia tree would make it easy to determine
 the subset of cached routes that need to be invalidated when a given
 new route is added.
 
   Bill
 

From: John Polstra <jdp@polstra.com>
To: freebsd-gnats-submit@freebsd.org
Cc: archie@freebsd.org, wollman@khavrinen.lcs.mit.edu,
	fenner@research.att.com
Subject: Re: kern/10778: "ipforward_rt" is not cleared when routing table changes
Date: Thu, 26 Oct 2000 11:09:33 -0700 (PDT)

 I have confirmed that the problem Archie described is real, and the
 cause is as he describes it.  The problem is easy to reproduce when
 tunneling some routes through a VPN.  In this case there is a default
 route which points to the normal gateway, and there are some network
 routes pointing to the VPN gateway.  The the problem is reproduced
 as follows:
 
     - Communicating with a host 192.168.1.1 which is on the VPN.
       The route for 192.168.1.0/24 sends the packets to the VPN
       gateway.
 
     - The VPN link goes down or is shut down.
 
     - Packets destined for 192.168.1.1 now get routed to the default
       gateway (which of course fails to deliver them to the right
       place).  Note that the ipforward_rt cache is (correctly) ignored
       in this case because the route it points to is no longer up.
 
     - ipforward_rt records that the route to 192.168.1.1 is via the
       default gateway.
 
     - The VPN link is brought back up.
 
     - But packets for 192.168.1.1 still get sent to the default
       gateway because of the cached route in ipforward_rt.  If the
       VPN gateway is a separate host from the default gateway and we
       are communicating with only a single host on the VPN, this
       situation can endure indefinitely.
 
 Sending a packet to, say 192.168.1.2 replaces the bad ipforward_rt
 entry and gets things working again.
 
 One easy hack would be to ignore ipforward_rt if it is more than, say,
 2 seconds old.  This isn't a real fix, but it would at least limit the
 duration of the damage.  The performance penalty would be negligible
 in real life.
 
 The downside of implementing this hack is that it might prevent a
 real fix from ever getting made.
 
 John
 

From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
To: John Polstra <jdp@polstra.com>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: kern/10778: "ipforward_rt" is not cleared when routing table changes
Date: Thu, 26 Oct 2000 16:54:42 -0400 (EDT)

 <<On Thu, 26 Oct 2000 11:09:33 -0700 (PDT), John Polstra <jdp@polstra.com> said:
 
 > One easy hack would be to ignore ipforward_rt if it is more than, say,
 > 2 seconds old.  This isn't a real fix, but it would at least limit the
 > duration of the damage.  The performance penalty would be negligible
 > in real life.
 
 Yes, this is a bug.  The right fix is to change the IP code so that,
 when it gets notified of a routing change, ipforward_rt (and
 presumably ip6forward_rt if there is such a thing) get cleared
 automatically.  This could easily be done in a couple of lines in
 netinet/in_rmx.c:in_addroute().  ipforward_rt would also have to be
 unstaticked in ip_input.c and declared in a useful header file.
 
 The code which would make things Just Work doesn't happen in the
 forwarding case because protocol-based cloning is (intentionally)
 disabled.
 
 -GAWollman
 
 
State-Changed-From-To: open->analyzed 
State-Changed-By: ru 
State-Changed-When: Wed Jun 6 07:30:49 PDT 2001 
State-Changed-Why:  
The ipforward_rt part has been fixed in in_rmx.c,v 1.39. 


Responsible-Changed-From-To: freebsd-bugs->ru 
Responsible-Changed-By: ru 
Responsible-Changed-When: Wed Jun 6 07:30:49 PDT 2001 
Responsible-Changed-Why:  
I will work on the remnants of this problem. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=10778 
State-Changed-From-To: analyzed->patched 
State-Changed-By: bms 
State-Changed-When: Wed Jun 23 01:43:55 GMT 2004 
State-Changed-Why:  
Obsoleted by introduction of ip_forward_cacheinval() by sam 
in in_rmx.c rev 1.46, in -CURRENT. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=10778 

From: Ruslan Ermilov <ru@FreeBSD.org>
To: Bruce M Simpson <bms@FreeBSD.org>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/10778: "ipforward_rt" is not cleared when routing table changes
Date: Wed, 23 Jun 2004 09:16:38 +0300

 On Wed, Jun 23, 2004 at 01:44:18AM +0000, Bruce M Simpson wrote:
 > Synopsis: "ipforward_rt" is not cleared when routing table changes
 > 
 > State-Changed-From-To: analyzed->patched
 > State-Changed-By: bms
 > State-Changed-When: Wed Jun 23 01:43:55 GMT 2004
 > State-Changed-Why: 
 > Obsoleted by introduction of ip_forward_cacheinval() by sam
 > in in_rmx.c rev 1.46, in -CURRENT.
 > 
 This particular bug with ipforward_rt was fixed long before this
 commit, in rev. 1.39 of in_rmx.c (and merged).  What's not fixed
 still is the issue with socket's cached routes (see Bill Fenner's
 description in the PR).
 
 
 Cheers,
 -- 
 Ruslan Ermilov
 ru@FreeBSD.org
 FreeBSD committer
State-Changed-From-To: patched->analyzed 
State-Changed-By: bms 
State-Changed-When: Wed Jun 23 06:40:34 GMT 2004 
State-Changed-Why:  
Not fully fixed. Cached routes still need to be addressed at 
the socket level. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=10778 

From: Bruce M Simpson <bms@spc.org>
To: Ruslan Ermilov <ru@FreeBSD.org>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/10778: "ipforward_rt" is not cleared when routing table changes
Date: Wed, 23 Jun 2004 07:41:16 +0100

 On Wed, Jun 23, 2004 at 09:16:38AM +0300, Ruslan Ermilov wrote:
 > This particular bug with ipforward_rt was fixed long before this
 > commit, in rev. 1.39 of in_rmx.c (and merged).  What's not fixed
 > still is the issue with socket's cached routes (see Bill Fenner's
 > description in the PR).
 
 Could this be related to kern/38554 ?
 
 BMS

From: Ruslan Ermilov <ru@FreeBSD.org>
To: Bruce M Simpson <bms@spc.org>,
	Andre Oppermann <andre@FreeBSD.org>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/10778: "ipforward_rt" is not cleared when routing table changes
Date: Wed, 23 Jun 2004 10:12:22 +0300

 On Wed, Jun 23, 2004 at 07:41:16AM +0100, Bruce M Simpson wrote:
 > On Wed, Jun 23, 2004 at 09:16:38AM +0300, Ruslan Ermilov wrote:
 > > This particular bug with ipforward_rt was fixed long before this
 > > commit, in rev. 1.39 of in_rmx.c (and merged).  What's not fixed
 > > still is the issue with socket's cached routes (see Bill Fenner's
 > > description in the PR).
 > 
 > Could this be related to kern/38554 ?
 > 
 No, it's different.  PR kern/38554 describes the problem with connected
 sockets, when local address gets deleted -- they are still bound to the
 old address.
 
 This one talks about changing the routing table, and socket's cached
 routes not getting invalidated.  I believe that this problem got
 addressed by introduction of TCP hostcache (there's no inp_route now),
 and ip_output() is now passed a null route pointer.  Andre, am I correct?
 If so, I don't think there are plans to address this problem in RELENG_4,
 so it can probably be closed.
 
 
 Cheers,
 -- 
 Ruslan Ermilov
 ru@FreeBSD.org
 FreeBSD committer

From: Andre Oppermann <andre@freebsd.org>
To: Ruslan Ermilov <ru@FreeBSD.org>
Cc: Bruce M Simpson <bms@spc.org>, bug-followup@FreeBSD.org
Subject: Re: kern/10778: "ipforward_rt" is not cleared when routing table changes
Date: Wed, 23 Jun 2004 12:55:09 +0200

 Ruslan Ermilov wrote:
 > 
 > On Wed, Jun 23, 2004 at 07:41:16AM +0100, Bruce M Simpson wrote:
 > > On Wed, Jun 23, 2004 at 09:16:38AM +0300, Ruslan Ermilov wrote:
 > > > This particular bug with ipforward_rt was fixed long before this
 > > > commit, in rev. 1.39 of in_rmx.c (and merged).  What's not fixed
 > > > still is the issue with socket's cached routes (see Bill Fenner's
 > > > description in the PR).
 > >
 > > Could this be related to kern/38554 ?
 > >
 > No, it's different.  PR kern/38554 describes the problem with connected
 > sockets, when local address gets deleted -- they are still bound to the
 > old address.
 > 
 > This one talks about changing the routing table, and socket's cached
 > routes not getting invalidated.  I believe that this problem got
 > addressed by introduction of TCP hostcache (there's no inp_route now),
 > and ip_output() is now passed a null route pointer.  Andre, am I correct?
 > If so, I don't think there are plans to address this problem in RELENG_4,
 > so it can probably be closed.
 
 The described problem is fixed since 5.2R with the removal of PR_CLONING
 and the introduction of tcp_hostcache.
 
 I don't have plans to merge/fix this for RELENG_4.  However one of Luigi's
 students has ported tcp_hostcache to 4.9 IIRC.  That might be a way to
 fix it.  Although I am unsure if such a big change is ok for RELENG_4.
 
 -- 
 Andre
State-Changed-From-To: analyzed->closed 
State-Changed-By: ru 
State-Changed-When: Mon Nov 27 15:09:34 UTC 2006 
State-Changed-Why:  
It's been all long fixed for IPv4. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=10778 
>Unformatted:
