Re: [BEHAVE] WGLC on draft-ietf-behave-nat-mib

[Simon Perreault <[e-mail]>]

Le 2013-05-29 23:42, Dave Thaler a écrit :
> Some initial items noticed by document shepherd (me):
>
> 1) Section 5 of the current draft has
> " Some of the readable objects in this MIB module (i.e., objects with a
>     MAX-ACCESS other than not-accessible) may be considered sensitive or
>     vulnerable in some network environments.  It is thus important to
>     control even GET and/or NOTIFY access to these objects and possibly
>     to even encrypt the values of these objects when sending them over
>     the network via SNMP."
>
> Per http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security
> that's supposed to be followed with
> " These are the tables and objects and their
>     sensitivity/vulnerability:
>
>      <list the tables and objects and state why they are sensitive>"
>
> Also the document has 2 paragraphs of text
> "There are a number of managed objects in this MIB that may contain
> ...
> versions of SNMP provide features for such a secure environment."
> which do not appear in the current MIB boilerplate at the link above.
> Should those 2 paragraphs be removed?

How about this as a replacement?

    Some of the readable objects in this MIB module (i.e., objects with a
    MAX-ACCESS other than not-accessible) may be considered sensitive or
    vulnerable in some network environments.  It is thus important to
    control even GET and/or NOTIFY access to these objects and possibly
    to even encrypt the values of these objects when sending them over
    the network via SNMP.  These are the tables and objects and their
    sensitivity/vulnerability:

    Objects that reveal host identities:  Various objects can reveal the
       identity of private hosts that are engaged in a session with
       external end nodes.  A curious outsider could monitor these to
       assess the number of private hosts being supported by the NAT
       device.  Further, a disgruntled former employee of an enterprise
       could use the information to break into specific private hosts by
       intercepting the existing sessions or originating new sessions
       into the host.

       *  natMapIntAddrType

       *  natMapIntAddrInt

       *  natMapIntAddrExt

       *  natMappingIntRealm

       *  natMappingIntAddressType

       *  natMappingIntAddress

       *  natMappingIntPort

       *  natMappingMapBehavior

       *  natMappingFilterBehavior

       *  natMappingAddressPooling

       *  natSubscriberIntPrefixType

       *  natSubscriberIntPrefix

       *  natSubscriberIntPrefixLength

    Other objects that reveal NAT state:  Other managed objects in this
       MIB may contain information that may be sensitive from a business
       perspective, in that they may represent NAT state information.

       *  natCntAddressMappings

       *  natCntProtocolMappings

       *  natPoolUsage

       *  natPoolRangeAllocatedPorts

       *  natSubscriberCntMappings

    There are no objects that are sensitive in their own right, such as
    passwords or monetary amounts.

> 2) Section 5 contains MUST, SHOULD, etc.   But the document is missing
> the boilerplate reference to RFC 2119.

*gasp*

Added.

> 3) Section 6 does not say whether any additional actions for IANA
> are needed.  Suggest adding "No IANA actions are required by this document."

Added.

> 4) The MIB compiler I used complained about this:
>> natMappingPool OBJECT-TYPE
>>      SYNTAX NatPoolId (0|1..4294967295)
> Because of
>> NatPoolId ::= TEXTUAL-CONVENTION
>>      SYNTAX Unsigned32 (1..4294967295)
>
> That is, NatPoolId does not allow 0, and so natMappingPool cannot add it
> and still use the NatPoolId syntax.

Hmmmm... Would it be OK if I changed natMappingPool to an Unsigned32?

natMappingPool OBJECT-TYPE
     SYNTAX Unsigned32 (0|1..4294967295)

Updated draft is attached.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca