Re: ttl and authentication

Pekka Savola <pekkas@netcore.fi> Thu, 24 February 2005 07:42 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 CAA12033; Thu, 24 Feb 2005 02:42:03 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4E0D-0005Rz-JI; Thu, 24 Feb 2005 03:05:42 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4DbA-0004oG-EZ; Thu, 24 Feb 2005 02:39:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Db7-0004ni-OX for rtg-bfd@megatron.ietf.org; Thu, 24 Feb 2005 02:39:46 -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 CAA11793 for <rtg-bfd@ietf.org>; Thu, 24 Feb 2005 02:39:44 -0500 (EST)
Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Dxx-0005Oa-N7 for rtg-bfd@ietf.org; Thu, 24 Feb 2005 03:03:23 -0500
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j1O7dX424348; Thu, 24 Feb 2005 09:39:33 +0200
Date: Thu, 24 Feb 2005 09:39:33 +0200
From: Pekka Savola <pekkas@netcore.fi>
To: Dave Katz <dkatz@juniper.net>
In-Reply-To: <35ed279cf9e5b6c559f3d843e7c8d7c3@juniper.net>
Message-ID: <Pine.LNX.4.61.0502240936490.24247@netcore.fi>
References: <200502222036.PAA16786@ietf.org> <Pine.LNX.4.61.0502232111590.6499@netcore.fi> <eb091c568763bfdd10f3c04ae3c9677c@juniper.net> <Pine.LNX.4.61.0502240855100.22843@netcore.fi> <35ed279cf9e5b6c559f3d843e7c8d7c3@juniper.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: rtg-bfd@ietf.org
Subject: Re: ttl and authentication
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: 9466e0365fc95844abaf7c3f15a05c7d

On Thu, 24 Feb 2005, Dave Katz wrote:
>> The same argument seems to apply here.  Speaking as an operator who's using 
>> BFD, I will not be happy if the TTL is not checked first as this opens a 
>> resource exhaustion attack vector which could be easily prevented.
>
> I guess I would counter that if the TTL check is the only thing protecting 
> your infrastructure, then you have bigger problems.  Filtering at the edge of 
> your network has got to be the first line of defense.  Certainly there have 
> got to be similar opportunities to hose things with other protocols for which 
> a TTL check will not help.

That is correct, and in fact in our case, we do have filtering at the 
edge.

However, it is not clear which packets routers implementing BFD will 
demultiplex.  Are the BFD ports open to everyone -- i.e., are you 
requiring that all packets addressed to the any of the routers' 
addressed must be dropped at the borders (that's rather unreasonable 
approach IMHO)?  What if you want to run BFD with eBGP and you cannot 
be protected with border filtering?

All in all, if there is no strong reason to remove the TTL check, I'd 
strongly prefer to put it back in.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings