Re: ttl and authentication

[Dave Katz <[e-mail]>]

On Feb 23, 2005, at 12:15 PM, Pekka Savola 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?

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

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

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