Subject: RE: (NAT) draft-ietf-nat-natmib-00.txt

From: Randy Turner <[email-masked]>
Date: Wed, 21 Mar 2001 12:52:51 -0800

I guess I'm calling into question the primary assumption. There's no way to
properly NAT VPN tunnels without GRE or ESP support, and telecommuting is a
very large market. The support mailing lists for Linksys, Netgear, 3Com, and
our own were burning up with activity until we supported the capability for
VPN "pass-through" mode for both PPTP and IPSEC. There are other IP
protocols around the corner for which I would think this MIB would want to
be extensible as well. I would say without a clear path to other IP protocol
extensibility, this MIB will be obsolete in a very near time frame. I'm
trying to avoid this, since some good work can be reused here, without (in
my opinion) alot of extra complexity.

Randy

-----Original Message-----
From: Pyda Srisuresh [mailto:[email-masked]]
Sent: Wednesday, March 21, 2001 12:45 PM
To: Randy Turner; 'Rajiv Raghunarayan '
Cc: 'NAT-WG '
Subject: RE: (NAT) draft-ietf-nat-natmib-00.txt

Randy,

I agree with the authors about the complexity this brings in.
The primary assumption behind NAT deployments is that the NAT 
users are predominantly focussed on client-server type TCP/UDP 
applications. Given this, I suggest staying focussed on just 
these two protocols (TCP and UDP).

As for GRE tunnels working in conjunction with NAT, there is 
no draft covering this. I would not suggest extending the NAT MIB 
draft, until we have a draft covering GRE support with NAT.

As for ESP, are you suggesting to add this support because RSIP 
clients ask for this? If so, I would once again not recommend 
going down this path because RSIP is an experimental protocol.

cheers,
suresh

