Subject: [midcom] More on the NAT MIB document

From: Melinda Shore <[email-masked]>
Date: Thu, 05 Sep 2002 18:32:35 -0400

They're trying to get draft-ietf-nat-natmib-04.txt wrapped
up for publication, so it would be helpful if comments could
get in pretty quickly.  Please try to give the document a
review before next Wednesday, 11 September.

Thanks,

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

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 11 Sep 2002 16:27:28 +0200

Melinda,

Here are my comments on the NAT MIB:

==========================================
General comment (from MIDCOM perspective):
==========================================

It appears that if SNMP would be selected as MIDCOM
protocol, we could completely re-use the NAT MIB and
just add one or two tables and a few objects for
having a MIDCOM MIB. However, the functionality of
the NAT MIB is probably more than MIDCOM requires.
Missing functionality includes grouping of bindings
and port oddity requests.

==========================
MIB objects and semantics:
==========================

- The NatConfAddrMapEntry of the NatConfAddrMapTable is missing
  an object for requesting specific oddity of port numbers
  provided by the NAT. Reference: MIDCOM requirement described
  in section 2.2.9 of RFC 3304.

- In the NatAddrBindTable a local address, a gloabal address,
  and a direction can be specified. However, the managed object
  natAddrBindDirection has a value of either 'uniDirectional' or
  'biDirectional'. This does not appear to be sufficient in the
  unidirectional case, because you do not know whether it is
  inbound or outbound. I would suggest to use 'inbound',
  'outbound', and 'biDirectional' as set of allowed values for
  this object.

- The same applies to NatAddrPortBindTable.

- A related issue is object natSessionDirection: Why is there
  no support for bi-diractional sessions?

- I would suggest adding another object to the NatAddrBindEntry
  specifying the origin (or creator) of the entry. This can be
  done very general {SNMP, CLI, other protcol} or it can be
  an authenticated (SNMP) user ID.

- The same applies to NatAddrPortBindTable.

- I wonder why NatAddrBindTable and NatAddrPortBindTable
  are different tables. A single table should be sufficient
  for serving both purposes. Most objects are the same in both
  tables and another object acting as a flag for distinguishing
  AddrBindings and AddrPortBindings should be sufficient.

===========
SMI syntax:
===========

There is a missing comma in definition of natConfProtGroup
just after object natConfProtConfigName.

=========
Phrasing:
=========

In the description of object natAddrBindAddrMapName I would
replace "the Management System" by "an SNMP manager".

    Juergen
-- 
Juergen Quittek     [email-masked]     Tel: +49 6221 90511-15
NEC Europe Ltd.,    Network Laboratories     Fax: +49 6221 90511-55
Adenauerplatz 6, 69115 Heidelberg, Germany   http://www.ccrle.nec.de

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 13 Sep 2002 20:17:52 -0700 (PDT)

Juergen,

Thanks very much for your detailed comments. 

NAT MIB functioanlity was meant principally for configuring the NAT 
devices - Not as a MIDCOM protocol per se. 
However, as you noticed, the NAT MIB may be meeting the MIDCOM 
protocol requirements for a NAT Middlebox.

Please see my specific responses below.

regards,
sures

> Here are my comments on the NAT MIB:
The odditt requirement is covered by the fact that a static port map range
can be defined. Please refer the mapping fields - 
    (natConfLocalPortFrom, natConfLocalPortTo) -->  
              (natConfGlobalAddrFrom, natConfGlobalPortto)        

>   'outbound', and 'biDirectional' as set of allowed values for

BIND itself has to be derived from the address map and the associated
direction specific in the address map. Please refer the description,
which I reproduced below for your convenience.
            
            "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."

> - The same applies to NatAddrPortBindTable.
Please see the explanation above.

>   no support for bi-diractional sessions?

Every session traversing a NAT device has a session direction. It has
to be inbound or outbound - not both, right.

>   an authenticated (SNMP) user ID.

What did you mean by the origin - The address map the BIND refers to
(or) the session that triggered this.
If you meant the first, it exists already - natAddrBindAddrMapName.

As for the second, sessions are fleeting and could have disappeared
even as the BIND remained. So, I dont believe, it wouldnt be right to keep
reference to the session in BIND.
> - The same applies to NatAddrPortBindTable.
Please see the comment above.

>   AddrBindings and AddrPortBindings should be sufficient.

Makes sense to me. However, I will let my co-authors comment on this.
Got it. Thanks.

> replace "the Management System" by "an SNMP manager".

Will do. 
>     Juergen

=====

__________________________________________________
Do you Yahoo!?
Yahoo! News - Today's headlines
http://news.yahoo.com
_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 16 Sep 2002 18:38:01 +0200

Hi Pyda,

First of all, I think you did a great job in defining this MIB.
It appears to be very mature and to cover all requirements.

However, some more text explaining the MIB might be helpful.
For example, the operational model of the natConfAddrMapTable
is not explained in detail: how to create an entry (and set up
the corresponding binding) using natConfProtRowStatus or
how to configura all required entries for a single TCP
connection.

But things like these can be added in a later version of
the MIB document when implementations are available and
a progress in standardization status is ahead.

Please see some more comments inline.

    Juergen

>               (natConfGlobalAddrFrom, natConfGlobalPortto)

OK, so if you want fixed port oddity, you have to select the port
numbers yourself, and you cannot use dynamic assignment.

>              which this bind is formed."

I see. But unfortunately, I do not fully understand.
Could you comment on possible combinations of {inbound, outbound, both}
maps and {uni-dir, bi-dir} bindings?

> to be inbound or outbound - not both, right.

