Subject: [midcom] RE: NAT-MIB review

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 12 Sep 2003 15:23:55 +0200

Thanks Juergen.
So I expect the authors to respond/comment back, and to most
probably issue another revision to address the issues.

Pls copy me explicitly on any follow up communication, cause 
I am currently not subscribed to midcom list.

Thanks,
Bert 

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email-masked]]
> Sent: donderdag 11 september 2003 18:05
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: NAT-MIB review
> 
> 
> Bert asked me to play the MIB doctor for the NAT-MIB and so I have
> reviewed <draft-ietf-nat-natmib-06.txt>. The document needs further
> editorial work in order to comply with the MIB guidelines as
> documented in <draft-ietf-ops-mib-review-guidelines-02.txt> and there
> are several technical questions that need to be discussed and resolved
> before the document is ready to go.
> 
>  1) The abstract should not contain references, see also the 
> guidelines
>     document.
> 
>  2) I suggest to add definitions of key terms into section 3. In
>     particular, I would like to see a definition for concepts such
>     as sessions, groups and probably owners. Also the relationship
>     to other MIDCOM work needs to be explained since the MIB module
>     talks about "MIDCOM compliance" and I have no clue what that
>     means (see also below).
> 
>  3) In the overview section, you should say that this MIB module
>     depends in some parts on the IF-MIB.
> 
>  4) In the overview section, please introduce the names of the tables
>     and use these names where appropriate to reduce any risk for
>     confusion. Some phrases I think are a bit confusing, e.g.
> 
>    o two scalars used to monitor address thresholds and generate 
>      notifications when the thresholds are crossed.
>     
>     I do not think you monitor thresholds. In fact, these thresholds
>     define when notifications are generated. (And my later reading of
>     the MIB makes me wonder whether the second one is ever used.)
> 
>  5) typo "... the currently exist ..." -> "... that currently 
> exist ..."
> 
>  6) Section 4.1 says:
> 
>    The association between the various configuration tables can be
>    represented as follows:
> 
> 
>      per interface config   (global config parameters)
>         |                            |
>         |                            |  
>         |                            |
>         |----------------------------|                       
>         |                       
>         |                      
>      address map     
>  
>     My understanding is that the global config parameters are just
>     a few scalars and not a table.
> 
>  7) Section 4.3 says that binds which point to non-existing address
>     maps are not allowed. In the MIB definitions, it would be very
>     useful to say precisely what happens if one tries to violate the
>     rule (that is, which error code is actually generated when I try
>     to delete an address map with pending binds or try to create a
>     bind which points to a non-existing address map).
> 
>  8) You seem to use the RowStatus for two purposes -
>     creating/destroying rows as well as enabling/disabling them. The
>     compliance allows implementations that do only one-shot row
>     creation and deletion, which means that those implementations
>     do not have the capability to disable a row. Also note that a
>     row in the notInService state has a timer attached so the row
>     cannot be in that state for longer periods of time.
> 
>     Perhaps you want to introduce explicit enabled/disabled states for
>     the rows in question in case it makes sense.
> 
>  9) The start of the module needs editorial work so that it conforms
>     to section 4.5 in the MIB review guidelines document.
> 
> 10) I suggest to also make the bit set representation of the protocol
>     types an explicit TC so that both TCs are close together which
>     reduces any maintenance issues.
> 
> 11) What does an idle timeout of 0 seconds actually mean? (This
>     question affects natConfUdpDefIdleTimeout,
>     natConfIcmpDefIdleTimeout, natConfOtherDefIdleTimeout,
>     natConfTcpDefIdleTimeout and natConfTcpDefNegTimeout.
> 
> 12) I suggest to reword the description of the TCP idle timeout
>     objects:
> 
>     natConfTcpDefIdleTimeout:
> 
>     The default time interval a NAT session (or is it a binding or
>     both?) for an established TCP connection is allowed to remain
>     valid without any activity on the TCP connection.
> 
>     natConfTcpDefNegTimeout:
> 
>     The default time interval a NAT session (or is it a binding or
>     both?) for a TCP connection which is not in the established state
>     is allowed to remain valid without any activity on the TCP
>     connection.
> 
>     The point here is that the phrase "TCP protocol session" confuses
>     me - do you refer to a NAT session for a TCP connection or
>     something else?
> 
> 13) I fail to see how the notification thresholds actually work. It
>     seems to me that actually only the natConfAddrRiseThreshold is
>     used. If my reading is wrong, the text probably has to be
>     improved.
> 
> 14) typo "... Groupn" -> "... Group"
> 
> 15) The description of the natConfInterfaceTable should probably say
>     that this is per interface configuration (and then you can remove
>     the comment above ;-).
> 
> 16) Why do you introduce natConfInterfaceIndex and not just import and
>     use ifIndex?
> 
> 17) What are the semantics of zero-length natConfAddrMapConfigName
>     values? Can I actually have multiple natConfAddrMapConfigName
>     objects with the same value? If not, what happens if I try to
>     create them? And why do you identify address maps by name when all
>     the other entities are identified by numbers?
> 
>     Also, I find the description confusing since this does not
>     according to my understanding select a set of address maps but
>     rather a single address map.
> 
> 18) The StorageType TC requires you to specify which objects are
>     writable if the storage type is permanent - see also section 4.6.4
>     in the MIB review guidelines document. This is missing in all
>     places where StorageType is being used.
> 
> 19) I fail to understand the concept of the OwnerId and GoupId. What
>     does the value 42 tell a management station? I think this concept
>     is important to introduce in the beginning of the document.
> 
> 20) What precisely happens if I write a value != 0 to
>     natConfLocalPortFrom, natConfLocalPortTo, natConfGlobalPortFrom,
>     natConfGlobalPortTo on a basic NAT?
> 
> 21) I think the number space for address binds (e.g. natAddrBindId,
>     natAddrPortBindId) should exclude the value 0. Perhaps it actually
>     makes sense to introduce TCs doe NatAddrBindId and
>     NatAddrBindIdOrZero so things will be consistent.
> 
> 22) The description of natAddrBindDirection says:
> 
>             "This object represents the direction of the BIND.
>              A BIND may be either uni-directional or bi-directional,
>              same as the orientation of the address map, based on
>              which this bind is formed."
> 
>     Where in the address map is the direction specified?
> 
> 23) Please say precisely which error is to be generated if you set
>     natAddrBindAddrMapName or natAddrPortBindAddrMapName to a non
>     existent addrMapName.
> 
> 24) Should natAddrBindMaxIdleTime natAddrPortBindMaxIdleTime and
>     natSessionMaxIdleTime not use syntax TimeInterval instead of
>     TimeTicks?
> 
> 25) You may want to rename all counters ending in *Translate to
>     *Translates to follow the old rules that counters are in plural.
> 
> 26) The natAddrBindTable, natAddrPortBindTable and natSessionTable
>     have no StorageType, see the MIB review guidelines document.
> 
>     (In general, one can also ask why these tables are not part of the
>     configuration branch since I can do row creation here. Also there
>     are counters in the translation tables which are actually
>     statistics. Personally, I would just drop the branches since they
>     serve no real value and only increase the length of the OIDs.)
> 
> 27) What is the "query id" you refer to in the description of
>     natAddrPortBindLocalPort and natAddrPortBindGlobalPort? If you
>     mean the ICMP type code, then please say ICMP type code.
> 
> 28) In the number space for session, you really want to exclude the
>     value 0. Again, it might help to introduce specific TC(s).
> 
> 29) What is the relationship between binds and sessions? Your MIB
>     is modelled as if it is 1:n, that is you can have n sessions
>     for one bind. Is that the case?
> 
> 30) Is there redundant information? Can a session have a different
>     protocol type than the associated binds? Or why are
>     natSessionProtocolType and friends needed?
> 
> 31) Looking at this description:
> 
>     natStatsAddrMapAddrUsed OBJECT-TYPE
>         SYNTAX     Gauge32
>         MAX-ACCESS read-only
>         STATUS     current
>         DESCRIPTION
>                 "The number of addresses, pertaining to this 
> address map,
>                  that are currently being used from the nat pool. The
>                  value of this object is irrelevant if the 
> address map in
>                  question is a static address map." 
>         ::= { natStatsAddrMapEntry 6 }
>     
>     What does it mean that the object is irrelevant? Should it still
>     be implemented (if not clarify in the compliance definition). If
>     implemented, should it still report the correct value or can it
>     contain arbitrary garbage?
> 
> 32) I propose to rename the following objects for consistency:
> 
>     natStatsInterfacePktsIn  -> natStatsInterfaceInTranslates
>     natStatsInterfacePktsOut -> natStatsInterfaceOutTranslates
> 
> 33) I suggest to change the notification registration as follows:
> 
>     natMIBNotifications OBJECT IDENTIFIER ::= { natMIB 0 }
> 
>     natAddressUseRising NOTIFICATION-TYPE
>         -- yada yada
>         ::= { natMIBNotifications 1 }
> 
>     natPacketDiscard NOTIFICATION-TYPE
>         -- yada yada
>         ::= { natMIBNotifications 2 }
> 
> 
>     This again saves a sub-identifier and makes things more compact.
> 
> 34) The description of natAddressUseRising makes me beliefe that the
>     falling threshold is actually never being used.
> 
> 35) Why can you not use natConfAddrMapName instead of natAddrMapName
>     in the natPacketDiscard notification? And since you only
>     distinguish two discard reasons, why do you not simply use two
>     different notifications? This would avoid the introduction of
>     natPktDiscardReason. (In general, accessible-for-notify is kind of
>     a strange construction and this is why I wonder about these
>     objects.)
> 
> 36) In the compliance section, you always talk about "MIDCOM
>     compliance" and I have no clue what that means.
> 
> 37) I think there are dependencies between the natMIBNotif*Groups and
>     you probably want to spell them out since it does not make sense
>     to implement the natMIBNotificationGroup without the other
>     natMIBNotif*Groups.
> 
> 38) I think section 9 is not really needed since this OID assignment
>     will happen automatically when this document is being processed.
> 
> 39) In the security considerations, you simply state that "some of
>     these objects could contain sensitive information, e.g. bind
>     information". For someone deploying this, it might be useful to
>     have a more explicit discussion of the security implications.
> 
> 40) Remove the leading quote character in teh Full Copyright Statement
>     section.
> 
> That's it.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 
> 28725 Bremen, Germany
> 

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 14 Sep 2003 20:01:06 -0700 (PDT)

