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

"ietfdbh" <> Fri, 31 May 2013 17:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 96AA321F938E for <>; Fri, 31 May 2013 10:04:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -97.838
X-Spam-Status: No, score=-97.838 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I7JdneesmZEq for <>; Fri, 31 May 2013 10:04:54 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:44:76:96:59:243]) by (Postfix) with ESMTP id 8D4B821F8F83 for <>; Fri, 31 May 2013 10:04:50 -0700 (PDT)
Received: from ([]) by with comcast id ih101l0091vXlb85Dh4omg; Fri, 31 May 2013 17:04:48 +0000
Received: from JV6RVH1 ([]) by with comcast id ih4o1l00B2yZEBF3dh4ot9; Fri, 31 May 2013 17:04:48 +0000
From: "ietfdbh" <>
To: "'Simon Perreault'" <>, "'Dave Thaler'" <>
Date: Fri, 31 May 2013 13:04:31 -0400
Message-ID: <005a01ce5e20$ebb93130$c32b9390$>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac5eIOsemTjvHZTxRPGVjUEgOOEGGQ==
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1370019888; bh=2q7OlRIbV8mMfSG08ekBy8aYo6rB4FBpf+y0wAKLF+Q=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=OxCS9qboCfvp1GimiDpgh0CuMXyBw2x9q9otNIHUsKE4+2ze4i3slB2Q3uH9YT+5j O36OiC3UFgLrBhex7/2Ldu3rGykTGWjmxuESf3TzhmqXIDSh9SeUbqVTQh4vt5nCx2 gw3fNfa/6iCwB09t+yXSO1vIZ9ETAxACp5EINMk7Ercie4StH4djdvrPwWHDVTP9Ri byqgssJd2USXMYNTmyTR85vlMcXJlugWqkFlUlKDCvFaNDHQpMgysbp3l1Yf1G/QuF Wmg0ENqt8RsppxepHqgBVf+YV5/ZUOls6OGMNY6ziurlIV84QOsppCnN972Sy8yYoU 6MrDMsTonreIA==
Subject: Re: [BEHAVE] WGLC on draft-ietf-behave-nat-mib - SMI violation?
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: Fri, 31 May 2013 17:04:58 -0000


natAddrPortBindLocalAddr - the one being deprecated - is redefined in the
new document. The original had InetAddress syntax with no range; the new doc
adds a range (thereby redefining the range).
I think this violates SMI rules (but it deserves checking to be sure).

David Harrington

-----Original Message-----
From: [] On Behalf Of
Sent: Friday, May 31, 2013 9:48 AM
To: 'Simon Perreault'; 'Dave Thaler'
Subject: Re: [BEHAVE] WGLC on draft-ietf-behave-nat-mib


Three things.

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

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

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

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?

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

David Harrington
-----Original Message-----
From: [] On Behalf Of
Simon Perreault
Sent: Friday, May 31, 2013 3:51 AM
To: Dave Thaler
Subject: Re: [BEHAVE] WGLC on draft-ietf-behave-nat-mib

Le 2013-05-30 21:38, Dave Thaler a écrit :
>>> 4) The MIB compiler I used complained about this:
>>>> natMappingPool OBJECT-TYPE
>>>>       SYNTAX NatPoolId (0|1..4294967295)
>>> Because of
>>>>       SYNTAX Unsigned32 (1..4294967295)
>>> That is, NatPoolId does not allow 0, and so natMappingPool cannot 
>>> add it and still use the NatPoolId syntax.
>> Hmmmm... Would it be OK if I changed natMappingPool to an Unsigned32?
>> natMappingPool OBJECT-TYPE
>>       SYNTAX Unsigned32 (0|1..4294967295)
> Yes, but you should remove the range restriction since that's the full
> So just
>          SYNTAX Unsigned32

Right. Removed.

> I see you added in the security considerations section:
>>       Note: This section only applies to objects with current status.
>>       For deprecated objects, please refer to the Security
>>       Considerations section from [RFC4008].
> However that doesn't make sense in my opinion unless we make RFC4008 a
> Normative (not informative) reference.   But I would prefer keeping it as
> an informative reference so it can be obsoleted.   So I disagree with the
> quoted limitation.

Hmmm... So what should we do instead? Keeping in mind that the security
considerations in 4008 aren't up to today's standards.

a) Copy the security section verbatim from 4008. Add a preamble saying
something like "These considerations apply to the deprecated elements. 
Others may apply, use at your own risk."

b) Create brand new security considerations for deprecated elements.

c) ???

Behave mailing list

Behave mailing list