[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
- [secdir] Secdir review of draft-perrault-behave-n… Takeshi Takahashi
- Re: [secdir] Secdir review of draft-perrault-beha… Tom Taylor
- Re: [secdir] Secdir review of draft-perrault-beha… Senthil Sivakumar (ssenthil)