Bert & Juergen,

Please see my comments below.

regards,
suresh

> > before the document is ready to go.
Thanks, Juergen, for the detailed review. Great job indeed. You have really
fine combed the syntax and semantics. Thansk again. I have responded to some
below. For the remaining, I requested Rohit, one of my Co-authors, to chime in.
However, any one of the co-authors might do so.

A bunch of your questions relate to MIDCOM compliance. Unfortunately, the
MidcomBase MIB is not published yet. Until the Midcombase MIB is out, the
MIDCOM extension done in the NAT MIB would not make much sense to the readers,
I am afraid. DO let me know if you have any suggestions on how to go about
this. Thanks.

> >  1) The abstract should not contain references, see also the 

Will do.

> >     talks about "MIDCOM compliance" and I have no clue what that

OK. The Midcom compliance is pending a new Midcom draft outlining how SNMPv3
would suffice to serve as MIDCOM protocol. 
 
> >     depends in some parts on the IF-MIB.

Only in that NAT is configurable on a per-interface. We will mention this in
the Overview section. Thanks.
  
> >     the MIB makes me wonder whether the second one is ever used.)

Perhaps Rohit will respond to this.

> >  5) typo "... the currently exist ..." -> "... that currently 
Yup.

> >      per interface config   (global config parameters)

The diagram is correct. The configuration consists of a few global scalars
(natConfig objects 1..7) and a per-interface address map(natConfInterfaceTable)

> >     bind which points to a non-existing address map).
OK. When you try to delete an address map with pending binds, all associated
BINDs are removed. No error is created. Typically, address maps are not edited
once confgured.When you try to create a BIND pointing to a non-existing address
map (or) an exisitng address map, but has no relevance to the BIND, BIND
creation fails - error code: UnknownAddressMapEntry (or)
InvalidAddressMapEntry.

We will add this info. 
> >     the rows in question in case it makes sense.

Perhaps Rohit will respond to this.

> >     to section 4.5 in the MIB review guidelines document.
 
OK. Perhaps Rohit will respond to this.

> >     reduces any maintenance issues.

Agreed. Sounds good.

> >     natConfTcpDefIdleTimeout and natConfTcpDefNegTimeout.

When idle timeout is set to zero, these fields will be assigned their
respective DEFVAL values.
> >     valid without any activity on the TCP connection.

OK. This refers just to the session, not the binding.

> >     me - do you refer to a NAT session for a TCP connection or

Yes. NAT session is for a TCP connection. Sorry about the confusing phrases.
We will fix this.

> >     used. If my reading is wrong, the text probably has to be
Perhaps Rohit will respond to this.

