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]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