Subject: RE: BFD MIB comments

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 1 Oct 2008 07:36:01 -0700

Hello Vishwas.

Enough time has elapsed since last response on this thread, so let me
chime in.

I suppose the question on the table is, it is worth it?

One can see that this is a generic issue for all applications/protocols
using similar authentification mechanism. One popular protocol, ospf,
provide capability for similar authentification. I've taking a look at
the mib spec for ospf (rfc4750). The mib objects defined are simple, and
do not provide support for things such as multiple keys per interface,
dynamic change, or tx/rx key deviations.

Several products of the vendor that I belong to do not and do not plan
to support snmp set operations for bfd mib, due to various reasons.
Hence definitions of bfd-mib-05 to display only active tx
authentification/key for sessions will suffice. If majorities of the
vendors are proceeding in the same manner, then incorporating your
suggested changes is not worth the complexities being added into the mib
definition. That's one "nay" vote for you Tom =)

Obviously this does not preclude specific vendors from defining and
implementing their own version of enterprise mib space to perform what
you suggested.

Thanx,
Nobo

> -----Original Message-----
> From: Thomas Nadeau [mailto:[email-masked]] 
> Sent: Wednesday, September 17, 2008 7:28 PM
> To: Vishwas Manral
> Cc: [email-masked]; Zafar Ali (zali); Nobo Akiya (nobo); 
> [email-masked]
> Subject: Re: BFD MIB comments
> 
> 
> On Sep 17, 2008:11:07 AM, at 11:07 AM, Vishwas Manral wrote:
> 
> > Hi Tom,
> >
> >>> I noticed some small changes required in the MIB which need some 
> >>> consideration, while working on the BFD.
> >>>
> >>> 1. In the session table I find there is an object which states BFD

> >>> SessionAuthenticationType. We also talk about KeyId.
> >>>
> >>> The idea of KeyId is to be able to use any algorithm and Key and 
> >>> hence allow Key changing (for Key rollover)  and authentication
type 
> >>> changing at run time. So a KeyID indexes information which tells
the 
> >>> authentication and the Key to be used. When we want to change
either 
> >>> the algorithm or the Key at either end. We first allow another Key

> >>> ID's to be enabled for packet reception while still using the old 
> >>> one for sending out packets. When all the routers have been 
> >>> configured with this change we can actually do a Key switchover,
by 
> >>> changing the configuration for sending packets. There however
seems 
> >>> only 1 KeyID overall for receiving and sending.
> >>>
> >>> In my view we can have a separate table of all KeyId's which is 
> >>> indexed by each session, just like the session performance table.
> >>> The
> >>> table itself contains KeyId (the Index to the table) active/ 
> >>> inactive/ algorithm to use and direction (outbound/ inbound/
both). 
> >>> There can be only one sending but multiple reception Keys active
at 
> >>> one time (so if another is made active the otehr row needs to be 
> >>> made inactive).
> >>
> >>       This is a pretty significant change. I'd like to hear from
the 
> >> vendors who are implementing this to see if this is really needed
in 
> >> their implementations.
> >
> > Yes this is a significant change. But it meets the requirement of
what 
> > is explained in the MIB draft itself of allowing multiple KeyID's.
We 
> > currently talk about allowing multiple KeyId's active however the 
> > session has only 1 KeyId field.
> >
> > Yes, we are implementing it. This thing is already there in our
other 
> > protocol implementations.
> 
>       I am sure that you are. *)  I want to know who all else is using
it.
> 
>       --Tom
> 
> 
> 
> >>> 3. I think BFDSessionPerfEntry needs to have counts of at least 
> >>> packets which were discarded - if not count of the reasons of each

> >>> kind of packet discarded.
> >>
> >>       This is very difficult to do in a real implementation -- 
> >> especially one that is highly optimized for the positive case; 
> >> therefore, I do not think we should do this. At best I would say 
> >> counting discards without a reason is the way to go here.
> >
> > Yes that would be ok too. Though I would prefer more diagnostics 
> > information.
> >
> >>
> >>> 4. I think we need to add number of packets for which
authentication 
> >>> failed. It is very helpful and essential and figuring if there are

> >>> any misbehaving packets being received.
> >>
> >>       The alternative to counting, is to just have a time stamp for

