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

Simon Perreault <> Wed, 10 July 2013 13:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D62A221F9E94 for <>; Wed, 10 Jul 2013 06:52:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.467
X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1mN1qaV7jlQw for <>; Wed, 10 Jul 2013 06:52:01 -0700 (PDT)
Received: from ( [IPv6:2620:0:230:8000::2]) by (Postfix) with ESMTP id DBC7B21F9E88 for <>; Wed, 10 Jul 2013 06:52:00 -0700 (PDT)
Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:c15b:51e7:d305:cc6c]) by (Postfix) with ESMTPSA id BEF8740430; Wed, 10 Jul 2013 09:51:59 -0400 (EDT)
Message-ID: <>
Date: Wed, 10 Jul 2013 15:52:00 +0200
From: Simon Perreault <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: ietfdbh <>
References: <> <> <> <> <> <004a01ce5e05$6bf10c90$43d325b0$>
In-Reply-To: <004a01ce5e05$6bf10c90$43d325b0$>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Cc:,, 'Dave Thaler' <>
Subject: Re: [BEHAVE] WGLC on draft-ietf-behave-nat-mib
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 Jul 2013 13:52:02 -0000

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.

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

> 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.