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

Tom Taylor <> Mon, 13 April 2015 18:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 51FF61ACE0D; Mon, 13 Apr 2015 11:57:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tQds6ySO5cVB; Mon, 13 Apr 2015 11:57:13 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5C4301B2A2B; Mon, 13 Apr 2015 11:57:13 -0700 (PDT)
Received: by iebmp1 with SMTP id mp1so73095353ieb.0; Mon, 13 Apr 2015 11:57:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ukgZXIaD0VoEDw75KUtXPJaExtentWggr7nHHaaKYOM=; b=Ip2zyvjLRkHqGP+cdKTEw1Oml0bbDHRenDAKYS7+n6kAcXYnvPHDm+WyvSQYTPoXl6 Japt8Qte/0bqKjt895NGXus5nG5mKxRAF55jTjbhpVP0piIvzMmHJn3+OeOi55Fd3+xr abpfVqZaMknQqlXYrQ7iRmNTLysZJ2Rk2Za5UnsOOVJ0APHtB+so9uY1Ftz8CPQuRIqg Wk2BexgLb1dKJKEuW3VjwzbP0dOq5kOjXzCFbiZPbHLKqudldZ2OVXBCqEKFvHEK/SCb LIq2WnQYGL0ksz8OWwndB8t6+2UIvz28LdE7Jhif5U3uFUgYg2F07isq5RwwguFRCzpM Mzmw==
X-Received: by with SMTP id m9mr18958724igx.45.1428951432886; Mon, 13 Apr 2015 11:57:12 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id kc1sm5535689igb.0.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Apr 2015 11:57:12 -0700 (PDT)
Message-ID: <>
Date: Mon, 13 Apr 2015 14:57:10 -0400
From: Tom Taylor <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Takeshi Takahashi <>,
References: <008201d07602$149a67e0$3dcf37a0$>
In-Reply-To: <008201d07602$149a67e0$3dcf37a0$>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc:, 'The IESG' <>,
Subject: Re: [secdir] Secdir review of draft-perrault-behave-natv2-mib-03
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Apr 2015 18:57:20 -0000

Thank you very much for your review. Some responses below marked with [PTT].

Tom Taylor

On 13/04/2015 11:54 AM, Takeshi Takahashi wrote:
> 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?
[PTT] The notification concerns address pools. Those are sets of 
addresses routable in a given address realm. If the addresses are in one 
pool they are inaccessible to users or services assigned to a different 
pool. The action taken would be to move some of the addresses from the 
underutilized pool to another one than has a high utilization.

[PTT] The need for a notification for this condition is something I 
questioned myself, but apparently someone sees it to be useful.

> 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?
[PTT] I pondered that one myself. There may be some slight effect on 
SNMP message size when conveying this data, but probably you're right, 
we should go for uniformity.
> 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.)
[PTT] I think typically a vendor will quote capacities, and an operator 
will confirm them in the lab before putting the equipment into service.

> Thank you.
> Take