Subject: Re: Monitoring BFD sessions

From: Jeffrey Haas <[email-masked]>
Date: Sun, 4 Nov 2012 11:00:43 -0500

Havard,

On Tue, Oct 30, 2012 at 10:31:01AM +0100, Havard Eidnes wrote:
> I'm maintaining a small software package we use to monitor
> certain aspects of our network, and among them I'm monitoring BFD
> session states, using a couple of vendors' interim versions of
> the BFD MIB (implanted in their own enterprises tree for the time
> being).
> 
> With one of the vendors I'm observing strange behaviour, in that
> almost every time a BFD session goes through an operational
> down->up state transition (after first going through an up->down
> state transition), the implementation chooses a new BFD
> discriminator for the session.

This behavior is likely desirable in the grand scheme of things.  In
particular, it helps prevent replay attacks against the protocol.

> Furthermore, it looks as if the vendor is using the value of the
> local discriminator when forming the bfdSessIndex value in the
> MIB.

This is probably the problematic thing for you.  The MIB session index
ideally should be a management facing entity and thus have a level of
stability imposed by configuration.  Nothing prohibits it from changing in
the way you're noticing, but it's something I'd press my vendor to fix. 

> So my questions here are twofold:
> 
> 1) Is there a problem with the specifications as written that
>    allows an implementor to (in my opinion) totally de-value the
>    usefulness of the bfdSessTable?

I'd argue the table is fine.  Your vendor should not bind the session index
to the local discriminator.

> 2) Is the implementor in question defending unreasonable
>    behaviour which instead belongs in the "implementation bug"
>    category?

Unfortunately, it's in the "compliant, but annoying" category.

-- Jeff
(Who realizes the vendor in question may be his employer.  If so, please
feel free to involve me in applying the hammer of clue to the problem report.)

---

From: Marc Binderberger <[email-masked]>
Date: Mon, 5 Nov 2012 12:32:35 +0100

Hello Havard, Jeff et al.

> particular, it helps prevent replay attacks against the protocol.

Let me guess: BFD is requested by OSPF or ISIS?

At least one vendor I know requests the BFD session after OSPF/ISIS has discovered a neighbor with the Hello mechanism. The consequence of BFD going down, which is treated like a Hello failure, is that the discovered neighbor information is - strictly speaking - not valid anymore. The BFD session is deleted. Once OSPF/ISIS re-detect the neighbor a _new_ BFD session is started. Which uses a new Discriminator.

As Jeff said, "in the grand scheme of things" this makes sense, even when it looks odd from the BFD level.

Regards, Marc

--
Marc Binderberger           <[email-masked]>

---

From: Binny Jeshan <[email-masked]>
Date: Mon, 5 Nov 2012 17:21:18 +0530

Hello,

I think changing discriminator is fine, if i go as per section 6.3 of RFC
5880.. What do you think of the below lines Havard / Jeff?

" Note that it is permissible for a system to change its discriminator

   during a session without affecting the session state, since only that
   system uses its discriminator for demultiplexing purposes (by having
   the other system reflect it back).  The implications on an
   implementation for changing the discriminator value is outside the
   scope of this specification."

Ofcourse if there are any implications then i'd think that has to be
dealt with. Example is that if the receive processing is affected so
as to cause  a session going down. or may be it could be some attacker
sending BFD packets. This need to be fixed at the receiver end. But if
i'd there to be implementing BFD, i'd inititate a poll sequence to
finish the job clean and make the remote understand the parameter
change better.

"      If the Your Discriminator field is nonzero, it MUST be used to

      select the session with which this BFD packet is associated.  If
      no session is found, the packet MUST be discarded“

What do you think?

Regards,

Binny Jeshan

On 5 November 2012 17:02, Marc Binderberger <[email-masked]> wrote:

> At least one vendor I know requests the BFD session after OSPF/ISIS has
> discovered a neighbor with the Hello mechanism. The consequence of BFD
> going down, which is treated like a Hello failure, is that the discovered
> neighbor information is - strictly speaking - not valid anymore. The BFD
> session is deleted. Once OSPF/ISIS re-detect the neighbor a _new_ BFD
> session is started. Which uses a new Discriminator.
>
>

---

From: Marc Binderberger <[email-masked]>
Date: Mon, 5 Nov 2012 14:37:22 +0100

Hello Binny,

> But if i'd there to be implementing BFD, i'd inititate a poll sequence to finish the job clean and make the remote understand the parameter change better. 

