Subject: Resetting the sequence number in an authenticated BFD session

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 10 Jan 2008 22:42:12 +0200

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

---

From: "Nitin Bahadur" <[email-masked]>
Date: Thu, 10 Jan 2008 13:41:15 -0800

Alexander,

   I agree that keeping the sequence number consistent between line
cards is not practical. We need a way for a system to indicate that it
wants to restart the sequence.

Nitin

________________________________

From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Thursday, January 10, 2008 12:42 PM
To: David Ward; Dave Katz
Cc: Ronen Sommer; BFD WG; Igor Danilovich
Subject: Resetting the sequence number in an authenticated BFD session
Importance: High

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.

I would highly appreciate any feedback from the draft authors and/or
from the WG.

Regards,

                  Sasha

---

From: "Nitin Bahadur" <[email-masked]>
Date: Thu, 10 Jan 2008 14:10:50 -0800

That's not sufficient from a practical point of view. Here's why.

*      run BFD on bundled interfaces (any flavor) centrally

Can't support very low detection times. Only line cards can support tens
of ms.

*      run BFD on all component links independently

This solution does not work for multi-hop bfd sessions. If the outgoing
link for a mhop session is a link-bundle, then you would need to create
a 1 session per component link just to monitor the health of a single
bfd peer. Also, for a mhop session, if there are link bundles on both
the peers, I'm not sure how it would work.

*      run BFD on a master component link

What if the master goes down? The link is still UP. If you now assign
the master to a different line card, you end up with problem of sequence
number out of sync.

I would be interested in knowing the other variants that might help
solve the above issues.

Thanks

Nitin

From: David Ward [mailto:[email-masked]] 
Sent: Thursday, January 10, 2008 1:51 PM
To: Nitin Bahadur
Cc: David Ward; Alexander Vainshtein; Dave Katz; Ronen Sommer; BFD WG;
Igor Danilovich
Subject: Re: Resetting the sequence number in an authenticated BFD
session

Solutions include (and are alluded to in the drafts):

run BFD on bundled interfaces (any flavor) centrally

run BFD on all component links independently

run BFD on a master component link

There are other variants as well.

-DWard

On Jan 10, 2008, at 3:41 PM, Nitin Bahadur wrote:

Alexander,

Nitin

Hi all,

Regards,

                  Sasha

---

From: David Ward <[email-masked]>
Date: Thu, 10 Jan 2008 16:19:41 -0600

Nitin -

inline

On Jan 10, 2008, at 4:10 PM, Nitin Bahadur wrote:

> That’s not sufficient from a practical point of view. Here’s why.
>
> Ø      run BFD on bundled interfaces (any flavor) centrally
> Can’t support very low detection times. Only line cards can support  
> tens of ms.
>
> Ø      run BFD on all component links independently
> This solution does not work for multi-hop bfd sessions. If the  
> outgoing link for a mhop session is a link-bundle, then you would  
> need to create a 1 session per component link just to monitor the  
> health of a single bfd peer. Also, for a mhop session, if there are  
> link bundles on both the peers, I’m not sure how it would work.
>

DW: The picture would be that the component links in an L2 bundle are  
directly adjacent.  In an L2 bundle situation where you want to test  
each link  independently with bidir comms between two routers why  
would it be mhop? MHop session are for those w/o being directly  
adjacent.

> Ø      run BFD on a master component link
> What if the master goes down? The link is still UP. If you now  
> assign the master to a different line card, you end up with problem  
> of sequence number out of sync.
>

DW: Many of them do not require modifications to the protocol to be  
interoperable and would be outside the scope of the BFD specification.

-DWard

> Cc: David Ward; Alexander Vainshtein; Dave Katz; Ronen Sommer; BFD  
> WG; Igor Danilovich
> cards is not practical. We need a way for a system to indicate that  
> it wants to restart the sequence.
>
> Nitin
>
> 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).
>

---

From: David Ward <[email-masked]>
Date: Thu, 10 Jan 2008 16:24:42 -0600

Nitin -

On Jan 10, 2008, at 4:19 PM, David Ward wrote:

