[secdir] Secdir review of draft-perrault-behave-natv2-mib-03

"Takeshi Takahashi" <takeshi_takahashi@nict.go.jp> Mon, 13 April 2015 15:54 UTC

Return-Path: <takeshi_takahashi@nict.go.jp>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F024F1ACE08; Mon, 13 Apr 2015 08:54:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.298
X-Spam-Level: ***
X-Spam-Status: No, score=3.298 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-aLxSSymngN; Mon, 13 Apr 2015 08:54:12 -0700 (PDT)
Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FFB81ACDC4; Mon, 13 Apr 2015 08:54:12 -0700 (PDT)
Received: from gw2.nict.go.jp (gw2.nict.go.jp [133.243.18.251]) by ns2.nict.go.jp with ESMTP id t3DFs8DT023656; Tue, 14 Apr 2015 00:54:08 +0900 (JST)
Received: from TakeVaioVJP13 (ssh.nict.go.jp [133.243.3.49]) by gw2.nict.go.jp with ESMTP id t3DFs50Y023650; Tue, 14 Apr 2015 00:54:06 +0900 (JST)
From: Takeshi Takahashi <takeshi_takahashi@nict.go.jp>
To: draft-perrault-behave-natv2-mib.all@tools.ietf.org
Date: Tue, 14 Apr 2015 00:54:07 +0900
Message-ID: <008201d07602$149a67e0$3dcf37a0$@nict.go.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AdB111/h0yd7zQHoRkKk9EAsY4rZpw==
Content-Language: ja
X-Virus-Scanned: clamav-milter 0.98.5 at zenith2
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/GxB7srtCGHhueiXlZBNbSAwZUcc>
Cc: behave-chairs@tools.ietf.org, 'The IESG' <iesg@ietf.org>, secdir@ietf.org
Subject: [secdir] Secdir review of draft-perrault-behave-natv2-mib-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Apr 2015 15:54:14 -0000

Hello,

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security area
directors.
Document editors and WG chairs should treat these comments just like any
other last call comments.

This document is ready for publication.

[summary of this document]

This draft defines a portion of the MIB for devices implementing the NAT
function.
The new MIB module defined in this document, NATv2-MIB is intended to
replace module NAT-MIB (RFC 4008).
The document claims that the version 2 has more focus on measurement, while
the version 1 has more focus on configuration.
This document begins with defining four types of content the NATv2-MIB
module provides, followed by the outline of MIB module organization (OID
map) and detailed explanation of MIB-related tables.

[comment on security consideration]

The biggest concern I had when reading this draft was the manipulation of
the MIB by malicious parties.
Access control and encryption need to be addressed.
The current security consideration section raises adequate concerns on that,
and I think the section is fine.

[minor questions]

Let me ask minor three questions to deepen my understanding on this draft.
Note that these questions are purely for deepening my understanding, and I
am not asking to change the sentences of the draft at all by these
questions.

1. [Section 3.1.2 in page 7]
   question on natv2NotificationPoolUsageHigh and
natv2NotificationPoolUsageLow.

It is easy to imagine the use of "natv2NotificationPoolUsageHigh", but I am
not sure what kind of usage we have on the "natv2NotificationPoolUsageLow".
The notification indicates that "usage equals or has fallen below a lower
threshold".
What kind of actions are we going to take by receiving the notification?
Are we going to aggregate two rarely-used NAT modules into one based on this
notification?

The NATv2-MIB provides state information, as described in Section 3.1.3.
I assume that administrators of NAT modules monitor the state information
periodically in order to redesign NAT modules (if needed).
If so, I do not think administrators rely on the
natv2NotificationPoolUsageLow notification; I do not see the need to receive
real-time notification of rarely-used NAT.
I might have totally misunderstood; I would appreciate some guidance on
this.


2. [Section 3.1.2 in page 7]
   question on disabling notifications.

"A given notification can be disabled by setting the threshold to 0
(default)" with the exception of natv2PoolThresholdUsageLow, which uses "-1"
to disable its notification.
Having two different values on the same kind of issues is a bit confusing to
me.
I wonder whether we could have any problem if we use the value "-1" for all
the threshold values to disable notifications.
Are there any disadvantages using "-1" instead of using the mixture of "0"
and "-1" for the threshold values?


3. [Section 3.1.4 in page 10]
   question on Statistics.

This question is related to the counters "address/port map limit drops".
According to the draft, the counters are incremented based on the threshold
values for address/port mapping.
Then, I would avoid setting a value that is more than the NAT module's
capability.
Do we have any means to check the appropriateness of the threshold value?
(I am not sure whether it is possible to measure NAT's processing
capabilities in advance.)

Thank you.

Take