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

Simon Perreault <simon.perreault@viagenie.ca> Wed, 10 July 2013 13:52 UTC

Return-Path: <simon.perreault@viagenie.ca>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62A221F9E94 for <behave@ietfa.amsl.com>; Wed, 10 Jul 2013 06:52:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.467
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mN1qaV7jlQw for <behave@ietfa.amsl.com>; Wed, 10 Jul 2013 06:52:01 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id DBC7B21F9E88 for <behave@ietf.org>; Wed, 10 Jul 2013 06:52:00 -0700 (PDT)
Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:c15b:51e7:d305:cc6c]) by jazz.viagenie.ca (Postfix) with ESMTPSA id BEF8740430; Wed, 10 Jul 2013 09:51:59 -0400 (EDT)
Message-ID: <51DD6700.10901@viagenie.ca>
Date: Wed, 10 Jul 2013 15:52:00 +0200
From: Simon Perreault <simon.perreault@viagenie.ca>
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 <ietfdbh@comcast.net>
References: <7bc37af6cf764c2e965778b6b265a2d4@BY2PR03MB269.namprd03.prod.outlook.com> <ba99d2de63904656992c45255161910a@BY2PR03MB269.namprd03.prod.outlook.com> <51A72041.6060208@viagenie.ca> <2d6b12df967d4faf8fcfd6d6891b2ca2@BN1PR03MB267.namprd03.prod.outlook.com> <51A8565B.5070700@viagenie.ca> <004a01ce5e05$6bf10c90$43d325b0$@comcast.net>
In-Reply-To: <004a01ce5e05$6bf10c90$43d325b0$@comcast.net>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Cc: draft-ietf-behave-nat-mib@tools.ietf.org, behave@ietf.org, 'Dave Thaler' <dthaler@microsoft.com>
Subject: Re: [BEHAVE] WGLC on draft-ietf-behave-nat-mib
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=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.
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