Re: ttl and authentication

[Dave Katz <[e-mail]>]

On Feb 24, 2005, at 12:39 AM, Pekka Savola wrote:

> 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.
>

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