Last Call Review of draft-perrault-behave-natv2-mib-03
review-perrault-behave-natv2-mib-03-secdir-lc-takahashi-2015-04-14-00

• Status
• Email expansions
• History

• Versions
• 00

Review
review-perrault-behave-natv2-mib-03-secdir-lc-takahashi-2015-04-14

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