Re: TTL/Auth Redux
Pekka Savola <pekkas@netcore.fi> Sun, 13 March 2005 19:00 UTC
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02282; Sun, 13 Mar 2005 14:00:40 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAYNu-0003BA-Ld; Sun, 13 Mar 2005 14:04:18 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAYJz-0000qj-LN; Sun, 13 Mar 2005 14:00:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAYJy-0000qd-9w for rtg-bfd@megatron.ietf.org; Sun, 13 Mar 2005 14:00:14 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02252 for <rtg-bfd@ietf.org>; Sun, 13 Mar 2005 14:00:10 -0500 (EST)
Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAYNR-0003AG-21 for rtg-bfd@ietf.org; Sun, 13 Mar 2005 14:03:49 -0500
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j2DIxub12981; Sun, 13 Mar 2005 20:59:56 +0200
Date: Sun, 13 Mar 2005 20:59:56 +0200
From: Pekka Savola <pekkas@netcore.fi>
To: Dave Katz <dkatz@juniper.net>
In-Reply-To: <302ea42bfd6ba31bd7af777d8a017d42@juniper.net>
Message-ID: <Pine.LNX.4.61.0503132043370.12535@netcore.fi>
References: <302ea42bfd6ba31bd7af777d8a017d42@juniper.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: "'rtg-bfd@ietf.org'" <rtg-bfd@ietf.org>
Subject: Re: TTL/Auth Redux
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
Sender: rtg-bfd-bounces@ietf.org
Errors-To: rtg-bfd-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
On Fri, 11 Mar 2005, Dave Katz wrote: > Toward the end of the discussion, it appeared that Pekka's concerns were > based on the assumption that a system had to attempt to validate any packet > carrying authentication that it saw. I have three main concerns: 1) if the system is not configured to use authentication, but the attacker sends you packets with Auth bit set which would be demultiplexed to an existing or new session -- and you don't discard the packets (because the authentication is disabled) before demultiplexing occurs, you end up having to perform SHA1 operations on the attack packet. This is an easy demultiplexing computation DoS attack. 2) if the system is configured to use authentication, but A bit is not set and would be demuxed to an exising or new session, is the packet discarded before performing SHA1 computation? (It seems so, but I'm not 100% sure). 3) If the system is configured to use authentication, and A bit is set in packets sent from an off-link attacker, the attacker is able to perform a SHA1 authentication attack on any router using BFD authentication can be mitigated to the local link if TTL=255 check is done first. The result could be that the operators would be _afraid_ to turn on authentication because that would open an off-link attack vector. ... For 1) and 2), the spec doesn't appear to be 100% clear what the behaviour is (the last sentences of the first paragraph -- maybe this is due to the auth/no-auth transition without session reset?) and 3) is clearly an issue unless the receivers are mandated to perform TTL=255 check unless otherwise configured. [Section 6.7.6:] If the Your Discriminator field is zero, the session MUST be selected based on some combination of other fields, possibly including source addressing information, the My Discriminator field, and the interface over which the packet was received. The exact method of selection is application-specific and is thus outside the scope of this specification. If a matching session is not found, a new session may be created, or the packet may be discarded. This choice is outside the scope of this specification. If the A bit is set and no authentication is in use (bfd.AuthType is zero), the packet MUST be discarded. If the A bit is clear and authentication is in use (bfd.AuthType is nonzero), the packet MUST be discarded. > My intent was twofold. First, the only purpose of the TTL check was as a > really lousy form of authentication--if other forms of authentication are in > use, the TTL check is unnecessary. Second, I am concerned about the > unintended consequences of this check. There is an existence proof (or at > least a historical existence proof) of media that appear as a single network > layer hop, but decrement TTL in mid-link (tunneling schemes), as well as > systems that decrement TTL when they ought not to. These don't appear to be "single-hop" BFD sessions ? This seems hacking around broken media to be "pseudo single-hop" while they really aren't? While I can see why addressing these may be lucrative from the practical point-of-view, maybe we should be just making sure that multihop BFD works well in these scenarios? > It's also my contention that if you *are* going to use authentication, you > *must* have a generic mechanism for avoiding DoS attacks on the crypto > engine, since otherwise you *must* trust all potential sources of packets (in > which case the authentication is unnecessary.) DoS attacks from the same link vs DoS attacks from anywhere in the Internet have a very different attack vector. The operators may consider the first case to be acceptable (e.g., the customer's link, or semi-trusted IX fabric), but the latter requires another mechanisms for security. Hopefully this clarifies what kind of attacks I'm worried about. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
- TTL/Auth Redux Dave Katz
- Re: TTL/Auth Redux Pekka Savola
- Re: TTL/Auth Redux Dave Katz
- Re: TTL/Auth Redux Pekka Savola
- Re: TTL/Auth Redux Carlos Garcia Braschi
- Re: TTL/Auth Redux Dave Katz
- Re: TTL/Auth Redux Dave Katz
- Re: TTL/Auth Redux David Ward
- Re: TTL/Auth Redux Dave Katz
- Re: TTL/Auth Redux Pekka Savola
- Re: TTL/Auth Redux Dave Katz