point is there is nothing to understand for the remote system "R2" when "R1" is changing it's local discriminator. For R2 this is just a number to be used for the your_discr field.

Any attempt to help "R2" to "understand" is just weakening a clean & simple statement: that R2 has no business in understanding the discriminator of R1.

And the comment about the "implication" simply points out the fact that you are not automatically covered yourself by the RFC when you change your discriminator. In other words: you must know what you do :-)

Regards, Marc

P.S.: of course you can send P/F, should not cause any harm either.

On 2012-11-05, at 12:51 , Binny Jeshan wrote:

> Hello,
> 
> I think changing discriminator is fine, if i go as per section 6.3 of RFC 5880.. What do you think of the below lines Havard / Jeff? 
> 
> Ofcourse if there are any implications then i'd think that has to be dealt with. Example is that if the receive processing is affected so as to cause  a session going down. or may be it could be some attacker sending BFD packets. This need to be fixed at the receiver end. But if i'd there to be implementing BFD, i'd inititate a poll sequence to finish the job clean and make the remote understand the parameter change better. 
>

---

From: Havard Eidnes <[email-masked]>
Date: Mon, 05 Nov 2012 15:12:09 +0100 (CET)

> particular, it helps prevent replay attacks against the protocol.

OK, I understand there may be good reasons to do this.

> the way you're noticing, but it's something I'd press my vendor to fix. 

I agree -- this would probably be the best thing.  The current
text for the bfdSessIndex is:

    bfdSessIndex OBJECT-TYPE
        SYNTAX     BfdSessIndexTC
        MAX-ACCESS not-accessible
        STATUS     current
        DESCRIPTION
            "This object contains an index used to represent a
             unique BFD session on this device."
        ::= { bfdSessEntry 1 }

Now...  As Marc Binderber guesses, the BFD sessions are in my
case configured as part of the IS-IS configuration.  And as he
says, the device acts as if the BFD session is deleted (I beleive
this is also evident via the CLI, it will then not be there at
all) when the BFD adjacency is lost and subsequently also the
IS-IS adjacency is lost.

So then the question comes up: what is the administrative
lifetime of a BFD session which is configured in this way, and is
the administrator in control of it?  Or can one say that since
something appears to delete the session (the IS-IS process?),
strictly speaking, a new session is created when the neighborship
is re-established, so since this is a different session than the
one who existed earlier, it makes sense to not use the same
bfdSessIndex value to refer to this different session?

That would be ... most annoying, and leaves me exactly where I
started, with no straight-forward way to automatically dig out
the longer-term state changes for the BFD neighborship between
these two neighboring routers using the BFD MIB.  The only way
would be to construct my own "bfd session index", possibly
consisting of "interface, ip-address-type, dest-ip-addr" (or
possibly more, to support multiple BFD sessions between two
neighboring routers).  However, to me this smells of bad MIB
design -- if those are the values an administrator have to build
an index on, why are they not already index values in the BFD
session table?

Is all this the way it should be?

Is there some text which needs to go in somewhere to discourage
this behaviour?

Regards,

- Håvard

---

From: Binny Jeshan <[email-masked]>
Date: Mon, 5 Nov 2012 23:31:20 +0530

Hello Mark,

What i meant is this - If R1 changes its Local discriminator and sends new
packets, R1 should be still able to receive packets from R2 which sends
packets using old "Your discriminator" of R1, which R2 learnt earlier
before the discriminator change. The receive processing of R1 should be in
a position to remember its old discriminator somewhere to demultiplex the
packet to its correct session.

Thats where I'd prefer to do a Poll Sequence to do any such parameter
changes in packet, be it be a Authentication change or a Discriminator
change. Because that would ensure the session state undisturbed.

Regards,
Binny.

On 5 November 2012 19:07, Marc Binderberger <[email-masked]> wrote:

> Hello Binny,
>
> > But if i'd there to be implementing BFD, i'd inititate a poll sequence
> to finish the job clean and make the remote understand the parameter change
> better.
>
> point is there is nothing to understand for the remote system "R2" when
> "R1" is changing it's local discriminator. For R2 this is just a number to
> be used for the your_discr field.
>
> Any attempt to help "R2" to "understand" is just weakening a clean &
> simple statement: that R2 has no business in understanding the
> discriminator of R1.
>
> And the comment about the "implication" simply points out the fact that
> you are not automatically covered yourself by the RFC when you change your
> discriminator. In other words: you must know what you do :-)
>
>
> Regards, Marc
>
> > I think changing discriminator is fine, if i go as per section 6.3 of
> RFC 5880.. What do you think of the below lines Havard / Jeff?
> >
> dealt with. Example is that if the receive processing is affected so as to
> cause  a session going down. or may be it could be some attacker sending
> BFD packets. This need to be fixed at the receiver end. But if i'd there to
> be implementing BFD, i'd inititate a poll sequence to finish the job clean
> and make the remote understand the parameter change better.
> >

