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

From: "Takeshi Takahashi" <[email-masked]>
Date: Tue, 14 Apr 2015 00:54:07 +0900

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

---

From: Tom Taylor <[email-masked]>
Date: Mon, 13 Apr 2015 14:57:10 -0400

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

Tom Taylor

> Are we going to aggregate two rarely-used NAT modules into one based on this
[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.

> 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.
> 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.

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Mon, 13 Apr 2015 19:41:17 +0000

Please find some answers below.

>Are we going to aggregate two rarely-used NAT modules into one based on

The usage of natv2NotificationPoolUsageHigh is to provision more addresses
and 
natv2NotificationPoolUsageLow is to reclaim the addresses. Usually, the
high and 

low notifications happen at the beginning of a deployment that helps the
network 
operators to find a happy medium. Once the network is up and running, some
strange Ddos attacks would trigger the high and a temporary provisioning
of 
more addresses and then once the attack is identified and averted, the
addresses 
can be reclaimed (either with a low notification or otherwise). As to what
people
do with reclaiming the addresses is hard to say. With cloud deployments,
it is 
possible to envision a scenario to dynamically use the addresses in an
efficient way to 
reclaim addresses and use it for other NAT instances.

>and "-1" for the threshold values?

I don¹t see a disadvantage of using -1 across the board to disable
thresholds, 
however, it is easy to understand, the value of 0 to disable the
threshold. 
(with just one exception).

Thanks
Senthil