--- Randy Turner <[email-masked]> wrote:
>  
> Hi Rajiv,
> 
> To be honest, I haven't exhaustively analyzed ways to implement the
> extensibility I am suggesting. The method that I mentioned is just "off
the
> top of my head". Since I needed a way to basically do a relational
> normalization to separate out IP protocol-specific information, this just
> seemed an obvious way to do it. I think if someone wanted to add support
for
> another IP protocol, it would be more or less obvious how to do this.
> 
> I think it's more important that the MIB be extensible with regards to
other
> IP protocols, and secondarily, we need a relatively straightforward way to
> do this. Right now, we have to arbitrarily add fields to one aggregate
> structure, and when we add support for things like GRE or ESP, it gets a
> little muddled. However, it does keep the number of groups necessary to
> create a NAT mapping to a small number.
> 
> I still think we need a way to split out IP-protocol-specific information
> that is necessary to maintain NAT session state. NAT session information
> that is common to all IP protocols could still be maintained in a single
> table. I welcome yours and other comments on the best way to achieve this.
> As a comparison, we might want to look at the current MIB proposal, and
see
> what it would look like when we add support for GRE and ESP, just to
> illustrate the less than desirable aggregation I mentioned above.
> 
> I will think about your alternate proposal (suggested in your previous
> email) today, and provide comments.
> 
> Randy
> 
> -----Original Message-----
> From: Rajiv Raghunarayan
> To: Randy Turner
> Cc: NAT-WG
> Sent: 3/20/01 4:46 AM
> Subject: Re: (NAT) draft-ietf-nat-natmib-00.txt
> 
> Hi Randy,
> 
> Well by complicated, I actually meant that the number of entries
> in quite a few tables would increase (by an amount equivalent to
> the number of protocols employing NAT).
> 
> To expand, let's assume that we need to configure NAT for all 
> possible protocols using NAT. In the current scenario, one would 
> 
> o Configure one entry in the natConfTable
> o Configure one entry in the natConfStaticAddrMapTable (assuming
>   static configuration).
> 
> Now, in a modified scenario, if one needs to configure NAT, they 
> would
> 
> o Configure the natConfTable i.e. add as many entries as the
>   number of protocols
> o Configure as many entries in the natConfStaticAddrMapTable
>   as the number of protocols (since the natConfName happens
>   to be one of the indices into this table).
> o Configure the respective protocol tables to hold these 
>   entries.
> 
> Now this has a ripple effect
> 
> A. it increases the number of entries in the natConfTable
> B. it increases the number of entries in the natConf*AddrMapTables
> C. it increases the number of entries in the nat*BindTables
>    (since they hold a reference to the natConfName used in creating
>    the BIND).
> D. it increases the number of entries in the Session table
>    (since sessions are associated with BINDS).
> E. Number of entries in most stats table would also increase
>    accordingly.
> 
> This is what I meant when I said that things would get a little
> complicated. But, this does not mean that I disagree with the
> extensibility part you've specifed - just that I wanted to try and
> keep the increase in entries as low as possible without compromising 
> on the flexibility/extensibility part.
> 
> One thing that I feel we could do is define another intermediate
> table (say natProtSpecificConfTable) consisting of <id> (some 
> index element), <protocol> (a pointer to the protocol-specific 
> conf. table, same as the one you've suggested in the natConfTable), 
> and <prot-index> (an index into the protocol-specific table). Both 
> 'id' and 'protocol' are index elements for natProtSpecificConfTable.
> 
> In the natConfTable one could add index element natProtSpecificConfIdx
> (and index into the natProtSpecificConfTable, which maps to 'id').
> This is in lieu of the two elements, protocol and prot-id. We could 
> then reference the protocol specific tables (for protocol specific 
> information) using 'natProtSpecificConfIdx' (via the 
> natProtSpecificConfTable).
> 
> This way we do get in the required extensibility, of course by
> adding a little bit of complexity.
> 
> What do you think??
> 
> Thanks,
> Rajiv.
> 
> Randy Turner wrote:
> > 
> > 
> > Can you give an example of how complicated this might get when we have
> one
> > row per IP protocol ? We would have to weigh however complicated this
> might
> > get against aggregating all information into one row...
> > 
> > Thanks,
> > Randy
> > 
> > -----Original Message-----
> > From: Rajiv Raghunarayan
> > To: Randy Turner
> > Cc: 'NAT-WG '
> > Sent: 3/19/01 6:18 AM
> > Subject: Re: (NAT) draft-ietf-nat-natmib-00.txt
> > 
> > Randy,
> > 
> > There's one small difference I notice in what you're suggesting
> > and the way the current architecture attends to the configuration.
> > To be more explicit, in the current arch. we can specify one row
> > of info all protocols e.g. tcp, udp etc. (in the natConfTable).
> > While in case of the suggested approach, we'll need to have one
> > row for each protocol i.e. ip-protocol specifying the protocol
> > and ip-prot-index the index into the protocol table. This would
> > necessitate in having multiple entries (per protocol) not only in
> > the natConfTable, but also correspondingly in the nat*AddrMap
> > tables (since they an extension of the natConfTable). I think it
> > would complicate things a bit here..
> > 
> > Off hand, one thing that I think we could do is to define ip-protocol
> > as a bit-field consisting of all protocols that need to be supported
> > i.e. tcp, udp, icmp etc., and have an ip-prot-index pointing into
> > each of these tables (as in the case above). One problem with this
> > approach is that addition of new protocol tables would require
> > addition of new flags/bits into the bit-field.
> > 
> > What do you think??
> > 
> > -Rajiv.
> > 
> > Randy Turner wrote:
> > >
> > >
> > >
> > > I think the initial version of the MIB could contain the majority of
> > IP
> > > protocol tables that we are likely to see in the NAT world, and if
> we
> > left
> > > out one or two, the path to extensibility would be very clear. These
> > initial
> > > tables would include support for TCP, UDP, ICMP, GRE, and maybe ESP.
> > >
> > > Randy
> > >
> > > -----Original Message-----
> > > From: Rajiv Raghunarayan
> > > To: Randy Turner
> > > Cc: NAT-WG
> > > Sent: 3/19/01 5:29 AM
> > > Subject: Re: (NAT) draft-ietf-nat-natmib-00.txt
> > >
> > > Hi Randy,
> > >
> > > I do think your approach sounds pretty reasonable - my only
> > > concern is the number of tables that we may end up having (more
> > > the number of protocols using NAT, more the number of tables!!),
> > > and where/when should these tables be added is one more thing to
> > > be addressed (which I believe should not be a big issue).
> > >
> > > Having said that, I still think your idea makes the MIB pretty
> > > flexible.
> > >
> > > Also CCing the NAT-WG for inputs, if any.
> > >
> > > -Rajiv.
> > >
> > > Randy Turner wrote:
> > > >
> > > >
> > > > Basically, each IP protocol uses different information to maintain
> a
> > > NAT
> > > > "session", like TCP and UDP use src/dst IP address and port number
> > > > information.
> > > >
> > > > ICMP NAT looks at src/dst IP, and ICMP transaction info, subtype,
> > and
> > > code,
> > > > etc.
> > > >
> > > > IPSEC ESP uses other types of information (not port numbers).
> > > >
> > > > I think it would be easier to have the MIB be extended/augmented
> by
> > > the
> > > > addition of new IP protocol types, *if* there was a separate table
> > of
> > > NAT
> > > > sessions for each type IP protocol. Having an "ip-protocol" object
> > > would let
> > > > you know which table to index, and the "ipProtIndex" would be an
> > index
> > > into
> > > > the table for a particular NAT session.
> > > >
> > > > The global NAT session table would include these two objects
> "table"
> > > and
> > > > "tableindex" to allow a manager to drill down to find out details
> of
> > > the
> > > > particular NAT session, from a transport perspective. Note that
> NAT
> > > session
> > > > information that is common to all IP protocols (like session
> timers,
> > > src &
> > > > dest IP, etc. ) would still exist in the global session table
> since
> > > there's
> > > > no need to replicate it.
> > > >
> > > > Does this sound reasonable?
> > > >
> > > > Randy
> > > >
> > > > -----Original Message-----
> > > > From: Rajiv Raghunarayan
> > > > To: Randy Turner
> > > > Sent: 3/17/01 6:07 AM
> > > > Subject: Re: (NAT) draft-ietf-nat-natmib-00.txt
> > > >
> > > > Hi Randy,
> > > >
> > > > Thanks for reviewing the MIB. I have a small query regarding your
> > > > suggestion (rather it's more of a clarification).
> > > >
> > > > Are you suggesting that we replace all the timeout parameters
> > > > in the natConfTable with 'ipProtocol' and 'ipProtocolIndex',
> > > > where ipProtocol is a pointer to a table of protocol specific
> > > > information, while ipProtocolIndex is an index into an entry of
> > > > that table. I certainly seem to agree with you idea separating
> > > > the protocol specific info from NAT, but that would entail
> > > > adding procotol specific tables to maintain the same, and we
> > > > may end up having lots of tables (depending on the quirks of
> > > > individual protocols). Unfortunately, I'm not completely aware
> > > > of the requirements of all protocols (as far as NAT is concerned),
> > > > and hence cannot immediately judge if we could come up with a
> > > > set of common information (which can be later extended by all
> > > > protocols as and when necessary).
> > > >
> > > > Do let me know your thoughts/opinions - I'm sure we could come
> > > > up with something that's extensible and simple.
> > > >
> > > > Thanks,
> > > > Rajiv.
> > > >
> > > > Randy Turner wrote:
> > > > >
> > > > > Hi Rajiv,
> > > > >
> > > > > Looking at the MIB, I think there should be a way to "table" ip
> > > > protocols
> > > > > that can be NAT'd. What I mean by this, is that you currently
> have
> > > > static
> > > > > fields in the NatConfEntry structure for TCP, UDP, and ICMP. In
> > > order
> > > > to
> > > > > make this extensible, you might have a field called "ipProtocol"
> > and
> > > > > "ipProtocolIndex". We would then be able to define a table of
> > > > > IP-protocol-specific information that is required to properly
> NAT
> > a
> > > > > particular IP protocol. Of course, for TCP and UDP, these
> entries
> > > > could
> > > > > point to the same type of table that uses IP addresses and the
> > > notion
> > > > of
> > > > > "port numbers". However, for other protocols like GRE, 6to4, and
> > > > others,
> > > > > they would have their own table definitions that contain columns
> > > that
> > > > > describe fields that are required to NAT this particular IP
> > > protocol.
> > > > >
> > > > > Is this something you have thought about?
> > > > >
> > > > > Randy
> > > > >
> > > > > -----Original Message-----
> > > > > From: Rajiv Raghunarayan [mailto:[email-masked]]
> > > > > Sent: Thursday, March 15, 2001 6:26 AM
> > > > > To: NAT-WG
> > > > > Subject: (NAT) draft-ietf-nat-natmib-00.txt
> > > > >
> > > > > Hello Folks,
> > > > >
> > > > > We have recently submitted a draft on NAT MIB, which can be
> > > > > accessed at
> > > > > http://www.ietf.org/internet-drafts/draft-ietf-nat-natmib-00.txt
> > > > >
> > > > > We would appreciate your feedback/comments/questions on it, so
> we
> > > > > can work on improving it, as may be necessary.
> > > > >
> > > > > Thanks and Regards,
> > > > > Rajiv.
> > > > > -
> > > > > To unsubscribe, email [email-masked]' with
> > > > > 'unsubscribe nat' in the body of the message.
> > > > > List archive: <URL:http://www.portmasters.com/archives/>
> -
> To unsubscribe, email [email-masked]' with
> 'unsubscribe nat' in the body of the message.
> List archive: <URL:http://www.portmasters.com/archives/>

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.
List archive: <URL:http://www.portmasters.com/archives/>

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 21 Mar 2001 15:22:20 -0800 (PST)

I belive, it would be useful to see the PPTP, IPsec and GRE pass-through 
modes documented in a draft first. I dont believe, we want to make the 
MIB complex with a protocol table for extensibility for every IP 
protocol. 

On a different note, some folks in the WG meeting expressed interest
in having MIB parameters defined for ALG extensions (ex: FTP-ALG, 
DNS-ALG etc.)

Any thoughts/comments from others in the list on 
             (a) MIB extensions for IP protocols, 
             (b) MIB extensions for ALGs
Should they be done in the preliminary MIB draft (or)
should they be done in a follow-on extensions draft?

Thanks.

cheers,
suresh

> > List archive: <URL:http://www.portmasters.com/archives/>

=====