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

From: Martin Stiemerling <[email-masked]>
Date: Tue, 05 Aug 2003 16:57:47 +0200

Hi Pyda,

| Had a chance to briefly review the draft. Overall, the draft seems well
| thought out and organized. I liked it. Below are my comments. Majority of
| the comments are centered on NAT middleboxes.

Thanks for reading the document and giving feedback!

|
| 1. I suggest, the document state upfront that the focus of the draft was
| principally TCP and UDP based applications ( I think, section 2.3.6 states
| this)

Yes, that's must since a lot of discussions are saying "what about protocol
xy". We will put this in the front of the document, perhaps with
a hint to the NAT MIB module.

|
| 2. Terminology - I found it confusing  with the terms "agent" and
| "session", especially, as juxtaposed to terms like "user agent" and "data
| session" in SP example. But, I believe, the authors were consitent
| throughout and refered the terms to mean "Midcom agent" and "Midcom
| session". It might be a good idea to state this upfront.

The terminology in the SIP examples could be indeed more precise. Will fix 
that.

|
| 3. Session control transactions (including SE, ST, AST & Middlebox
| capabilities transaction): I believe, these are middlebox function
| **independent** and the semantics may be uniformly enforced across
| varieties of middlebox devices.
|
| These are unlike the Policy rule transactions, which, I believe, are often
| middlebox function **dependent**. As such, the Middlebox
| function-independent transactions and middlebox function-dependent
| transactions need not be in the same transport session, so long as the
| authentcation/authorization information from one can be carried across
| the other. Further, midlebox-function-specific transactions need not
| confirm to an abstract/uniform transaction model. The sub-protocols that
| govern the resources of NAT or firewall may use different transaction
| models.

The general idea of the semantics is that all session, policy rule, and
policy rule groups transactions are transmitted in the same transport
session (whatever the transport is).

|
| While I dont beleieve, the document states anywhere that transactions for
| any any middlebx function should confirm to a unique model (or) that all
| transactions should occur within a specific MIDCOM session, it seemed to
| imply that. Perhaps, this is mainly to do with the way the draft is
| structured. If so, i would suggest that this be stated upfront so the
| model doesnt cloud the readers mind into thinking this as a requirement.

Yes, all transactions should occur within the specific MIDCOM session.
We will add a statement to clarify this.

|
| 4. Agent-unique-Ids vs Middlebox-unique-Ids
| I like the characterization. The examples are spread across the draft.
| Basically, I believe, agent-unique-Ids are transaction-IDs for the
| requests generated by the Agent and all the rest are middle-box-unique. I
| would suggest stating this during terms definitions.

Right.

|
| One other note. The middlebox can engage in sessions with several MIDCOM
| agents. To me, this mandate that the middlebox assign each of the agents
| it engges with a unique-agent-ID. This agent-id would in turn be used by
| the middlebox to track ownership of the resources and a means to contact
| the agents asynchronously. I believe, this needs to be included in the
| semantics draft (as part of the session control transactions).

It is in the section 2.1.7 "Peer identifiers". Perhaps the
heading is misleading and should be changed to "Agent identifier".
The bottom line of this section is that a middlebox must use
some sort of agent ID, but can use for instance the TCP socket ID.

|
| 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'.
|
| 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).
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?

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

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.

|
| 7. Ownership (NAT maps, binds):
| Say, a NAT address map is scoped out by multiple agents into multiple
| sub-rules. NAT middlebox will presumably assign a different group-ID for
| each of the sub-maps. Once a packet belongs to an address-map of an
| agent-specified group-id, NAT middlebox does not wait for the agent to
| setup all the follow-on construct like NAT BIND and nat session, right?
| In that case, I believe, the owning agent-id is transferred to the BINDs
| and sessions that NAT creates; but not the group-id, correct? I presume,
| it is safe to assume, ownership transfer is expected to occur from binds
| to sessions as well.

To be honestly, I do not understand the point. Could you elaborated it more?

|
| 8. Note, there shoudl be an ownership attribute in policy-rule request and
| response (Listed in section 4.1, but not specified on 2.3.7, 2.3.8).

