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

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 27 Jul 2003 22:55:01 -0700 (PDT)

Martin, Juergen and Tom,

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.

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)

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.

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.

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.

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. 

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

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.

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. 

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.

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. 

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

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.

Thats all for now.

cheers,
suresh

=====

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