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

[Dave Thaler <[e-mail]>]

> -----Original Message-----
> From: Simon Perreault [mailto:[e-mail]]
> Sent: Thursday, May 30, 2013 2:48 AM
> To: Dave Thaler
> Cc: [e-mail]; [e-mail]
> Subject: Re: WGLC on draft-ietf-behave-nat-mib
> 
> 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.

Fine.


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

Ok.

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

Ok.

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

Yes, but you should remove the range restriction since that's the full range.
So just
        SYNTAX Unsigned32
 
> Updated draft is attached.

I see you added in the security considerations section:
>      Note: This section only applies to objects with current status.
>      For deprecated objects, please refer to the Security
>      Considerations section from [RFC4008].

However that doesn't make sense in my opinion unless we make RFC4008 a
Normative (not informative) reference.   But I would prefer keeping it as
an informative reference so it can be obsoleted.   So I disagree with the
quoted limitation.

-Dave