[RFC] TTL target goes mainline ?

[RFC] TTL target goes mainline ?

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1263 bytes --]

Hi!

As we are in the process of pushing more 'new' code from
patch-o-matic-ng into the mainline kernel, I was thinking whether or not
we should also submit potentially-dangerous targets such as the TTL
target to the kernel.

The TTL target allows setting, incrementing and decrementing of the TTL,
and is therefore extremely dangerous. OTOTH, there are ISP's that check
whether you use a router or not (and thus filter or not) by looking at
the TTL of every packet that comes in on your link - so there is a
practical use of this to a number of people.

At some point the kernel had a CONFIG_DANGEROUS, but that had been
removed. I think CONFIG_DANGEROUS would be exactly the right thing for
TTL manipulations.

So my proposal is to only allow decrementing (or setting to a value
below the original one) the TTL unless CONFIG_EXPERIMENTAL is set. 

What do you think?

-- 
- Harald Welte <laforge@netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC] TTL target goes mainline ?

[Patrick McHardy]

Harald Welte wrote:
> Hi!
> 
> As we are in the process of pushing more 'new' code from
> patch-o-matic-ng into the mainline kernel, I was thinking whether or not
> we should also submit potentially-dangerous targets such as the TTL
> target to the kernel.
> 
> The TTL target allows setting, incrementing and decrementing of the TTL,
> and is therefore extremely dangerous. OTOTH, there are ISP's that check
> whether you use a router or not (and thus filter or not) by looking at
> the TTL of every packet that comes in on your link - so there is a
> practical use of this to a number of people.
> 
> At some point the kernel had a CONFIG_DANGEROUS, but that had been
> removed. I think CONFIG_DANGEROUS would be exactly the right thing for
> TTL manipulations.
> 
> So my proposal is to only allow decrementing (or setting to a value
> below the original one) the TTL unless CONFIG_EXPERIMENTAL is set. 

Why not, people can just as easy shoot themselves using bridging or
tc actions. But I'm not sure about enabling only parts of functionality
without CONFIG_EXPERIMENTAL, why not simply depend entirely on it?

Re: [RFC] TTL target goes mainline ?

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 738 bytes --]

On Fri, Aug 26, 2005 at 01:43:55PM +0200, Patrick McHardy wrote:

> Why not, people can just as easy shoot themselves using bridging or
> tc actions. But I'm not sure about enabling only parts of functionality
> without CONFIG_EXPERIMENTAL, why not simply depend entirely on it?

because decrementing the TTL is considered safe, routers do it all the day ;)

-- 
- Harald Welte <laforge@netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC] TTL target goes mainline ?

[Patrick McHardy]

Harald Welte wrote:
> On Fri, Aug 26, 2005 at 01:43:55PM +0200, Patrick McHardy wrote:
> 
> 
>>Why not, people can just as easy shoot themselves using bridging or
>>tc actions. But I'm not sure about enabling only parts of functionality
>>without CONFIG_EXPERIMENTAL, why not simply depend entirely on it?
> 
> 
> because decrementing the TTL is considered safe, routers do it all the day ;)

Sure :) I just think its nicer than to enable "sub-functionality" by
config options, so if its there, its usable. I also don't think there
are people who actually have CONFIG_EXPERIMENTAL disabled, so in
the end, we just save a few ifdefs in the code.

Re: [RFC] TTL target goes mainline ?

[Phil Oester]

On Fri, Aug 26, 2005 at 03:41:27PM +0200, Patrick McHardy wrote:
> Sure :) I just think its nicer than to enable "sub-functionality" by
> config options, so if its there, its usable. I also don't think there
> are people who actually have CONFIG_EXPERIMENTAL disabled, so in
> the end, we just save a few ifdefs in the code.

Agree that almost everyone enables CONFIG_EXPERIMENTAL.  How about 
an IP_NF_TARGET_TTL_DEC which depends on IP_NF_TARGET_TTL, and which
has a nice big warning about being dangerous?

Phil

Re: [RFC] TTL target goes mainline ?

[Patrick McHardy]

Phil Oester wrote:
> On Fri, Aug 26, 2005 at 03:41:27PM +0200, Patrick McHardy wrote:
> 
>>Sure :) I just think its nicer than to enable "sub-functionality" by
>>config options, so if its there, its usable. I also don't think there
>>are people who actually have CONFIG_EXPERIMENTAL disabled, so in
>>the end, we just save a few ifdefs in the code.
> 
> Agree that almost everyone enables CONFIG_EXPERIMENTAL.  How about 
> an IP_NF_TARGET_TTL_DEC which depends on IP_NF_TARGET_TTL, and which
> has a nice big warning about being dangerous?

I think documenting the issue is enough, users have plenty of ways of
shooting themselves.

Re: [RFC] TTL target goes mainline ?

[David S. Miller]

From: Patrick McHardy <kaber@trash.net>
Date: Fri, 26 Aug 2005 17:24:28 +0200

> I think documenting the issue is enough, users have plenty of ways of
> shooting themselves.

I agree, let's not burdon new code with "this feature is dangerous"
ifdefs.

Re: [RFC] TTL target goes mainline ?

[Bill Rugolsky Jr.]

On Fri, Aug 26, 2005 at 01:18:32PM +0200, Harald Welte wrote:
> The TTL target allows setting, incrementing and decrementing of the TTL,
> and is therefore extremely dangerous. OTOTH, there are ISP's that check
> whether you use a router or not (and thus filter or not) by looking at
> the TTL of every packet that comes in on your link - so there is a
> practical use of this to a number of people.
 
Sharp tools are sometimes a necessity.  IMHO, it's better to give people
a standard sharp tool and teach them to use it, than to have each invent
their own.  Besides the ISP use, there are other applications where a
bit of routing infrastructure sometimes needs to be transparent, e.g.,
passing packets to virtual environments.

Since Quagga does not grok interface bundles, I use TTL
and ROUTE to make hdlc[0123] packets appear to arrive on teql0:

$ sudo /sbin/iptables -t mangle -vL PREROUTING
Chain PREROUTING (policy ACCEPT 1317K packets, 97M bytes)
 pkts bytes target     prot opt in     out     source               destination         
 571K   19M TTL        all  --  hdlc+  any     anywhere             anywhere            TTL increment by 1 
 571K   19M ROUTE      all  --  hdlc+  any     anywhere             anywhere            ROUTE iif:teql0 

Two netfilter rules removed a rewrite of Quagga's interface handling from
our critical path.

So please, submit TTL for mainline, guarded by however many config layers of
"we're not kidding! last exit! turn back!" warnings are required. :-)

Regards,

	Bill Rugolsky

Re: [RFC] TTL target goes mainline ?

[Maciej Soltysiak]

Hi!

> So my proposal is to only allow decrementing (or setting to a value
> below the original one) the TTL unless CONFIG_EXPERIMENTAL is set. 

> What do you think?
Not that my vote counts or anything but as a user and an ocasional
netfilter hacker I belive it is best to either:
- submit the target with its current set of options (decreasing, increasing,
  setting to a value) acompanied by EXPERIMENTAL flag and a warning in the
  help screen, maybe even an additional text in the option line, like
  "[m] TTL target (warning: see help!)"
- *or* leave it in pom-ng, so only people who now what they are doing would
  use it.

nb. This means that IPv6 HOPLIMIT should go in too. I guess.

-- 
Best regards,
Maciej