Subject: Re: [BEHAVE] WGLC on draft-ietf-behave-nat-mib

From: Simon Perreault <[email-masked]>
Date: Wed, 10 Jul 2013 15:52:00 +0200

Le 2013-05-31 15:47, ietfdbh a écrit :
> 1) A while back, I suggested that, if you are deprecating all of the NAT-MIB
> in rfc4008, that it would be better to do this as a separate document from
> the NEW-NAT-MIB (or whatever the new module gets called). Simon asked me to
> get consensus from the MIB Doctors.
> 
> I checked with the MIB Doctor list, and only got one reply - from Juergen,
> who apparently recommended a single document. His response:
> " I have probably been pushing them into this because at the beginning it
> was not really clear why the existing NAT-MIB is fatally flawed such that it
> needs a complete replacement. If the behave WG has meanwhile reached
> consensus that indeed the existing NAT-MIB is fatally flawed and needs a
> complete replacement, then indeed what you suggest makes sense. I assume the
> WG has checked with those who have implementations of the existing NAT-MIB
> (if any) that they agree on a need for a complete new MIB."

I'm having trouble parsing this.

Our position, and we feel we have the consensus of the WG with us, is
that the existing NAT-MIB is fatally flawed and we need a complete
replacement. The reasons are explained in section 3.1.
https://tools.ietf.org/html/draft-ietf-behave-nat-mib-06#section-3.1

That's why we initially started with a brand new MIB, called the
NEW-NAT-MIB. We changed into the current structure based on feedback
from the working group in general and Juergen in particular.

So, what would be your advice?

> 2) Since deprecated objects are not obsoleted, I think new security
> considerations might be called for relating to the deprecated objects -
> especially if there are security implications of implementing BOTH the
> current and deprecated objects. 
> 
> Some NMS applications will support only the old MIB module; others may
> support only the new MIB module. Some agents will want to implement both, to
> make their devices manageable from either type of NMS application. Some NMS
> applications will want to support both, to deal with both legacy and new
> agents. 

Totally agreed.

> MIB modules often make information available that could potentially be used
> by attackers. 
> Are there particular risks involved in exposing the information of these two
> NAT-MIBs in combination? 
> Are there potential risks associated with the potential confusion of looking
> at a NAT from the different perspectives used by these two NAT MIB
> approaches?

Well, I don't see any possible synergistic security hole that would be
created by the combination of the old and new MIB. So I would be
inclined to just creating new security considerations for the deprecated
objects.

> 3) I notice there is no "Operational Considerations" section. I wonder if
> one is called for here, because operators may be faced with NMS applications
> and/or agents that support both the deprecated and the new MIB module. What
> should operators (and NMS applications) do with this potentially conflicting
> information? What should they explicitly NOT do? E.g., What assumptions
> should they NOT make about the relationships between specific objects in the
> old and new versions?

It's a good question, but I can't think of anything specific. I'll keep
this in mind.

> My impression is that the old and the new MIB modules might be appropriate
> depending on the environment in which they exist, and the old MIB is
> implemented (to whatever degree of compliance) in existing legacy devices,
> so simply saying "never use the old MIB" is not going to be an acceptable
> approach. 

Indeed. And that's not what the document says.

Simon

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 Jul 2013 16:19:12 +0200

> from the working group in general and Juergen in particular.

As far as I recall, it was initially not clear whether there is
consensus that the NAT-MIB is fatally flawed. (And the text that is
now in section 3.1 did not exist at that time in the current level of
detail as far as I recall.)

I suggest a consensus call is made by the chairs on this fundamental
question. If there is consensus that the NAT-MIB is fatally flawed
(and note that opinions of implementors in particular matter here),
then declaring the MIB module in RFC 4008 historic (e.g. marking RFC
4008 historic) and creating a new MIB module may indeed be the right
thing to do.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>