[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B4F18B8.8060708@gmail.com>
Date: Thu, 14 Jan 2010 14:14:32 +0100
From: Eric Dumazet <eric.dumazet@...il.com>
To: William Allen Simpson <william.allen.simpson@...il.com>
CC: David Miller <davem@...emloft.net>, andi@...stfloor.org,
shemminger@...tta.com, netdev@...r.kernel.org,
linux-api@...r.kernel.org
Subject: Re: [PATCH] tcp: Generalized TTL Security Mechanism
Le 14/01/2010 13:38, William Allen Simpson a écrit :
> David Miller wrote:
>> The idea is that the min_ttl is set very high, so that
>> you'll only accept packets from hosts that started with
>> a ttl of 255 and are within a hop or two from you. (therefore
>> you'd set min_ttl to 254 or 253, something like that)
>>
> That's not a particularly good idea:
>
> http://www.iana.org/assignments/ip-parameters
>
> IP TIME TO LIVE PARAMETER
>
> The current recommended default time to live (TTL) for the Internet
> Protocol (IP) is 64 [RFC791, RFC1122].
>
> ===
>
> It always bugs me that things get incorrectly labeled "security", yet
> cannot secure anything.
>
> Security requires a secret.
>
> Various folks tried all kinds of games with TTL for BGP, but the only
> thing that _actually_ provided security was MD5 authentication.
Nobody forces you to use RFC 5082, I never had.
But if you use it, better read it before, and not use default ttl of 64 on
devices wanting to connect to your host.
Note this TTL Security mechanism is not replacing MD5 protection
The Generalized TTL Security Mechanism (GTSM) is designed to protect
a router's IP-based control plane from CPU-utilization based attacks.
In particular, while cryptographic techniques can protect the router-
based infrastructure (e.g., BGP [RFC4271], [RFC4272]) from a wide
variety of attacks, many attacks based on CPU overload can be
prevented by the simple mechanism described in this document. Note
that the same technique protects against other scarce-resource
attacks involving a router's CPU, such as attacks against processor-
line card bandwidth.
Its only a potential protection against CPU overload.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists