Re: TTL patch buggy?

["John A. Sullivan III" <john.sullivan@nexusmgmt.com>]

On Wed, 2004-01-07 at 14:35, Harald Welte wrote:
> On Wed, Jan 07, 2004 at 02:04:36PM -0500, John A. Sullivan III wrote:
> > Thank you very much but could you please explain this a bit more.  Oskar
> > Andreasson's tutorial explicitly mentions doing this, i.e., incrementing
> > TTL and we thought it was a good idea.  We certainly want to change our
> > ways if this is dangerous.  Here is the excerpt from the tutorial:
> 
> Well, as indicated in my last emai:
> 
> 1) it is dangerous to increment the TTL
> 2) still, there are vallid uses.
> 
> In gerneral, incrementing packets heading towards your internal network
> shouldn't be a problem.  If people want to hide their internal network
> structure from traceroute, they have two options:
> 
> a) drop all packets that have a ttl < number_of_hops_in_internal_net
> b) increment the TTL by number_of_hops_in_internal_net
> 
> Both ways make sure that the TTL never expires on a router in the
> internal network.
> 
> Where 'a' would interrupt traffic, and 'b' would make sure traffic
> passes.
<snip>
Thanks to all of you for such insightful replies.  As I synthesize them,
I see some problems and a possible solution.
1) Incrementing does create the possibility of routing loops although
this is minimal for end points.
2) Dropping packets with ttl < number_of_internal_hops may be safer but
requires a knowledge of the internal environment and incurs an overhead
with every internal change.
3) sysctl seems to provide no way to simply not send ttl expired
messages
4) If the goal is simply to hide the firewall, could one just drop all
packets where ttl == 1.  These packets would never make it only the
internal network anyway; it does not require incrementing ttl and 
requires no knowledge of the internal network.  I assume that, since one
can prevent the ttl expired from being sent by incrementing, that
netfilter will grab and drop the packet before the ttl expired
notification is sent.  Is there a problem with this approach?
-- 
John A. Sullivan III
Chief Technology Officer
Nexus Management
+1 207-985-7880
john.sullivan@nexusmgmt.com
---
If you are interested in helping to develop a GPL enterprise class
VPN/Firewall/Security device management console, please visit
http://iscs.sourceforge.net