netdev - Re: [PATCH] tcp: Generalized TTL Security Mechanism

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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