> >> the last failure. Operationally it is not the number of failures on
a 
> >> session that matter (most of the time), but when the last time it 
> >> happened.
> > Yes, agree. However if you see the security perspective, you would 
> > want to know how many times there have been tries to test the
security 
> > of the system.
> >
> >>> If you need help with this, do let me know and I can update this 
> >>> myself too.
> > Ok, this offer is still open. :)
> >
> > Thanks,
> > Vishwas
> >
> 
>

---

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 1 Oct 2008 21:09:56 +0530

Hi Nobo,

Thanks for your detailed reply.

So if I understand your reply, you are saying the OSPF MIB RFC does
not support it, besides because it adds complexity to the MIB, so you
are not in support of it. Here are some points you may want to
consider:

1. RFC4750, does not have any reference about KeyId of Key itself. So
we are digressing from the RFC4750 in this respect already.

2. In the MIB document itself we talk about allowing multiple KeyId's
and Keys, but the MIB does not support it.

So in my view if we are not for adding a new table, let us make the
MIB like RFC4750 and remove KeyId from the MIB. We also need to update
the description that states we should allow multiple Key ID's. Leaving
it the way it is is not complete in anyway - we should either follow
something which we state and have as part of the BFD base spec (which
I would ahve prefered) or not, I do not think we should state
something and do something else.

Thanks again,
Vishwas

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 1 Oct 2008 12:45:30 -0400

[Not speaking in the capacity of WG chair]

Vishwas,

To add to my exchange with Nobo off-list:

> something and do something else.

Arguably the OSPF RFC itself is similarly at fault for not including the
key id in the MIB.  Let's simply consider OSPF as an example of what had
been considered passable practice before.

We have a few options that we could consider:
1. Allow these objects to be read-create in their current form.  This
   allows implementors to support some form of authentication
   configuration via SNMP.  This would involve updating the
   documentation to note support for management of a single key ID at a
   time.  Key rotation is not handled.  This achieves functional parity
   with deployed features such as OSPF.  Key update in practice must be
   done by atomic update using a set containing all affected objects in
   the same varBindList or otherwise risk the session dropping.
2. Move these objects to read-only for management purposes.  Vendors
   wishing to support a specific key scheme can do so via enterprise
   MIB.  This avoids imposing a committee-designed key configuration and
   rotation mechanism which may be at odds with a given vendor's
   configuration paradigm.
3. Factor the authentication objects from the session table into an
   authentication table.  Potentially include key rotation mechanisms.
   This however introduces relational integrity issues with the session
   table and activation state integrity issues with regards to the session
   table's rowstatus object.

   (SNMP people who understand the last sentence very likely are making
   culturally relevant motions to ward off evil.)

In my personal opinion, 1 seems to be a status-quo option that maintains
parity with OSPF.  It's also possible no one has noticed the OSPF issue
because no one wants to support writeable objects.

2 would similarly address your MIB document correctness issues but upset
various vocal subsets of IETF that really want objects you can set.
(IMNSHO those people don't usually have to deal with the relational
integrity issues that one single protocol component usually has with
related subsystems.  BFD has a ton of those.)

3 is arguably the "correct thing to do when designing a MIB" but
introduces a lot headache that the majority of vendors probably don't
want to support anyway.  Those people will likely demand the conformance
statement for the MIB make the authentication table optional.  Arguably,
given either 1 or 2 a vendor can implement their own version of 3 that
integrates well with their particular management paradigm.

Have I missed anything?

-- Jeff

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 2 Oct 2008 08:03:11 +0530

Hi Jeff,

That is a well thought of and helpful mail. I totally agree with what you state.

Thanks,
Vishwas

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 2 Oct 2008 11:21:43 -0400

Vishwas,

> That is a well thought of and helpful mail. I totally agree with what you state.

Thanks.

Presuming that you agree that factoring the authentication table out is
probably not a good option, do you have a preference for keeping the
objects read-create and updating the document text or making them
read-only?

-- Jeff

---

From: "Vishwas Manral" <[email-masked]>
Date: Fri, 3 Oct 2008 09:01:14 +0530

Hi Jeff,

The better option could be to make it "read-only" and thus allowing
vendor freedom to use any mechanism for Key rotation and
configuration.

However this would be at odds with the OSPF MIB, which makes the key
as "read-create"

Thanks,
Vishwas