>> Can’t support very low detection times. Only line cards can  
>> support tens of ms.
>>
>> health of a single bfd peer. Also, for a mhop session, if there  
>> are link bundles on both the peers, I’m not sure how it would work.
>>
>
>
> DW: The picture would be that the component links in an L2 bundle  
> are directly adjacent.  In an L2 bundle situation where you want to  
> test each link  independently with bidir comms between two routers  
> why would it be mhop? MHop session are for those w/o being directly  
> adjacent.
>
>

DW: Perhaps you meant that two routers running a mhop BFD session  
that traversed a link bundle somewhere inbetween. In this case there  
is nothing you can do as there is nothing you can to to guarantee you  
are going to traverse the same component links of the bundle  
inbetween two other routers. The forwarding choice of how to balance  
those flows over the component links is a local decision that the  
mhop BFD'ing routers cannot bias.

I wasn't sure if you were thinking of that case.

-DWard

>> assign the master to a different line card, you end up with  
>> problem of sequence number out of sync.
>>
>> I would be interested in knowing the other variants that might  
>> help solve the above issues.
>
>
>>    I agree that keeping the sequence number consistent between  
>> line cards is not practical. We need a way for a system to  
>> indicate that it wants to restart the sequence.
>>
>> Nitin
>>
>> 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).
>>

---

From: "Nitin Bahadur" <[email-masked]>
Date: Thu, 10 Jan 2008 15:14:27 -0800

The case I was thinking of was as follows..

       ____________                             ________

      |    Bundle        |                           |   Bundle |    

 A  +---------------------+ B ------ C  ------ D +------------+ E  

      |____________ |

A and E are iBGP peers. iBGP doesn't know/care bout link bundling. The
peers establish a BFD mhop session between them. The links A-B and D-E
are link bundles. One cannot guarantee that the link bundle components
will be on the same line-card. How can one maintain auth semantics if
the line card on A hosting  the BFD session goes down.

 

DW: The picture would be that the component links in an L2 bundle are
directly adjacent.  In an L2 bundle situation where you want to test
each link  independently with bidir comms between two routers why would
it be mhop? MHop session are for those w/o being directly adjacent.

DW: Perhaps you meant that two routers running a mhop BFD session that
traversed a link bundle somewhere inbetween. In this case there is
nothing you can do as there is nothing you can to to guarantee you are
going to traverse the same component links of the bundle inbetween two
other routers. The forwarding choice of how to balance those flows over
the component links is a local decision that the mhop BFD'ing routers
cannot bias.

---

From: David Ward <[email-masked]>
Date: Thu, 10 Jan 2008 17:39:26 -0600

The solution for this is outside the scope of the spec.  Note that  
the problem you describe is not specific to auth at all, it is a  
generic system problem. The problem is the same if you receive any  
BFD notification over any link and you need to disseminate that  
information to all component links. Discrim change, timer change, etc  
they all fit into this category.

You can home the BFD machine on one LC (yes, a form of  
centralization) and fwd bfd packets to it, you can run BFD on all LCs  
homing component links and send notifications between them  
(proprietary solution) - there are many variants of this. It is much,  
much harder to put the solution into forwarding chips themselves but,  
again it is not an unsolvable problem either.

In any event, the meta point is that this problem is not limited to  
authentication seq_id rollover and unfort is not a solution that  
requires specification for interoperability. Towards that end I know  
of multiple interoperable implementations that work over bundles.

-DWard

On Jan 10, 2008, at 5:14 PM, Nitin Bahadur wrote:

> A and E are iBGP peers. iBGP doesn’t know/care bout link bundling.  
> The peers establish a BFD mhop session between them. The links A-B  
> and D-E are link bundles. One cannot guarantee that the link bundle  
> components will be on the same line-card. How can one maintain auth  
> semantics if the line card on A hosting  the BFD session goes down.
>
>
>
> that traversed a link bundle somewhere inbetween. In this case  
> there is nothing you can do as there is nothing you can to to  
> guarantee you are going to traverse the same component links of the  
> bundle inbetween two other routers. The forwarding choice of how to  
> balance those flows over the component links is a local decision  
> that the mhop BFD'ing routers cannot bias.
>
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 11 Jan 2008 12:11:38 +0200

David, Nitin and all,
Please see inline below (blue italics)..Unfortunately it seems that none of the options explicitly proposed by David resolve the issue.
 