> > 14) typo "... Groupn" -> "... Group"
OK.

> >     that this is per interface configuration (and then you can remove
The description in natConfInterfaceEntry does say this. But, could be clearer,
perhaps.

> > 16) Why do you introduce natConfInterfaceIndex and not just import and

Makes sense. perhaps Rohit will respond to this. 
> >     values? 

A name with zero-length is invalid and has no impact.

> >             Can I actually have multiple natConfAddrMapConfigName
> >     objects with the same value? 
No. NatConfAddrMapTable indexed by natConfAddrMapName.

> >                                  If not, what happens if I try to

Address map is essentially a file name with one or more address map entries
within it. An interface is associated with a unique address map at the
configuration time.

As for the other entries identified by numbers - are you referign to Bind-Id,
session-Id etc? These are NAt generated, so it makes sense for them to be a
number. 
> >     rather a single address map.

Yes. You have just one address map selected per-interface. The actual address
map entries associated with the name are obtained from natConfAddrMapTable.

> >     places where StorageType is being used.

OK. Rohit wil lprobably address this.
only natConfig & natConfAddrMapTable are saved between reboots.

> >     is important to introduce in the beginning of the document.

OK. The concept of Ownerid & GroupId are introduced principally to extend the
MIB to be Midcom compliant. This will become apparent when the Midcom MIB draft
is out. 

Essentially, a Midcombase MIB will maintain a table that associates Midcom
agent (username) with the agentId assigned to it. Perhpa,s we could add a
pointer to the midcombase MIB draft when the draft is published. The draft is
currently in review by the design team.

> >     natConfGlobalPortTo on a basic NAT?

That would not be considered a BasicNat address map. As a result, this woudl
not generate address BINDs. If the parameters donot fit the requirements of a
static map or NAPT or one of the other supported maps, the address map entry
will be declared invalid and will not be used. 
> >     NatAddrBindIdOrZero so things will be consistent.
OK.

> >     Where in the address map is the direction specified?
Good catch. We missed it.

> >     natAddrBindAddrMapName or natAddrPortBindAddrMapName to a non

For the NAT devices that are not MIDCOM compliant or donot communicate with
MIDCOm agents, this is not an issue as the MAP name is generated by the NAT
devices alone. 

In the case a NAT device is in session with a MIDCOM agent, INVALID_MAP_NAME
error will be issued when the specified MapName is invalid. 

> >     natSessionMaxIdleTime not use syntax TimeInterval instead of

Perhaps Rohit will respond to this.

> >     *Translates to follow the old rules that counters are in plural.
OK.

> >     serve no real value and only increase the length of the OIDs.)

natAddrBindTable, natAddrPortBindTable and natSessionTable are genrated
dynamically by the NAt device and are not saved between reboots. Unlike these,
natConfig is a configuration object.

Perhaps, Rohit will respond to this in detail.
> >     mean the ICMP type code, then please say ICMP type code.

This is refering to the Identifier field in the header.

> >     value 0. Again, it might help to introduce specific TC(s).
OK.

> >     for one bind. Is that the case?
Yes.

> >     natSessionProtocolType and friends needed?

Well, session desribes the full session characteristics - namely the original
5-tuple and the xlated 5-tuple. When a session has a non-zero BindId specified,
the ProtocolType and friends in the session must match that of the BIND.
However, in case of a symmetric NAPT device, the Session will have  BindId
specified as Zero. In such a case, the session must include AddressMapName and
AddressMapEntryIndex specified. Oops... these two fields are missing in
NatSessionEntry.

> >     contain arbitrary garbage?

Perhaps Rohit will address this in detail.
But, here is my read on this. In the case of static address map, this could
will be the full count of all addresses that are statically mapped. There is no
room for additional addresses for performing a BIND.

> >     natStatsInterfacePktsOut -> natStatsInterfaceOutTranslates
Sounds good.

> >     falling threshold is actually never being used
> > 

Perhaps, Rohit will respond to the above three.

> >     compliance" and I have no clue what that means.

How do you suggest we break the umbilical chord? I agree, much of this has no
meaning unless the Midcom-MIB is published.

> >     to implement the natMIBNotificationGroup without the other

perhaps Rohit will respond to this.

