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