Regards,
                 Sasha

From: David Ward [mailto:[email-masked]]
Sent: Thu 1/10/2008 11:51 PM
To: Nitin Bahadur
Cc: David Ward; Alexander Vainshtein; Dave Katz; Ronen Sommer; BFD WG; Igor Danilovich
Subject: Re: Resetting the sequence number in an authenticated BFD session

run BFD on bundled interfaces (any flavor) centrally [Sasha] This rasies the issue of the central component failover (as mentioned in my oriinal message).
 
run BFD on all component links independently [Sasha] IMHO this is not a viable option. E.g., consider a L3 1-hop situation where the bundled interfaces run between one of the routers and a L2 switch, while the L3 adjacency is unaware of bundling. This is easily achieved with LAG. 
 
run BFD on a master component link [Sasha] The failure of the LC that carries the "master componet link" is the original scenario described in my original email, and the issue remains unsloved IMO.

-DWard

	
	Alexander,
	 
	   I agree that keeping the sequence number consistent between line cards is not practical. We need a way for a system to indicate that it wants to restart the sequence.
	 
	Nitin

	 
	Hi all,

	 

	Regards,
	                  Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 11 Jan 2008 12:21:54 +0200

David, Nitin and all,
 
IMHO the problem raised is specific because it represents a combination of situations:

1.	
	Handling of a non-planned event is required

	*	
		From my experience, card failures fail quite often into this category 
	*	
		Since the ecent is non-planned, the BFD machine cannot prepare the peer for this event. Handling of planned events could, e.g., begin with the peer expecting such an event decalring the BFD session administratively down and thus precluding any undesirable action by the peer

2.	
	The event affects the authentication procedure. This means (and my reading of the draft) that regardless of what the BFD machine after the event tries to do, it will not be achieved because the packets it sends shall not be authenticated and hence shall not affect the peer behavior.

The real-time side of the story (namely sequence numbers chagning quite fast) makes any solution based on synchronization between tow incarnations (before and after the event) of the BFD machine very difficult.

Regards,

                 Sasha

From: David Ward [mailto:[email-masked]]
Sent: Fri 1/11/2008 1:39 AM
To: Nitin Bahadur
Cc: David Ward; Alexander Vainshtein; Dave Katz; Ronen Sommer; BFD WG; Igor Danilovich
Subject: Re: Resetting the sequence number in an authenticated BFD session

The solution for this is outside the scope of the spec.  Note that the problem you describe is not specific to auth at all, it is a generic system problem. The problem is the same if you receive any BFD notification over any link and you need to disseminate that information to all component links. Discrim change, timer change, etc they all fit into this category. 

You can home the BFD machine on one LC (yes, a form of centralization) and fwd bfd packets to it, you can run BFD on all LCs homing component links and send notifications between them (proprietary solution) - there are many variants of this. It is much, much harder to put the solution into forwarding chips themselves but, again it is not an unsolvable problem either.

In any event, the meta point is that this problem is not limited to authentication seq_id rollover and unfort is not a solution that requires specification for interoperability. Towards that end I know of multiple interoperable implementations that work over bundles.

-DWard 

	

	       ____________                             ________
	      |    Bundle        |                           |   Bundle |   
	 
	A and E are iBGP peers. iBGP doesn't know/care bout link bundling. The peers establish a BFD mhop session between them. The links A-B and D-E are link bundles. One cannot guarantee that the link bundle components will be on the same line-card. How can one maintain auth semantics if the line card on A hosting  the BFD session goes down.

	*      run BFD on all component links independently
	This solution does not work for multi-hop bfd sessions. If the outgoing link for a mhop session is a link-bundle, then you would need to create a 1 session per component link just to monitor the health of a single bfd peer. Also, for a mhop session, if there are link bundles on both the peers, I'm not sure how it would work.

	DW: The picture would be that the component links in an L2 bundle are directly adjacent.  In an L2 bundle situation where you want to test each link  independently with bidir comms between two routers why would it be mhop? MHop session are for those w/o being directly adjacent.

	DW: Perhaps you meant that two routers running a mhop BFD session that traversed a link bundle somewhere inbetween. In this case there is nothing you can do as there is nothing you can to to guarantee you are going to traverse the same component links of the bundle inbetween two other routers. The forwarding choice of how to balance those flows over the component links is a local decision that the mhop BFD'ing routers cannot bias.