2.3.7 and 2.3.8 specifiy the Policy Reserve Rule and Policy Enable Rule.
In section 4.1 the Status transactions are used, but not the reserve/enable
transactions. The ownership attribute is not required in reserve/enable
transactions since agents are only allowed to access their
policy rules/groups.

|
| 9. Section 2.3.7(PRR):
| PRR seems to be a construct meant specifically for NAT middleboxes. The
| disctinction between the two is apparently to do with when the lifetime
| clock starts ticking. Requring NAT middleboxes to maintain PRR seems
| needlessly complex. I would suggest doign away with the PRR construct.
| PER should suffice, so long as the agent can set the PER just as the
| construct is required.

PRR is required and requested by some vendors, since you can nail down
ports and IP address before you know anything else of your communcation
partner. Using only PER with wildcarding may results in some not needed
security risks, but is indeed requested by some people as well.
So with PRR you can request information about your external IP address and
port without opening anything in the NAT.

Thanks for doing this extensive review of the MIDCOM semantics Suresh.

Martin

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

---

From: "Pyda Srisuresh" <[email-masked]>
Date: Sat, 9 Aug 2003 22:37:28 -0700

Martin,

Sorry for the delay. Please see my comments inline.

<... stuff deleted>
> session (whatever the transport is).

OK.

> We will add a statement to clarify this.

OK.

> some sort of agent ID, but can use for instance the TCP socket ID.

OK. I am just looking for a statement that says that agent identifiers
must be middlebox unique.

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

