Subject: [midcom] Semantics Discussion Points

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 18 Jul 2002 10:17:30 -0400

The charts I presented on open issues in defining the semantics will
undoubtedly appear at some point with the minutes.  In the meantime, their
contents are reproduced here.  I should say that many of these points
represent attempts to better understand the requirements.  Comments on the
various points are welcome.

1. Takeover

Takeover = ability for one Agent to operate on rules established by another
Is it really required?
What granularity?  Per rule?  Per session?
Should the protocol have a formal handoff procedure? 
Note that in the case of an Agent crash this can't be done but takeover
capability is desirable anyway.

2. "Deterministic Outcome"

It can be argued that Middlebox behaviour will be deterministic only in the
eyes of the administrator.
Is it agreed that this is the only condition the protocol must satisfy to
meet requirement 2.1.12?

3. Meaning of End Of Session

Do rules continue to survive to the end of their lifetime?

4. Groups

Must it be possible to form groups on an ad hoc basis after the rules have
been defined, or can rules be assigned to groups from the start?
Will there ever be a requirement to move a rule from one group to another?
Is destroy-create an adequate substitute if there is such a requirement?
Group timeout needed?

5. Port Parity

Would there ever be a case where you would want to map an odd port to an
even one or vice versa?

6. Is Deny Required?

Is there a real example where MIDCOM needs to install a blocking rule?

7. Multiple Filter Conditions

A group of policy rules is equivalent to testing packets against Rule 1 OR
Rule 2 OR ...
Is AND capability required?
Probably not -- can express the conjunction of filters as a simple filter
itself.
Conclusion: no point in multiple filter conditions in the same policy rule.

8. Query Capability

Is the requirement for querying installed rules limited to the example in
the framework or should it be more general?
Audit for takeover?
Taylor draft provides general capability against a wildcarded filter
expression -- is this going too far?
Scope issues: is what an Agent can discover by querying limited by local
policy only?

9. Wildcards and Ranges

Is there a need to support address ranges in filters?
Port ranges?
Open-ended pinholes (e.g. allow TCP from any source to this internal
address/port)?

10. Grace Period and Pre-Notification

Should there be notifications before rule lifetime expiry?

11. Atomicity A Requirement?

Neither semantics document provides for installation of multiple rules in a
single atomic transaction (i.e. to avoid deadlock).
Is this a requirement?
Is there a requirement to enable forcing of symmetric bidirectional mappings
(i.e. source mapped address-port = destination mapped address-port)?

Tom Taylor
[email-masked]
Ph. +1 613 736 0961 (ESN 396 1490)

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

---

From: "Bob Penfield" <[email-masked]>
Date: Mon, 22 Jul 2002 15:40:58 -0400

----- Original Message -----
From: "Tom-PT Taylor" <[email-masked]>

> Takeover = ability for one Agent to operate on rules established by
another

As one of those who supported/insisted on requirement 2.2.7, I say yes.
Again, the motivation behind requirement 2.2.7 (which is unfortunately not
present in the requirements), was to allow for redundancy in the application
and to handle the case where one agent failed after a rule was added,
another agent could remove the rule when the application session was
completed.

> What granularity?  Per rule?  Per session?

It could even be per agent, as in "let agent A muck with any rule that agent
B creates and vice versa". In that case it could simply be policy in the
middlebox.

> Should the protocol have a formal handoff procedure?

No. I see no need for this. The redundant agents (there could be more than
just 2) are established ahead of time. This could be done:

a) by local policy in the middlebox.

b) at session establishment where the agent indicates what other agents are
allowed to operate in its rules.

OR

c) at rule creation, where the agent indicates what other agents can operate
on this rule.

OR, if multiple agents could establish sessions with the middlebox using the
same agent identification, so they would be seen as the same entity even
though there are multiple sessions. Its as if the "agent" is a logical
entity that lives across multiple network hosts. Any notifications would be
sent on all sessions with that agent identifier.

