Re: Resetting the sequence number in an authenticated BFD session

[Dave Katz <[e-mail]>]

I am not a security expert, nor do I play one on TV, but the whole  
point of the sequence number scheme is to protect against replay  
attacks, and any scheme that allows for the arbitrary resetting of  
the sequence number space opens up a giant hole.

If the authentication section were to carry an additional field with  
"next sequence number expected" then the sender who had lost track of  
the sequence space could recover without the receiver being  
vulnerable to a replay attack (the details of making this work  
properly with multiple packets in flight seems possible with  
sufficient signaling but is beyond my ability to extemporize in this  
email.)  Note that I believe it is impossible to avoid session  
flapping in the case where the round-trip time between systems is  
greater than the detection time of the session, so it's not clear  
that any such solution is possible in the general case.

If people feel strongly enough about this issue and cannot solve it  
any other way, I would suggest an extension to the base spec using a  
new authentication type field, as this is going to take some time and  
careful thought, and could be done without affecting the base spec.


It's worth noting, however, that this is mostly just a particular  
instance of the more general problem of recovering from lost BFD  
state.  Another interesting example is trying to handle various  
graceful-restart-like scenarios, including processor failover.

The generic solution to these problems is to add a layer between the  
BFD state machine and the applications that does some intelligent  
hysteresis around BFD state changes and hides the flap from the  
applications.  This can easily be done without impacting the  
detection time of the session for cases other than the sequence  
number issue.  The long-overdue reissue of the generic spec will talk  
about this more fully, Real Soon Now.

It's a little bit touchier to pull off with the sequence number stuff  
because it's hard to reestablish session state in less than a  
detection time.  One straightforward approach would be to simply wait  
for the old session to time out (since you'll be receiving packets  
that don't authenticate.)  This complicates the heuristics of the  
flap suppression a bit, but not terribly, and it also means that  
signaling session failure to applications when the far end key stops  
working will take longer than a detection time.  This doesn't sound  
like a bad tradeoff to me, since it's a deep-end case and wouldn't  
impact the detection time for generic failures.  The security  
implications are exactly what they are today for session  
establishment (or slightly better, since any bad-guy third party  
would have to block the legitimate session as well as replaying the  
establishment of a new one.)

Another scheme could involve establishing a new session and  
abandoning the old one, which could be done in less than a detection  
time, but this opens up a giant denial-of-service hole.

--Dave


On Jan 10, 2008, at 1:42 PM, Alexander Vainshtein wrote:

> Hi all,
> I have a question related to the expected behavior of sequence  
> numbers in an aythenticated (MD5 or SHA1) BFD session.
>
> The corresdponding sections of draft-ietf-bfd-base-06 state that,  
> once the packet has been authenticated by the receiver, its  
> sequence number MUST be checked; if its value is out of range  
> defined by the last received sequence number and the Detect  
> Multiplexor, the packet MUST be discarded.
>
> This may result in the a BFD session going down in the situation  
> when the transceiver "loses" the information about its last  
> transmitted sequence number. A suitable use case is a multilink  
> interface (LAG, ML-PPP, etc.) with the links residing in different  
> line cards, and e BFD implemented in one of these cards: if this  
> card fails, the BFD would could be re-started in one of the  
> remaining cards. Such a restart would not affect the local session  
> because the BFD machine would be restarted with bfd.AuthSeqKnown =  
> 0, but keeping bfd.XmitAuthSeq consistent between different line  
> cards seems problematic. (Implemeting BFD in some common card would  
> resolve the situation with the multilink interfaces but would raise  
> similar issues when the common card fails).
>
> Note that this problem would not occur for a non-authenticated BFD  
> session.
>
> IMHO this problem is real, and I do not see a simple solution for it.
> I would highly appreciate any feedback from the draft authors and/ 
> or from the WG.
>
> Regards,
>                   Sasha
>