---

From: David Ward <[email-masked]>
Date: Fri, 11 Jan 2008 08:18:51 -0600

Sasha -

I think I already covered your points on centralization and master  
component link. WRT the issue that a L3 device is connected to an L2  
device via a bundled interface and the far L3 device is single  
attached ... BFD is currently an L3 solution. You'd have to run LACP,  
UDLR or BFD at L3 to the L2 device to cover this scenario.

-DWard

On Jan 11, 2008, at 4:11 AM, Alexander Vainshtein wrote:

> David, Nitin and all,
> Please see inline below (blue italics)..Unfortunately it seems that  
> none of the options explicitly proposed by David resolve the issue.
>
> Regards,
>                  Sasha
>
> run BFD on bundled interfaces (any flavor) centrally [Sasha] This  
> rasies the issue of the central component failover (as mentioned in  
> my oriinal message).
>
> run BFD on all component links independently [Sasha] IMHO this is  
> not a viable option. E.g., consider a L3 1-hop situation where the  
> bundled interfaces run between one of the routers and a L2 switch,  
> while the L3 adjacency is unaware of bundling. This is easily  
> achieved with LAG.
>
> run BFD on a master component link [Sasha] The failure of the LC  
> that carries the "master componet link" is the original scenario  
> described in my original email, and the issue remains unsloved IMO.
>

---

From: David Ward <[email-masked]>
Date: Fri, 11 Jan 2008 08:23:19 -0600

Sasha -

> From my experience, card failures fail quite often into this category

This is a generic problem.

>
> Since the ecent is non-planned, the BFD machine cannot prepare the  
> peer for this event. Handling of planned events could, e.g., begin  
> with the peer expecting
> such an event decalring the BFD session administratively down and  
> thus precluding any undesirable action by the peer

This is also a generic problem.

> The event affects the authentication procedure. This means (and my  
> reading of the draft) that regardless of what the BFD machine after  
> the event tries to do, it will not be achieved because the packets  
> it sends shall not be authenticated and hence shall not affect the  
> peer behavior.

Again, this is no different if other "helping" BFD processes didn't  
have any of the session state. Any BFD information given w/ unknown  
session information is ignored. This isn't limited to Auth.

> The real-time side of the story (namely sequence numbers chagning  
> quite fast) makes any solution based on synchronization between tow  
> incarnations (before and after the event) of the BFD machine very  
> difficult.
>
>
>

Difficult but, not impossible. Again, there are multiple  
interoperable implementations that work over enet bundles, MLPP, etc.  
Fortunately none of them change the packets on the wire or protocol  
state machine.

-DWard

> information to all component links. Discrim change, timer change,  
> etc they all fit into this category.
>
> centralization) and fwd bfd packets to it, you can run BFD on all  
> LCs homing component links and send notifications between them  
> (proprietary solution) - there are many variants of this. It is  
> much, much harder to put the solution into forwarding chips  
> themselves but, again it is not an unsolvable problem either.
>
> requires specification for interoperability. Towards that end I  
> know of multiple interoperable implementations that work over bundles.
>
> -DWard
>
>> and D-E are link bundles. One cannot guarantee that the link  
>> bundle components will be on the same line-card. How can one  
>> maintain auth semantics if the line card on A hosting  the BFD  
>> session goes down.
>>
>>
>>
>> are directly adjacent.  In an L2 bundle situation where you want  
>> to test each link  independently with bidir comms between two  
>> routers why would it be mhop? MHop session are for those w/o being  
>> directly adjacent.
>>
>>
>> guarantee you are going to traverse the same component links of  
>> the bundle inbetween two other routers. The forwarding choice of  
>> how to balance those flows over the component links is a local  
>> decision that the mhop BFD'ing routers cannot bias.
>>
>>
>

---

From: "Peter Arberg" <[email-masked]>
Date: Fri, 11 Jan 2008 10:07:30 -0800

Hi David,
 
When you say:
 
---
Difficult but, not impossible. Again, there are multiple interoperable
implementations that work over enet bundles, MLPP, etc. Fortunately none of
them change the packets on the wire or protocol state machine.
---
 