> and is not aware about the actual NAT session (a binding could be

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.

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

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

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

> | sub-rules.

OK. I guess, I wasnt clear. Let me take an example.
Say, you have a NAPT map configured as "10.0.0.0/8 be mapped to address
142.29.48.20".
Say, you have two agents - agent-1 and agent-2. Say, both these agents
assign group-IDs to subsets of TCP/UDP ports as follows.

          Agent-1, group-1:  "10.1.0.0/16 mapped to
142.29.48.20:31001-32000"
          Agent-1, group-2:  "10.2.0.0/16 mapped to
142.29.48.20:32001-33000"
          Agent-2, group-3:  "10.3.0.0/16 mapped to
142.29.48.20:33001-34000"
          Agent-2, group-4:  "10.4.0.0/16 mapped to
142.29.48.20:34001-35000"

> |            NAT middlebox will presumably assign a different group-ID for

So, if a session was initiated from 10.3.0.1, NAT would (without
intervention from agent-2) setup a PORT-bind and nat-session.

> | and sessions that NAT creates; but not the group-id, correct? I presume,

In the above scenario, the PORT-BIND and session that NAT creates for the
session from 10.3.0.1 would inhert agent ownership (i.e., agent-2) from the
map, but not the group ID. This, I believe, is because group is
map/BIND/session-specific and cannot be inherited across resource object
types.

> | it is safe to assume, ownership transfer is expected to occur from binds
By the same token, when a BIND belongs to a Bind-group-id, the sessions that
use the BIND will inherit agent ownership from the BIND; but will not
inherit the Bind-group-id.

> To be honestly, I do not understand the point. Could you

Sorry, my oiginal text was not clear. Hope the above explanation helps.

> transactions since agents are only allowed to access their
                                                       ^^^^^
How will a middlebox know what is theirs if there isnt an agent ownership
assigned. I believe, an agent is instantiating its ownership on a middlebox
resource when the agent enables it.

> partner.

Perhaps I should restate what I said. I believe, you were using the term PRR
to reserve IP addresses/ports and the term PER to setup address/port BINDs.
I was suggesting to use a single term PER to ascertain ownership of NAT
address map entries, BIND entries and session entries.

>          Using only PER with wildcarding may results in some not needed

By PER with wild-carding, did you mean multiple BINDs? If so, why do you
believe, that would be a security risk?

> port without opening anything in the NAT.

Please see my above note.

> Thanks for doing this extensive review of the MIDCOM semantics Suresh.

No problem. Thank you for doing an extensive write up.

> Martin

regards,
suresh

---

From: Tom Taylor <[email-masked]>
Date: Tue, 12 Aug 2003 09:54:30 -0400

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.

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.

> Sorry for the delay. Please see my comments inline.
...

> manipulation based on group IDs and Owner-IDs can be part of "MIDCOM
...>

---

From: Pyda Srisuresh <[email-masked]>
Date: Sat, 16 Aug 2003 16:03:37 -0700 (PDT)

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

> lifetime expires, any session existing by virtue of that policy rule is

OK. However, the semantics document need to recognize the MaxIdleTime as a
parameter in itself and allow that to be set.

cheers,
suresh

> > manipulation based on group IDs and Owner-IDs can be part of "MIDCOM

=====

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 18 Aug 2003 14:06:17 +0200

Hi,

--On Saturday, August 09, 2003 22:37:28 -0700 Pyda Srisuresh 
<[email-masked]> wrote:
[...]
|> It is in the section 2.1.7 "Peer identifiers". Perhaps the
|> heading is misleading and should be changed to "Agent identifier".
|> The bottom line of this section is that a middlebox must use
|> some sort of agent ID, but can use for instance the TCP socket ID.
|
| OK. I am just looking for a statement that says that agent identifiers
| must be middlebox unique.

That statement is now in the text of section 2.1.7.

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

The goal was and is to keep the protocol itself quite simple and to enable 
MIDCOM
agent to get things working through middleboxes. For a management protocol
it would be clear that this session and binding configuration is needed.
The MIDCOM semantics focus on dynamic configuration.

[...]
|> 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".

How and where the lifetimes are maintained is not part of the protocol, 
since
MIDCOM is concered with the communication between agent and middlebox.
If the lifetimes are stored within the MIDCOM stack or within the actual
middlebox engine is more an operational or implementation issue.
For instace with the lifetime in MIDCOM stack approach you can extend
easily existing firewalls and NATs, without digging into the middlebox 
engine.

|
| BTW, What are your thoughts on the MaxIdletime attribute?

The MaxIdleTime needs to be considered by the implementation, but
not by the middlebox. The MIDCOM stack can watch the MaxIdleTime
and include it into its operational logic.

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

The identification can be part of the middlebox engine, but it must no be.
That depends on implementation and probably vendor's believe.

|
|> |
|> | 7. Ownership (NAT maps, binds):
|> | Say, a NAT address map is scoped out by multiple agents into multiple
|> | sub-rules.
|
| OK. I guess, I wasnt clear. Let me take an example.
| Say, you have a NAPT map configured as "10.0.0.0/8 be mapped to address
| 142.29.48.20".
| Say, you have two agents - agent-1 and agent-2. Say, both these agents
| assign group-IDs to subsets of TCP/UDP ports as follows.
|
|           Agent-1, group-1:  "10.1.0.0/16 mapped to
| 142.29.48.20:31001-32000"
|           Agent-1, group-2:  "10.2.0.0/16 mapped to
| 142.29.48.20:32001-33000"
|           Agent-2, group-3:  "10.3.0.0/16 mapped to
| 142.29.48.20:33001-34000"
|           Agent-2, group-4:  "10.4.0.0/16 mapped to
| 142.29.48.20:34001-35000"

Thanks, now is see the point. With the NAT MIB you can do these kind of
configuration at the NAT. But in the MIDCOM semantics the target is not
to configure complete sub-network mappings. The target is to enable
dedicated bindings for end hosts. The semantics talk about A0, A1, A2,
and A3. Whereas, A0 and A3 are the addresses' and ports of two endhosts. So 
the
configuration of the NAT would be:
Agent-1, group1, A0 mapped to A2, A0={IP Address, port(s)} A2={IP Address, 
port(s)}

So the goal is to create exactly for the combination of A0, A1, A2, and A3 a
binding and probably a session (and nail it down).
Sessions should be removed upon removal of the corresponding binding. 
Perhaps
we need to add text to the semantics to express that explicitly.

[...]
|
| Sorry, my oiginal text was not clear. Hope the above explanation helps.

Thanks, now I got it!

|
|> |
|> | 8. Note, there shoudl be an ownership attribute in policy-rule
|> request and
|> | response (Listed in section 4.1, but not specified on 2.3.7, 2.3.8).
|>
|> 2.3.7 and 2.3.8 specifiy the Policy Reserve Rule and Policy Enable Rule.
|> In section 4.1 the Status transactions are used, but not the
|> reserve/enable
|> transactions. The ownership attribute is not required in reserve/enable
|> transactions since agents are only allowed to access their
|                                                        ^^^^^
| How will a middlebox know what is theirs if there isnt an agent ownership
| assigned. I believe, an agent is instantiating its ownership on a
| middlebox resource when the agent enables it.

An agent becomes the owner of a middlebox resource when he enables it.
The agent can only manipulate policy rules with PRR and PER where he is the
owner. The middlebox must of course keep track of the ownership of a 
particular
policy rule internally.

|> |
|> | 9. Section 2.3.7(PRR):
|> | PRR seems to be a construct meant specifically for NAT middleboxes. The
|> | disctinction between the two is apparently to do with when the lifetime
|> | clock starts ticking. Requring NAT middleboxes to maintain PRR seems
|> | needlessly complex. I would suggest doign away with the PRR construct.
|> | PER should suffice, so long as the agent can set the PER just as the
|> | construct is required.
|>
|> PRR is required and requested by some vendors, since you can nail down
|> ports and IP address before you know anything else of your communcation
|> partner.
|
| Perhaps I should restate what I said. I believe, you were using the term
| PRR to reserve IP addresses/ports and the term PER to setup address/port
| BINDs. I was suggesting to use a single term PER to ascertain ownership
| of NAT address map entries, BIND entries and session entries.
|
|>          Using only PER with wildcarding may results in some not needed
|> security risks, but is indeed requested by some people as well.
|
| By PER with wild-carding, did you mean multiple BINDs? If so, why do you
| believe, that would be a security risk?

PER with wildcarding would result in one bind (A0 to A2). For combined
NAT and firewall this would result in: Allow everything from outside to A2 
(and
thus to A0). Some people see this as a security risk, since you open your 
firewall/NAT
wide for everybody. In some scenarios, like SIP early media, this wide open 
case
is explicitly needed, since it is not known from where the first data is 
coming.

Cheers
Martin

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 22 Aug 2003 23:17:26 -0700 (PDT)

> That statement is now in the text of section 2.1.7.
OK. Sounds good.

> The MIDCOM semantics focus on dynamic configuration.
OK. Sounds like, we are in synch. I.e., the agent is able to set NAT bindings
as well as NAT sessions, right?

> easily existing firewalls and NATs, without digging into the middlebox 
I agree, this is an implementation issue. We can move on.

> not by the middlebox. 

Meaning? NAT middlebox uses this extensively.

>                       The MIDCOM stack can watch the MaxIdleTime

The Midcom logic Shoudl be able to both watch and set the MaxIdleTime.
Several ALGs, including the DNS-ALG use this attribute.

> That depends on implementation and probably vendor's believe.
I am not parsing what you say. I assume what you saying is that you dont care 
how it is implemented.

> | Say, you have a NAPT map configured as "10.0.0.0/8 be mapped to address

Well, what I am trying to say here is a Midcom agent can own a map resource,
NAT coudl still derive BINDs and sessions out of the address map the midcom
agent owns. The BINDs and sessions generated by NAT will still retain the agent
as the owner. Midcom agent is not necessarily required to  create all the BINDs
and sessions it owns. It could. But, not a requirement.

> is explicitly needed, since it is not known from where the first data is 
OK, I understand. PERs that are not session specific (ex; BINDs) are
wild-cards. While they can be security risks, that neednt be the case. Anyways,
something tell me we are not seeing things eye to eye here.

Do you see a problem with using a single PER term to ascertain ownership
of NAT address map entries, BIND entries and session entries. Thanks.

cheers,
suresh

=====