Re: TTL/Auth Redux
Dave Katz <dkatz@juniper.net> Sun, 13 March 2005 20:17 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 PAA07745; Sun, 13 Mar 2005 15:17:32 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAZaI-0005gd-Is; Sun, 13 Mar 2005 15:21:10 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAZUf-00077N-QJ; Sun, 13 Mar 2005 15:15:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAZUe-00077I-OJ for rtg-bfd@megatron.ietf.org; Sun, 13 Mar 2005 15:15:20 -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 PAA07476 for <rtg-bfd@ietf.org>; Sun, 13 Mar 2005 15:15:19 -0500 (EST)
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAZY6-0005bJ-Ft for rtg-bfd@ietf.org; Sun, 13 Mar 2005 15:18:57 -0500
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j2DKEx999540; Sun, 13 Mar 2005 12:15:01 -0800 (PST) (envelope-from dkatz@juniper.net)
Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j2DKEre31579; Sun, 13 Mar 2005 12:14:53 -0800 (PST) (envelope-from dkatz@juniper.net)
In-Reply-To: <Pine.LNX.4.61.0503132043370.12535@netcore.fi>
References: <302ea42bfd6ba31bd7af777d8a017d42@juniper.net> <Pine.LNX.4.61.0503132043370.12535@netcore.fi>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Message-Id: <0800c8fb4c7cf5af900919aec7dee613@juniper.net>
Content-Transfer-Encoding: 7bit
From: Dave Katz <dkatz@juniper.net>
Date: Sun, 13 Mar 2005 13:15:59 -0700
To: Pekka Savola <pekkas@netcore.fi>
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c
Content-Transfer-Encoding: 7bit
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: 932cba6e0228cc603da43d861a7e09d8
Content-Transfer-Encoding: 7bit
On Mar 13, 2005, at 11:59 AM, Pekka Savola wrote: > 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. I don't understand what you're trying to say. If the system is not configured to use authentication, the system will *never* try to authenticate, since it has no means to do so (what would it use for a key?) They will *always* be discarded. The discard is two-way--if authentication is disabled on a session, all authenticated packets will be discarded (as well as the opposite.) So there is no attack possible. > > 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). How could you perform the SHA1 computation on an unauthenticated packet? There's no authentication section, key ID, or hash to verify. There is no authentication calculation on unauthenticated packets, period, there can't be. Any implementor who runs a SHA1 checksum over the packet before checking whether it's necessary deserves to fail. > > 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. I'll throw out my argument about the futility of cryptographic authentication in an environment that is easily DoS'ed. But in any case, the language I suggested allows the TTL check for people who want to do that, it just doesn't mandate it (or bar it.) The order of the checks is outside the scope, as the intent of the protocol spec is not to protect half-baked implementations. Those folks who have DoS-able crypto engines are hopefully smart enough to use the tools the right way. The spec is *not* an implementation guide. > > ... > > 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. I don't get what you're trying to say here. The first paragraph deals with the case when you receive the first packet for a session (no Your Discr.) Whether or not you create a session or discard it depends on how BFD is being used, and is outside the scope of the base spec. Generally you would discard such packets (for example, in the OSPF case, both sides know there's going to be a BFD session by virtue of the OSPF neighbor relationship) but there are certainly cases where you might want to bootstrap a session based purely on BFD. But this is entirely orthogonal to the authentication question. As I said before, if a system is capable of being swamped by authentication, then it is free to turn on the TTL check as the verbiage at the end of my last missive suggested. > >> 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? The fact is that they have existed, they may exist in the future, and that their presence may not be known unless somebody is watching TTLs carefully. But it doesn't matter, based on my suggested change. > >> 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. > So now I'm completely lost. Is my suggested verbiage acceptable or not? The rest of this becomes purely academic if it is. Frankly, I'm finding this whole exchange rather frustrating. --Dave
- 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