---

From: Dave Katz <[email-masked]>
Date: Mon, 5 Nov 2012 11:24:48 -0700

Conceptually, the IGP is creating and destroying BFD sessions as the adjacencies come and go.  There is no inherent relationship between the "old" and the "new" session after a flap.  Having said that, implementations are free to carry the state (in particular the discriminator value) across flaps.  The implementation I wrote did this, though I can't comment on the current state of our code.  Fundamentally, a BFD session is an ephemeral thing.

Using the discriminator value as the session ID seems inappropriate to me since it is, in theory at least, unstable even during a running session.  This doesn't really address your problem, of course, since the discriminator is likely stable during the session, but the two sessions aren't correlated.

If you want to associate the old session with the new session in the context of your management application, I think the only reasonable way is to extract the address/interface information, as that is the only thing guaranteed to be the same under a new session.  This is going to be more robust in other situations as well (protocol restarts, reboots, etc.)

--Dave

---

From: Dave Katz <[email-masked]>
Date: Mon, 5 Nov 2012 11:45:16 -0700

As has been noted, you're free to do a poll sequence exchange at any time.  It's required on a discriminator change for Demand mode:

   If Demand mode is active on either or both systems, a Poll Sequence
   MUST be initiated whenever the contents of the next BFD Control
   packet to be sent would be different than the contents of the
   previous packet, with the exception of the Poll (P) and Final (F)
   bits.  This ensures that parameter changes are transmitted to the
   remote system and that the remote system acknowledges these changes.

Note, however, that the impetus of having a changeable discriminator value was to allow for a certain level of amnesia in the BFD process;  the discriminator is most likely changing because the BFD process has moved within the system and the discriminator was forgotten, so in that case it couldn't receive packets with the old value since it wouldn't recognize it.  (At least I think this was the reason the language was put into the spec in the first place.)

In Async mode, the session stability will only be at risk if the far end continues to send packets with the old discriminator for the entire detection interval.  This in turn can happen only if all outgoing packets from the near end with the new discriminator are lost on the way (in which case the session *should* fail).  For that matter, a poll sequence won't help here either, since packets are just getting dropped either way.

A poll sequence won't typically speed things up, since everybody should send an event-driven packet upon the change of discriminator anyhow:

   A BFD Control packet SHOULD be transmitted during the interval
   between periodic Control packet transmissions when the contents of
   that packet would differ from that in the previously transmitted
   packet (other than the Poll and Final bits) in order to more rapidly
   communicate a change in state.

Also, for what it's worth, the reason that a poll sequence is required on parameter changes is to ensure that the session doesn't fail because of a change in the detection time. The handshake is required to ensure that both ends are on the same page before packet transmission slows or timers are sped up.  This isn't necessary for a discriminator change in async mode.

So I guess I don't see the value in sending a poll sequence at this point (except perhaps in Demand mode) but it doesn't hurt anything.

--Dave

On Nov 5, 2012, at 11:01 AM, Binny Jeshan <[email-masked]> wrote:

> Hello Mark,
> 
> What i meant is this - If R1 changes its Local discriminator and sends new packets, R1 should be still able to receive packets from R2 which sends packets using old "Your discriminator" of R1, which R2 learnt earlier before the discriminator change. The receive processing of R1 should be in a position to remember its old discriminator somewhere to demultiplex the packet to its correct session. 
> 
> Thats where I'd prefer to do a Poll Sequence to do any such parameter changes in packet, be it be a Authentication change or a Discriminator change. Because that would ensure the session state undisturbed.
> 
> Regards,
> Binny.
>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 5 Nov 2012 14:40:13 -0500

> Is all this the way it should be?

Regardless of "the way it should be", it's a common issue across a number of
MIBs. :-(

bfdSessIpMapTable is there to let you look up the session that is likely to
be what you care about.  However, noting that things have moved to a new
session index requires tracking the fact that the session has dropped and
then using the table to discover the new session index.  This could be done
on each polling cycle (with the usual atomicity issues when polling
disparate tables) or whenever a notification related to the session going
down/coming up happens.

Or the vendor could be requested to put in place measures that result in
stable session indices for dynamically allocated BFD sessions.

-- Jeff