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

[Tom Taylor <[e-mail]>]

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