I take it you are refering to BFD over a link-bundle, where the bundle is
considered "1" link, so
just 1 BFD session, so it is a bundle "keepalive" instead of a per link
inside the bundle
monitoring/keepalive.
 
correct ?
 
thanks,
Peter

  _____  

From: David Ward [mailto:[email-masked]] 
Sent: 11. januar 2008 06:23
To: Alexander Vainshtein
Cc: Ronen Sommer; Dave Katz; Igor Danilovich; David Ward; BFD WG
Subject: Re: Resetting the sequence number in an authenticated BFD session

Sasha - 

David, Nitin and all,
 
IMHO the problem raised is specific because it represents a combination of
situations:

1.	

*	

	From my experience, card failures fail quite often into this
category

*	

*	

	Since the ecent is non-planned, the BFD machine cannot prepare the
peer for this event. Handling of planned events could, e.g., begin with the
peer expecting

*	

2.	

	The event affects the authentication procedure. This means (and my
reading of the draft) that regardless of what the BFD machine after the
event tries to do, it will not be achieved because the packets it sends
shall not be authenticated and hence shall not affect the peer behavior.

Again, this is no different if other "helping" BFD processes didn't have any
of the session state. Any BFD information given w/ unknown session
information is ignored. This isn't limited to Auth.

The real-time side of the story (namely sequence numbers chagning quite
fast) makes any solution based on synchronization between tow incarnations
(before and after the event) of the BFD machine very difficult.

Difficult but, not impossible. Again, there are multiple interoperable
implementations that work over enet bundles, MLPP, etc. Fortunately none of
them change the packets on the wire or protocol state machine.

-DWard

Regards,

                 Sasha

  _____  

From: David Ward [mailto:[email-masked]]
Sent: Fri 1/11/2008 1:39 AM
To: Nitin Bahadur
Cc: David Ward; Alexander Vainshtein; Dave Katz; Ronen Sommer; BFD WG; Igor
Danilovich
Subject: Re: Resetting the sequence number in an authenticated BFD session

The solution for this is outside the scope of the spec.  Note that the
problem you describe is not specific to auth at all, it is a generic system
problem. The problem is the same if you receive any BFD notification over
any link and you need to disseminate that information to all component
links. Discrim change, timer change, etc they all fit into this category. 

You can home the BFD machine on one LC (yes, a form of centralization) and
fwd bfd packets to it, you can run BFD on all LCs homing component links and
send notifications between them (proprietary solution) - there are many
variants of this. It is much, much harder to put the solution into
forwarding chips themselves but, again it is not an unsolvable problem
either.

In any event, the meta point is that this problem is not limited to
authentication seq_id rollover and unfort is not a solution that requires
specification for interoperability. Towards that end I know of multiple
interoperable implementations that work over bundles.

-DWard 

 
 
       ____________                             ________
      |    Bundle        |                           |   Bundle |   
 
A and E are iBGP peers. iBGP doesn't know/care bout link bundling. The peers
establish a BFD mhop session between them. The links A-B and D-E are link
bundles. One cannot guarantee that the link bundle components will be on the
same line-card. How can one maintain auth semantics if the line card on A
hosting  the BFD session goes down.

  _____  

*      run BFD on all component links independently
This solution does not work for multi-hop bfd sessions. If the outgoing link
for a mhop session is a link-bundle, then you would need to create a 1
session per component link just to monitor the health of a single bfd peer.
Also, for a mhop session, if there are link bundles on both the peers, I'm
not sure how it would work.

DW: The picture would be that the component links in an L2 bundle are
directly adjacent.  In an L2 bundle situation where you want to test each
link  independently with bidir comms between two routers why would it be
mhop? MHop session are for those w/o being directly adjacent.

DW: Perhaps you meant that two routers running a mhop BFD session that
traversed a link bundle somewhere inbetween. In this case there is nothing
you can do as there is nothing you can to to guarantee you are going to
traverse the same component links of the bundle inbetween two other routers.
The forwarding choice of how to balance those flows over the component links
is a local decision that the mhop BFD'ing routers cannot bias.

---

From: Dave Katz <[email-masked]>
Date: Fri, 11 Jan 2008 12:09:28 -0700

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 13 Jan 2008 07:24:26 +0200