> Is it agreed that this is the only condition the protocol must satisfy to

I don't think so. There needs to be precedence/ordering rules for the basic
components of the filter (5-tuple), or a way to indicate or determine the
precedence that is used by the middlebox. It may even depend on the hardware
used in the middlebox. Some systems won't allow overlap at all, some may
depend on the order the entries are added, others may depend on a weighting
scheme, other may simply be longest match. There should probably be
something in the session establishment that can indicate the precedence and
any restrictions.

> Do rules continue to survive to the end of their lifetime?

This should probably be specified in protocol at rule or session
establishment. In the case of redundant agents, where one agent might crash
or restart, you do not want to stop the flows/sessions. If rule state is
stored at the endpoints instead of at proxies which act as midcom agents, a
failed/restarted agent would not mean that the rule state was lost to the
application, and thus there is no need to delete the rule.

> Is destroy-create an adequate substitute if there is such a requirement?

I have not yet encountered or thought of a case where you would need to add
a rule to a group except when it is created.

> Is there a real example where MIDCOM needs to install a blocking rule?

It is not so much "deny" as "disabled". In establishing things like SIP
sessions, the agent does not have all the necesary information, but wants to
"reserve" the resources in the middlebox. If the middlebox has a limited
number of bindings it will give out or a limit on the number of pinholes,
you would want to make sure that the needed resources for both the
caller-to-callee and callee-to-caller flows are reserved in the first
communication with the middlebox so that we don't have to reject a session
after the called party has answered.

To be specific, refer to section 7.2 in the framework doc. The request to
"create consecutive port BINDs" occurs after the called party answers. If
this request were to fail, the proxy (midcom agent) would have to tear down
the session which the called party would see as more or less complete, but
the calling party will see it as unanswered (this also runs into all sorts
of messy SIP rules too). If the bindings could be reserved as the INVITE
traverses the SIP Proxy (midcom agent), the half-answered call could be
avoided. If the bindings/reservations could not be done, the INVITE would be
rejected and not forwarded on to the called party.

However, if the agent reserves the bindings at this earlier stage, it does
not know the internal address to which the bindings map to. It needs to
"reserve" a mapped address, but the rule is "disabled", until the rule is
updated with the internal address when the 200-OK response comes from the
internal SIP phone.

> Conclusion: no point in multiple filter conditions in the same policy
rule.

Agreed

> the framework or should it be more general?

It could also be used for recovery when an agent restarts and re-establishes
the session.

> Scope issues: is what an Agent can discover by querying limited by local

It could be limited to just those rules installed by the same agent
identifier in the same or a previous session.

> Open-ended pinholes (e.g. allow TCP from any source to this internal

Allowing any source is required for a basic RTP flow. SDP used in SIP, MGCP,
and Megaco does not identify the source address and port of the flow, only
the destination.

> Should there be notifications before rule lifetime expiry?

I'm inclined to think so. It does allow the agent to rely on the middlebox
for the expiration timing. Otherwise, the agent would have to have timers
too so it could extend the rule lifetime shortly before it expires.

> single atomic transaction (i.e. to avoid deadlock).

There were a number of us who wanted this as an explicit requirement, but it
is not in the doc, but the same principles in 2.2.3 of efficiency and
minimizing the messages to and from the middlebox apply. It would be better
if there was just one middlebox transaction between receiving the
application request and forwarding it on.

> (i.e. source mapped address-port = destination mapped address-port)?

It is not explicitly required, but would enable things like symetric RTP.

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 26 Jul 2002 19:26:22 -0400

----- Original Message -----
From: "Bob Penfield" <[email-masked]>

> From: "Tom-PT Taylor" <[email-masked]>
<snip>
> application, and thus there is no need to delete the rule.
OOPS, this is an answer to a different question. Namely, do rules survive
the end of a MIDCOM session (i.e. when the agent closes the connection).

The "end of lifetime question" sounds like question 10 in the original