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

From: Dave Thaler <[email-masked]>
Date: Wed, 29 May 2013 21:16:08 +0000

We are starting a two-week working group last call for "Additional Managed Objects for Network Address Translators (NAT)", draft-ietf-behave-nat-mib-06,

  http://tools.ietf.org/html/draft-ietf-behave-nat-mib-06 

Please send substantial comments to the list, and simple editorial nits to the authors.

WGLC for this document will end on Wednesday, June 12.

-Dave

---

From: Dave Thaler <[email-masked]>
Date: Wed, 29 May 2013 21:42:54 +0000

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?

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

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

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.

-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Dave Thaler
> Sent: Wednesday, May 29, 2013 2:16 PM
> To: [email-masked]
> Subject: [BEHAVE] WGLC on draft-ietf-behave-nat-mib
> 
> We are starting a two-week working group last call for "Additional Managed
> Objects for Network Address Translators (NAT)", draft-ietf-behave-nat-mib-06,
> 
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

---

From: Simon Perreault <[email-masked]>
Date: Thu, 30 May 2013 11:47:45 +0200

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

> the boilerplate reference to RFC 2119.

*gasp*

Added.

> are needed.  Suggest adding "No IANA actions are required by this document."

Added.

> 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

---

From: Dave Thaler <[email-masked]>
Date: Thu, 30 May 2013 19:38:57 +0000

> From: Simon Perreault [mailto:[email-masked]]
> Sent: Thursday, May 30, 2013 2:48 AM
> To: Dave Thaler
> Cc: [email-masked]; [email-masked]
> Subject: Re: WGLC on draft-ietf-behave-nat-mib
> 
> > Also the document has 2 paragraphs of text "There are a number of
> > managed objects in this MIB that may contain ...

Fine.

> > the boilerplate reference to RFC 2119.

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.

> > That is, NatPoolId does not allow 0, and so natMappingPool cannot add
> > it and still use the NatPoolId syntax.
> 

Yes, but you should remove the range restriction since that's the full range.
So just
        SYNTAX Unsigned32

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

---

From: Simon Perreault <[email-masked]>
Date: Fri, 31 May 2013 09:50:51 +0200

> Yes, but you should remove the range restriction since that's the full range.

Right. Removed.

> an informative reference so it can be obsoleted.   So I disagree with the

Hmmm... So what should we do instead? Keeping in mind that the security 
considerations in 4008 aren't up to today's standards.

a) Copy the security section verbatim from 4008. Add a preamble saying 
something like "These considerations apply to the deprecated elements. 
Others may apply, use at your own risk."

b) Create brand new security considerations for deprecated elements.

c) ???

Simon

---

From: "ietfdbh" <[email-masked]>
Date: Fri, 31 May 2013 09:47:41 -0400

Hi,

Three things.

1) A while back, I suggested that, if you are deprecating all of the NAT-MIB
in rfc4008, that it would be better to do this as a separate document from
the NEW-NAT-MIB (or whatever the new module gets called). Simon asked me to
get consensus from the MIB Doctors.

I checked with the MIB Doctor list, and only got one reply - from Juergen,
who apparently recommended a single document. His response:
" I have probably been pushing them into this because at the beginning it
was not really clear why the existing NAT-MIB is fatally flawed such that it
needs a complete replacement. If the behave WG has meanwhile reached
consensus that indeed the existing NAT-MIB is fatally flawed and needs a
complete replacement, then indeed what you suggest makes sense. I assume the
WG has checked with those who have implementations of the existing NAT-MIB
(if any) that they agree on a need for a complete new MIB."

2) Since deprecated objects are not obsoleted, I think new security
considerations might be called for relating to the deprecated objects -
especially if there are security implications of implementing BOTH the
current and deprecated objects. 

Some NMS applications will support only the old MIB module; others may
support only the new MIB module. Some agents will want to implement both, to
make their devices manageable from either type of NMS application. Some NMS
applications will want to support both, to deal with both legacy and new
agents. 

MIB modules often make information available that could potentially be used
by attackers. 
Are there particular risks involved in exposing the information of these two
NAT-MIBs in combination? 
Are there potential risks associated with the potential confusion of looking
at a NAT from the different perspectives used by these two NAT MIB
approaches?

3) I notice there is no "Operational Considerations" section. I wonder if
one is called for here, because operators may be faced with NMS applications
and/or agents that support both the deprecated and the new MIB module. What
should operators (and NMS applications) do with this potentially conflicting
information? What should they explicitly NOT do? E.g., What assumptions
should they NOT make about the relationships between specific objects in the
old and new versions?

My impression is that the old and the new MIB modules might be appropriate
depending on the environment in which they exist, and the old MIB is
implemented (to whatever degree of compliance) in existing legacy devices,
so simply saying "never use the old MIB" is not going to be an acceptable
approach. 

David Harrington
[email-masked]
+1-603-828-1401
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Simon Perreault
Sent: Friday, May 31, 2013 3:51 AM
To: Dave Thaler
Cc: [email-masked]; [email-masked]
Subject: Re: [BEHAVE] WGLC on draft-ietf-behave-nat-mib

Le 2013-05-30 21:38, Dave Thaler a écrit :
>>> That is, NatPoolId does not allow 0, and so natMappingPool cannot 
>>> add it and still use the NatPoolId syntax.
>>

Right. Removed.

c) ???

Simon