Re: [BEHAVE] WGLC on draft-ietf-behave-nat-mib - SMI violation?
"ietfdbh" <firstname.lastname@example.org> Fri, 31 May 2013 17:04 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96AA321F938E for <email@example.com>; Fri, 31 May 2013 10:04:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([126.96.36.199]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7JdneesmZEq for <firstname.lastname@example.org>; Fri, 31 May 2013 10:04:54 -0700 (PDT)
Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4B821F8F83 for <email@example.com>; Fri, 31 May 2013 10:04:50 -0700 (PDT)
Received: from omta17.westchester.pa.mail.comcast.net ([188.8.131.52]) by qmta13.westchester.pa.mail.comcast.net with comcast id ih101l0091vXlb85Dh4omg; Fri, 31 May 2013 17:04:48 +0000
Received: from JV6RVH1 ([184.108.40.206]) by omta17.westchester.pa.mail.comcast.net with comcast id ih4o1l00B2yZEBF3dh4ot9; Fri, 31 May 2013 17:04:48 +0000
From: "ietfdbh" <firstname.lastname@example.org>
To: "'Simon Perreault'" <email@example.com>, "'Dave Thaler'" <firstname.lastname@example.org>
Date: Fri, 31 May 2013 13:04:31 -0400
Content-Type: text/plain; charset="iso-8859-1"
X-Mailer: Microsoft Outlook 14.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; 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==
Cc: email@example.com, firstname.lastname@example.org
Subject: Re: [BEHAVE] WGLC on draft-ietf-behave-nat-mib - SMI violation?
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Fri, 31 May 2013 17:04:58 -0000
Hi, 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 email@example.com +1-603-828-1401 -----Original Message----- From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of ietfdbh Sent: Friday, May 31, 2013 9:48 AM To: 'Simon Perreault'; 'Dave Thaler' Cc: firstname.lastname@example.org; email@example.com Subject: Re: [BEHAVE] WGLC on draft-ietf-behave-nat-mib Hi, 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 agents. 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? 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 approach. David Harrington firstname.lastname@example.org +1-603-828-1401 -----Original Message----- From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Simon Perreault Sent: Friday, May 31, 2013 3:51 AM To: Dave Thaler Cc: email@example.com; firstname.lastname@example.org 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 >>>> NatPoolId ::= TEXTUAL-CONVENTION >>>> 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 range. > 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) ??? Simon _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave
- Re: [BEHAVE] WGLC on draft-ietf-behave-nat-mib - … ietfdbh
- Re: [BEHAVE] WGLC on draft-ietf-behave-nat-mib - … Simon Perreault