Subject: RE: [midcom] Re: Comments on the Semantics draft (draft-ietf-midcom-semantics-03.txt)

From: "Harrington, David" <[email-masked]>
Date: Wed, 20 Aug 2003 14:46:09 -0400

Hi,

I cannot locate a current copy of the NAT MIB. Did the I-D expire? Did
it ever move to an RFC?

dbh

> -----Original Message-----
> From: Pyda Srisuresh [mailto:[email-masked]] 
> Sent: Saturday, August 16, 2003 7:04 PM
> To: Tom Taylor
> Cc: Martin Stiemerling; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: [midcom] Re: Comments on the Semantics draft 
> (draft-ietf-midcom-semantics-03.txt)
> 
> 
> 
> --- Tom Taylor <[email-masked]> wrote:
> > I don't think MIDCOM is about control of NAT sessions, in 
> your terminology. 
> > MIDCOM 
> > installs BINDs and maps, and the NAT enables sessions 
> within that framework.
> > 
> It would be nice, if that was so. But, that is not the case. 
> There are several
> deployments of symmetric NAPT devices that use different 
> BINDings for the same
> (address,port) while connecting to different sessions.
> 
> > As for the distinction between rule lifetime and 
> maxIdleTime, let me make
> > this proposal:
> >   - NATs can continue to enforce maxIdleTime, if this is 
> seen as an effective
> > means 
> > of resource conservation
> >   - however, the policy introduced by policy rule lifetime 
> overrides: when
> > the 
> > lifetime expires, any session existing by virtue of that 
> policy rule is
> > terminated.
> > 
> 
> OK. However, the semantics document need to recognize the 
> MaxIdleTime as a
> parameter in itself and allow that to be set.
> 
> cheers,
> suresh
> 
> > Pyda Srisuresh wrote:
> > 
> > > Martin,
> > > 
> > > Sorry for the delay. Please see my comments inline.
> > > 
> > > <... stuff deleted>
> > ...
> > 
> > > 
> > > 
> > >>|
> > >>| 5. Policy rule: The definition says, this shoudl be 
> (condition+Action).
> > >>| However, I had seen several instances where a NAT-BIND 
> is referred as a
> > >>| Policy rule. Sounds like, you were using a single policy-rule
> > >>abstract to
> > >>| refer to several middlebox entities. It woudl help to 
> state the abstract
> > >>| type you are refering to in the rule. ex: map, BIND, 
> session etc.
> > >>
> > >>OK, I see the point. Indeed we refer in the policy rule 
> to a construct
> > >>that may consists out of NAT-BIND and firewall rules. So 
> the policy rule
> > >>is meant as an 'umbrella'.
> > > 
> > > 
> > > In that case, you might want to define a 
> "transaction-entity", which is an
> > > abstract construct that would refer to any middlebox 
> resource that may be
> > > dynamically controlled/monitored via the midcom protocol.
> > > 
> > > 
> > >>|
> > >>| I believe, a NAT-BIND constitutes an action; NAT address map
> > >>constitutes a
> > >>| condition (along with an implicit static/dynamic BIND action);
> > >>and, a NAT
> > >>| session, identified by its inside and outside session 
> tuples (alogn with
> > >>| the BINDs) will constitute a rule.
> > >>|
> > >>| 6. Section 2.3.1 - Configuration transactions
> > >>| a) You mention NAT bindings. But, there is no mention of NAT
> > >>sessions. For
> > >>| example, multiple NAPT sessions using beargn the same source-IP,
> > >>| Source-port might use different PORT bindings or the 
> same PORT binding.
> > >>| This is essentially the difference between symmetric 
> NAT and cone NAT.
> > >>| One permits p2p NAT sessiosn and the other doesnt. In 
> essence, NAT
> > >>| binding and NAT session must be treated as independent 
> controllable
> > >>| entities.
> > >>
> > >>I see the point, that for a single NAT binding several 
> NAT sessions may
> > >>run at the same time. And I see the point that these two 
> have to be
> > >>differentiated. The MIDCOM protocol does only configure 
> NAT bindings
> > >>and is not aware about the actual NAT session (a binding could be
> > >>configured by not used).
> > > 
> > > 
> > > Right. What I am saying is that the MIDCOM protocol ought 
> to be aware of
> > > "NAT session" construct in addition to "NAT binding". 
> This is because,
> > there
> > > could be instances where setting a NAT binding is 
> adequate (ex: basic NAT
> > > and p2p-NAT). Other times, the agent might need to setup 
> individual NAT
> > > sessions.
> > > 
> > > 
> > >>By now I don't see the impact on the semantics. It is 
> just a problem
> > >>of mentioning that there are NAT sessions or even more?
> > >>
> > > 
> > > The impact is to add an additional construct for "NAT 
> session" into the
> > > semantics.
> > > 
> > > I also had a question (later on below) about setting 
> ownership on a NAT map
> > > entry. This would, in turn, call for a new construct for 
> "NAT map" in the
> > > semantics.
> > > 
> > > 
> > >>|
> > >>| b) You mention lifetime of a rule. Typically, NAT 
> devices (that include
> > >>| an ALG) do not have this attribute. They have a MaxIdletime for
> > >>BINDs and
> > >>| sessions. Agents will want to set the MaxIdletime for a resource
> > >>| (NAT-BIND or NAT-session). The lifetime attribute is 
> new and may be a
> > >>| fine thing to add to NAT maps, binds and sessions. This 
> will ensure that
> > >>| agent imposed entities disappear after the specified 
> time. But, there is
> > >>| a dependency graph here. lifetiem of a nat map must be 
> greater than (or
> > >>| equal to) the lifetime of the nat binds and nat 
> sessions, it generates.
> > >>| Further, lifetime of a nat bind must be greater than 
> (or equal to) the
> > >>| lifetime of the sessions associated with the BIND.
> > >>
> > >>The lifetime attribute must neither be added to the NAT 
> engine nor to the
> > >>firewall engine, but it could. This lifetime attribute 
> can be kept in the
> > >>MIDCOM stack, and the stack must take about all other timers, e.g.
> > >>the nat bind time must be greater or equal to the policy 
> rule lifetime.
> > >>
> > > 
> > > 
> > > The MIDCOM stack you are refering to on a middlebox is 
> merely a MIDCOM
> > > specific extension module that manipulates the middlebox 
> resource objects,
> > > right. Given that these objects are quite granular and an 
> intrinsic part of
> > > NAT and firewall engines, how do you suppose the lifetime 
> timers for these
> > > objects can be maintained in an independent module away 
> from the NAT and
> > > firewall engines? I would think, the natural thing would 
> be to associate
> > the
> > > timer attribute as part of the NAT/Firewall objects, and 
> specify the timer
> > > routines that process the timeouts as part of "MIDCOM 
> extension module".
> > > 
> > > BTW, What are your thoughts on the MaxIdletime attribute?
> > > 
> > > 
> > >>There are some functions of MIDCOM that must not be 
> necessary supported
> > >>by the middlebox engines, like grouping firewall rules 
> and NAT bindings
> > >>into a single policy rule. This applies to the lifetimers 
> as well. These
> > >>functions may be only implemented in the MIDCOM stack.
> > >>
> > > 
> > > 
> > > Once again, I believe, group-ID and Owner-Id attributes 
> will need to be
> > > associated with the individual NAT/firewall objects. 
> Routines that do the
> > > manipulation based on group IDs and Owner-IDs can be part 
> of "MIDCOM
> > > extension module".
> > > 
> > > 
> > ...>
> > 
> 
> 
> =====
> 
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/midcom
> 

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

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 20 Aug 2003 20:36:52 -0700 (PDT)

Well, it clearly is dated (supposed to have expired in 05/03). I was able to
get the draft with the followign URL, however.
http://www.ietf.org/internet-drafts/draft-ietf-nat-natmib-05.txt

The new draft (rev 6) should be out in a couple of days. 

regards,
suresh

=====