David,
I have probably poorly presented the case of an intermediate L2 device. 
What I have in mind is the following combination:

1.	
	A single L3 adjacency monitored by BFD that has been established across an intermediate L2 device
2.	
	Different number of L2-bundled links between each of the L3 peers and the intermediate L2 device.

I do not see how your proposed solutions would help to resolve the problem:

1.	Not sure why UDLR is relevant to this scenario, will look-up the appropriate RFC first
2.	LACP operates per L2-bundled link. It would help to detect a failure of such a link, but, IMHO, no more than that
3.	L3 BFD between a L3 and L2 device would not affect the state of the L3 BFD session between the L3 peers.

Regards,

                Sasha

From: David Ward [mailto:[email-masked]]
Sent: Fri 1/11/2008 4:18 PM
To: Alexander Vainshtein
Cc: David Ward; Nitin Bahadur; Dave Katz; Ronen Sommer; BFD WG; Igor Danilovich
Subject: Re: Resetting the sequence number in an authenticated BFD session

Sasha - 

I think I already covered your points on centralization and master component link. WRT the issue that a L3 device is connected to an L2 device via a bundled interface and the far L3 device is single attached ... BFD is currently an L3 solution. You'd have to run LACP, UDLR or BFD at L3 to the L2 device to cover this scenario.

-DWard

	David, Nitin and all,
	 
	Regards,
	                 Sasha

	 

	-DWard

		
		Alexander,

		Nitin

		 
		Hi all,

		 

		Regards,
		                  Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 13 Jan 2008 07:44:05 +0200

Dave,
Lots of thanks for a detailed response. Please see inline below (blue italics).
 
Regards,
                   Sasha

From: Dave Katz [mailto:[email-masked]]
Sent: Fri 1/11/2008 9:09 PM
To: Alexander Vainshtein
Cc: David Ward; BFD WG; Igor Danilovich; Ronen Sommer
Subject: Re: Resetting the sequence number in an authenticated BFD session

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.
[Sasha] I am not a security expert either, but I understand that allowing arbitrary resetting of the sequence number would be a serious security issue. This was the main reason behind the statement (in the original message) that "I do not see a simple solution for the problem".

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. [Sasha] I agree that this is at least very complicated and probably impossible.

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. [Sasha] This would be nice. Not sure, though, how strong the people feel about it. One piece of info that could help is the understanding of the actual usage of the BFD authentication in the real-life deployments. 

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

	Hi all,

	 

	Regards,
	                  Sasha

---

From: David Ward <[email-masked]>
Date: Sun, 13 Jan 2008 10:17:45 -0600

Sasha -

What you need to realize is that you have a layering problem to solve  
and one could solve it multiple ways today.

One solution:

Run LACP or UDLD between the router and the switch that has the  
bundled interface, monitor component links and the state of the  
bundle. Independently run a BFD session between the two routers.

Second solution:

Run BFD between the two routers and on the router with the bundled  
interface, have a distributed state machine on all cards that home  
component links (this is an implementation specific design).

Third solution:

Run BFD between the router and the switch with the bundled interface  
via IP and monitor all component links. Run a second BFD between the  
two routers and use either a centralized BFD, a master link (that can  
receive all BFD packets through internal forwarding) or replicate  
state via #2.

All three of the above solve the problem (there are obvious variants)  
and are deployed today.

-DWard

On Jan 12, 2008, at 11:24 PM, Alexander Vainshtein wrote:

> Not sure why UDLR is relevant to this scenario, will look-up the  
> appropriate RFC first
> LACP operates per L2-bundled link. It would help to detect a  
> failure of such a link, but, IMHO, no more than that

> L3 BFD between a L3 and L2 device would not affect the state of the  
> L3 BFD session between the L3 peers.
>

> component link. WRT the issue that a L3 device is connected to an  
> L2 device via a bundled interface and the far L3 device is single  
> attached ... BFD is currently an L3 solution. You'd have to run  
> LACP, UDLR or BFD at L3 to the L2 device to cover this scenario.
>
> -DWard
>
>
>> Please see inline below (blue italics)..Unfortunately it seems  
>> that none of the options explicitly proposed by David resolve the  
>> issue.
>>
>> Regards,
>>                  Sasha
>>
>> rasies the issue of the central component failover (as mentioned  
>> in my oriinal message).
>>
>>> 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).
>>>

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 13 Jan 2008 19:17:06 +0200

