Subject: I-D ACTION:draft-ietf-bfd-multihop-01.txt

From: [email-masked]
Date: Tue, 22 Feb 2005 15:36:50 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF.

	Title		: BFD for Multihop Paths
	Author(s)	: D. Katz, D. Ward
	Filename	: draft-ietf-bfd-multihop-01.txt
	Pages		: 6
	Date		: 2005-2-22
	
This document describes the use of the Bidirectional Forwarding
   Detection protocol (BFD) over multihop paths, including
   unidirectional links.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-bfd-multihop-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-bfd-multihop-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-bfd-multihop-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 23 Feb 2005 21:15:32 +0200 (EET)

Hi,

> 	Filename	: draft-ietf-bfd-multihop-01.txt

There was one particularly unnerving change in -01:

5. TTL/Hop Count Issues

    If BFD authentication is not in use, all BFD Control packets for
    sessions operating according to this specification MUST be sent with
    a TTL or Hop Count value of 255.  All received BFD Control packets
    that are demultiplexed to sessions operating according to this
    specification MUST be discarded if the received TTL or Hop Count is
    not equal to 255.  A discussion of this mechanism can be found in
    [GTSM].

    If BFD authentication is in use, any value of TTL/Hop Count MAY be
    used in transmitted packets, and received packets MUST NOT be
    discarded based on the received TTL/Hop Count.

.. this is _not good_, depending on the definition of "BFD 
authentication is in use".

If I interpret this correctly, the routers can not simply drop BFD 
session which are sent to the router with a bogus TTL and bogus 
authentication (e.g., wrong password) based on the TTL check?

For single hop scenarios, I don't see the reason to omit checking for 
TTL or to send any other TTL than 255.  Please elaborate or put it 
back in ASAP :).

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

---

From: Dave Katz <[email-masked]>
Date: Wed, 23 Feb 2005 22:34:59 -0700

> authentication (e.g., wrong password) based on the TTL check?

I should have been a bit more specific here.  The intent was that an 
appropriately authenticated packet needn't be "authenticated" based on 
the TTL.  I don't quite understand your concern;  obviously if the 
packet fails authentication, it must be discarded, so it's not as 
though the MUST NOT language forces you to accept the packet.

Whether this change is gratuitous or not is a separate issue;  
regardless, I don't see it as dangerous.  I suppose "not good" could be 
equivalent to "gratuitous" but this doesn't rate an "ASAP."

> TTL or to send any other TTL than 255.  Please elaborate or put it 

The reason I made this change is that the TTL hack isn't necessary when 
packets are authenticated, and I've never been thrilled with the TTL 
hack, and I'm concerned that the idea of "single hop" is somewhat 
fluid, so I wanted to make sure that BFD could work even if "single 
hop" and "TTL isn't decremented" aren't congruent.  There is no 
specific case that I can think of that would make this fail (though 
there have been ideas floated over the years about reaching into 
encapsulated packets and decrementing the TTL) but it left me somewhat 
queasy.

This is an incompatible change relative to the last draft, which also 
leaves me a bit queasy, but less queasy than the not making the change.

If there are strong feelings that this shouldn't change, I am happy to 
remove it.  I will make the language more specific in any case.

--Dave

---

From: Pekka Savola <[email-masked]>
Date: Thu, 24 Feb 2005 09:00:14 +0200 (EET)

On Wed, 23 Feb 2005, Dave Katz wrote:
>> If I interpret this correctly, the routers can not simply drop BFD session 
>> which are sent to the router with a bogus TTL and bogus authentication 
>> (e.g., wrong password) based on the TTL check?
>
> appropriately authenticated packet needn't be "authenticated" based on the 
> TTL.  I don't quite understand your concern;  obviously if the packet fails 
> authentication, it must be discarded, so it's not as though the MUST NOT 
> language forces you to accept the packet.

The concern is which is done first: TTL check or authentication check.

Compare the situation to BGP with MD5.  Folks can easily DoS a router 
by sending bogus MD5-signed BGP packets to spend all the CPU's 
computational resources.  Using TTL=255 check _first_ prevents this 
particular attack vector, except from the on-link neighbors.

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.

---

From: Dave Katz <[email-masked]>
Date: Thu, 24 Feb 2005 00:35:37 -0700

> opens a resource exhaustion attack vector which could be easily 

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.

--Dave

---

From: Pekka Savola <[email-masked]>
Date: Thu, 24 Feb 2005 09:39:33 +0200 (EET)

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.

---

From: Dave Katz <[email-masked]>
Date: Thu, 24 Feb 2005 01:54:44 -0700

> strongly prefer to put it back in.

Let's put it a different way.  On first principles, if you are only 
willing to accept cryptographically authenticated packets from good 
guys, then cryptographic authentication has absolutely no value and you 
shouldn't use it at all (in which case you will have the TTL check.)

In general, there *must* be a spectrum of methods to protect against 
DoS attacks when cryptographic authentication is used (in any 
protocol), and these are likely to be adaptive and somewhat complex.  
BFD is *not* the only protocol with this issue, and given the direction 
things are going, there are only going to be more.

The metaproblem here is that specifications and operations are 
distinct.  When the spec says that you have to accept such packets, it 
is stated as such to provide a baseline of interoperability.  At some 
level, operationally, authentication is about consciously avoiding 
interoperation.  For example, in this case you could put a filter in 
place (outside of BFD) which discards all BFD packets received on the 
interface with TTL != 255.  This is is entirely equivalent to dropping 
it in the implementation (and is probably preferable if you're worried 
about DoS attacks, particularly if you filter in hardware.)  So is this 
somehow in violation of the spec as currently written?  Similarly, if 
an implementation provides a knob that provides this behavior within 
BFD, is that implementation broken?  I think we would agree that it is 
not.

The role of the spec has to be to provide as wide a range of 
interoperability as possible.  The MUST/MAY/SHOULD verbiage doesn't 
really give us the subtle gradations of meaning that are needed.  What 
I really want to say here is that an implementation has to be capable 
of accepting such packets, not that it has to under all circumstances 
and configurations.  I'm not sure how to say that.  I'd be happy to 
entertain suggestions.

Anyone who is familiar with my implementations knows that I view 
protocol specs liberally, so long as the box will interoperate fully 
with everybody else's.  In this particular case I wouldn't hesitate to 
add a knob to provide the behavior you desire, and would do so with a 
clear conscience.  I've always felt that the art of implementation is 
knowing what you can safely get away with.  But that's just me.

--Dave