> >     will happen automatically when this document is being processed.
OK.

> >     have a more explicit discussion of the security implications.

Perhaps, this will make more sense when the Midcom MIB is reviewed and
published. The objective of the Midcom MIB is to ensure that only the
authorized agents are allowed to modify the NAT resources; And, SNMPv3 ishall
be the management protocol.

> > 40) Remove the leading quote character in teh Full Copyright Statement
OK.

> > /js

=====

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 16 Sep 2003 20:39:39 +0200

> I am afraid. DO let me know if you have any suggestions on how to go about

You simply can't publish extensions to something that does not exist. So
either wait with the publication of the NAT-MIB until the MIDCOM MIB is
also ready to go or remove all the MIDCOM specific things and add them
later via AUGMENTS or a NAT-MIB revision or whatever is the right thing
that needs to be done. The point is that I can't judge whether the
MIDCOM specific things make sense to me without having the MIDCOM MIB
in my hands. And the same will hold true for implementors.
 
> creation fails - error code: UnknownAddressMapEntry (or)

Where does this error code go to??? I thought that you would get an SNMP
error code for the set request...`
 
> respective DEFVAL values.

This needs to be spelled out in the DESCRIPTION clauses.

> A name with zero-length is invalid and has no impact.

So why is it allowed if it is invalid? Or do you mean a zero-length
string is a special name which identifies no address map?

> No. NatConfAddrMapTable indexed by natConfAddrMapName.

The natConfAddrMapTable is indexed by natConfAddrMapName but I was
talking about natConfAddrMapConfigName which is a column of the
natConfInterfaceTable. (Perhaps the naming scheme is a bit confusing.
;-)
 
> within it. An interface is associated with a unique address map at the

Well, sounds like one particular implementation approach...
 
> session-Id etc? These are NAt generated, so it makes sense for them to be a

OK - it is the WGs decision after all. But still, you want to clarify
what happens if I assign the same value to different instances of
natConfAddrMapConfigName.

> will be declared invalid and will not be used. 

Please spell that out in the DESCRIPTION clauses.

> error will be issued when the specified MapName is invalid. 

Again, I would expect an SNMP error code...
 
> natConfig is a configuration object.

So why do I then have a RowStatus column?
 
> Perhaps, Rohit will respond to this in detail.

OK, I will see what Rohit has to say about this.
 
> This is refering to the Identifier field in the header.

OK. Then please say clearly in the DESCRIPTION that this refers to the 
Identifier field of ICMP messages.

> authorized agents are allowed to modify the NAT resources; And, SNMPv3 
> ishall be the management protocol.

Not sure I understand this. The NAT-MIB is just a MIB like all others so
the access decision is done by VACM like for all other MIBs. Hence, I
believe the NAT-MIB should discuss which objects are specifically
sensitive and for what reason.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 16 Sep 2003 15:28:13 -0700 (PDT)

> in my hands. And the same will hold true for implementors.

OK. Sounds like, it would be best to remove MIDCOM specific things from the
NAT-MIB now. When the MIDCOM MIB is settled, we could issue a separate draft to
either augment the original NAT-MIB or issue a new NAT-MIB revision.

> error code for the set request...`
You are right. I will check with Rohit on the SNMP error code to use.

OK.

> string is a special name which identifies no address map?

That sounds good. We will add this to the description.

> natConfInterfaceTable. (Perhaps the naming scheme is a bit confusing.
These should be different for each interface.
  
> Well, sounds like one particular implementation approach...
Agreed. It could have been numbers. I just spoke with my co-authors of possibly
using numbers instead of names. I believe, this is not a big issue either way.
We are certainly open to comments from the WG.

> natConfAddrMapConfigName.

Basically, an address map cannot be reused across different interfaces. Address
map entries contain addresses specific to an interface.

OK.

> Again, I would expect an SNMP error code...

This might be moot when the document is made independent of MIDCOM.

OK.

> sensitive and for what reason.

NAT configuration must be permitted only by an authorized SNMP application, as 
incorrect configuration could generate Denial of Service attacks on the
network. Monitoring the NAT sessiosn, BINDs and other statitics  shoudl not be
a cause for security alarm. The fear of unauthorized midcom agents effecting
the NAT resources is diminished once the MIB module is devoid of MIDCOM stuff.

> /js

Thanks, Juergen.

regards,
suresh

=====