So this is the direction of session creation and not necessarily
related to the directions of the corresponding map and/or binding?

> reference to the session in BIND.

Sorry, I referred to the wrong table. I wanted to refer to the
natConfAddrMapTable, not to the natAddrBindTable. My point is, that
it might be useful to know, whether an entry was created by an SNMP
manager, at the CLI, or by a configuraton file, ...

>> replace "the Management System" by "an SNMP manager".

Sorry about this. I already found that this comment
of mine was nonsense. "management station" is the proper term.

    Juergen

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 16 Sep 2002 23:31:22 -0700 (PDT)

> It appears to be very mature and to cover all requirements.

Thanks. It has been a team effort.
> how to configura all required entries for a single TCP
No problem.

> Please see some more comments inline.
Thanks, Juergen. My responses below.

regards,
suresh

> numbers yourself, and you cannot use dynamic assignment.

Actually, I misstated this in my previouss e-mail.
Specifying static port maps in the AddressMap Table is a way. But, that 
would be a poor way to do. However, specifying the above through
NatAddrPortBindEntry would be the right way to do. For example, the 
external agent could add two PortBind entires - one after the other.
Extending NatAddrPortBindEntry to specify port range (i.e., PortFrom 
and PortTo), instead of a single port would be another way to do this.
But, I believe, the current approach of making two entries with 
NatAddrPortBindEntry as it stands would be adequate.

> maps and {uni-dir, bi-dir} bindings?

Well, a BIND may be derived by NAT, based on the sessions noticed in
the ingress direction, Egress direction or both. ex: You could generate 
a BIND for a bi-directional NAT by looking up the address maps for 
sessions in either direction. Whereas, you would create and reuse the
BINDS only for outbound sessions with a traditional NAT. Hope this helps.

> related to the directions of the corresponding map and/or binding?

Yes.

> manager, at the CLI, or by a configuraton file, ...

Well, address maps are not changed frequently. Usually, they are set 
just once for the box. BINDs, on the other hand, may be created dynamically,
either by the NAT (based on address maps), or by SNMP mgmt application
or by CLI. So, you original query was fine. However, this is a tricky 
item. Where do you stop the line? Wouldnt you wish to further identify which
specific application usign the MGMT application set this etc.. I think,
it is best to keep this information on the SNMP application side rather
than in the MIB.

=====

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 17 Sep 2002 12:03:48 +0200

Hi Nalin,

-- Nalin Pai wrote on 17 September 2002 12:37 +0530:

> Thanks Juergen, for your comments.
>
> I think most of the issues you raised have/are been/being addressed
> by Suresh, except this one.
>
> Yes on first glance, both tables seem to be similar, however if
> you notice the indices for the 2 tables are different.
>
> For natAddrBindTable, they are
> INDEX   { natAddrBindLocalAddrType, natAddrBindLocalAddr }
>
> For natAddrPortBindTable, they are
> INDEX   { natAddrPortBindLocalAddrType, natAddrPortBindLocalAddr,
>           natAddrPortBindLocalPort, natAddrPortBindProtocol }
>
> The different indexing schemes makes it difficult (impossible?)
> to merge the two tables into one.

Thank you for this clarification. Now I understand.

> So to summarize the comments (so far) that will be addressed in the
> next draft.
>
> 1) There is a missing comma in definition of natConfProtGroup
> 2) However, some more text explaining the MIB might be helpful.

I have a further comment concerning the operational model.
I am missing clear statements about the relations
between map table, bind tables and session table, such as
   - Can I create a bind entry without having a corresponding map entry?
   - What are further entity relationships of entries in these tables?
   - May I create a session entry with a single bind ID first and later
     add a second one? If yes, how to do so?

And a very minor last comment:
In the NAT-TC module you can omit the line
    ::= { mib-2 xx } -- to be assigned by RFC-editor
because you are not defining any object within the module.
Then also the import of mib-2 is not needed.

    Juergen

> Thanks once again,
> Nalin
> Pyda Srisuresh wrote:
> Nalinaksh Pai
> Software Engineer
> Cisco Systems
> Phone: 91-080-5321300 Ext: 6354
> Email: [email-masked]
> Epage: [email-masked]

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 17 Sep 2002 12:03:30 +0200

Hi Pyda,

> Thanks. It has been a team effort.

Yes, of course. I intended to address all of you.

> would be a poor way to do. However, specifying the above throu gh

Now I understand.

> NatAddrPortBindEntry as it stands would be adequate.

Agreed.

> BINDS only for outbound sessions with a traditional NAT. Hope this helps.

Yes, it helps. I think I was lacking clear statements about the relations
between map table, bind tables and session table.

> it is best to keep this information on the SNMP application side rather

I agree that there is no strong requirement in doing so. However, for both
tables a management might like to know about the origin of an entry,
particularly whether it was created by the station itself or whether someone
else did so, for example at the command line, or via another NAT configuration
protocol.

Furthermore, since SNMPv1 and v2c are on their way to become "historic" you
can assume having a notion of an (authenticated?) user in SNMPv3 agents.

    Juergen

---

From: Nalin Pai <[email-masked]>
Date: Tue, 17 Sep 2002 17:05:28 +0530

Hi Juergen,

>      add a second one? If yes, how to do so?

OK, we will clarify such relations in the MIB.

> Then also the import of mib-2 is not needed.

Will look into this.

Thanks,
Nalin

---

From: Nalin Pai <[email-masked]>
Date: Tue, 17 Sep 2002 12:37:18 +0530

Thanks once again,
Nalin

-- 

Nalinaksh Pai
Software Engineer
Cisco Systems