David and all,
Lots of thanks for a prompt and detailed response.
 
My gut feeling is that replicated state (or something like that) is part
of all the approaches you've outlined, but I must carefully  re-check
this feeling.
 
Regards,
                Sasha

From: David Ward [mailto:[email-masked]] 
Sent: Sunday, January 13, 2008 6:18 PM
To: Alexander Vainshtein
Cc: David Ward; Nitin Bahadur; Dave Katz; Ronen Sommer; BFD WG; Igor
Danilovich
Subject: Re: Resetting the sequence number in an authenticated BFD
session

Sasha - 

One solution:

Run LACP or UDLD between the router and the switch that has the bundled
interface, monitor component links and the state of the bundle.
Independently run a BFD session between the two routers. 

Second solution:

Third solution:

Run BFD between the router and the switch with the bundled interface via
IP and monitor all component links. Run a second BFD between the two
routers and use either a centralized BFD, a master link (that can
receive all BFD packets through internal forwarding) or replicate state
via #2.

-DWard

	David,
	I have probably poorly presented the case of an intermediate L2
device. 
	What I have in mind is the following combination:

	1.	
		A single L3 adjacency monitored by BFD that has been
established across an intermediate L2 device
	2.	
		Different number of L2-bundled links between each of the
L3 peers and the intermediate L2 device.

	I do not see how your proposed solutions would help to resolve
the problem:

	1.	Not sure why UDLR is relevant to this scenario, will
look-up the appropriate RFC first 
	2.	LACP operates per L2-bundled link. It would help to
detect a failure of such a link, but, IMHO, no more than that

	3.	L3 BFD between a L3 and L2 device would not affect the
state of the L3 BFD session between the L3 peers.

	Regards,

	                Sasha

	From: David Ward [mailto:[email-masked]]
	Sent: Fri 1/11/2008 4:18 PM
	To: Alexander Vainshtein
	Cc: David Ward; Nitin Bahadur; Dave Katz; Ronen Sommer; BFD WG;
Igor Danilovich
	Subject: Re: Resetting the sequence number in an authenticated
BFD session

	Sasha - 

	I think I already covered your points on centralization and
master component link. WRT the issue that a L3 device is connected to an
L2 device via a bundled interface and the far L3 device is single
attached ... BFD is currently an L3 solution. You'd have to run LACP,
UDLR or BFD at L3 to the L2 device to cover this scenario.

	-DWard

		David, Nitin and all,
		Please see inline below (blue italics)..Unfortunately it
seems that none of the options explicitly proposed by David resolve the
issue.
		 
		Regards,
		                 Sasha

		From: David Ward [mailto:[email-masked]]
		Sent: Thu 1/10/2008 11:51 PM
		To: Nitin Bahadur
		Cc: David Ward; Alexander Vainshtein; Dave Katz; Ronen
Sommer; BFD WG; Igor Danilovich
		Subject: Re: Resetting the sequence number in an
authenticated BFD session

		run BFD on bundled interfaces (any flavor) centrally
[Sasha] This rasies the issue of the central component failover (as
mentioned in my oriinal message).
		 
		run BFD on all component links independently [Sasha]
IMHO this is not a viable option. E.g., consider a L3 1-hop situation
where the bundled interfaces run between one of the routers and a L2
switch, while the L3 adjacency is unaware of bundling. This is easily
achieved with LAG. 
		 
		run BFD on a master component link [Sasha] The failure
of the LC that carries the "master componet link" is the original
scenario described in my original email, and the issue remains unsloved
IMO.

		-DWard

			
			Alexander,
			 
			   I agree that keeping the sequence number
consistent between line cards is not practical. We need a way for a
system to indicate that it wants to restart the sequence.
			 
			Nitin

			From: Alexander Vainshtein
[mailto:[email-masked]] 
			Sent: Thursday, January 10, 2008 12:42 PM
			To: David Ward; Dave Katz
			Cc: Ronen Sommer; BFD WG; Igor Danilovich
			Subject: Resetting the sequence number in an
authenticated BFD session
			Importance: High
			 
			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