Subject: [midcom] MIDCOM Protocol Information Elements

From: "Tom-PT Taylor"<[email-masked]>
Date: Fri, 15 Mar 2002 11:13:50 -0500

This is a first rough cut at the information exchanges required between a
MIDCOM Agent and a Middlebox.  I've taken the requirements document as the
basis for discussion.  I'll summarize the discussion in terms of actual
messages and parameters in another note.

Requirement 2.1.1: authentication and authorization.

There are two ways to read this requirement.  One is that the necessary
parameters for authentication and authorization must be included in each
request made by a MIDCOM agent.  An alternative is that the protocol
supports an exchange of messages which sets up an association with a defined
scope of authorization between the MIDCOM Agent and the Middlebox.  In this
second case, the association identifier must clearly be present or implicit
in all subsequent exchanges between the two entities.

---

Requirement 2.1.2: one MIDCOM agent related to multiple Middleboxes

I believe this implies that a parameter must be present in each message
coming from a Middlebox, identifying that Middlebox uniquely.

---

Requirement 2.1.3: one Middlebox related to multiple MIDCOM Agents

Similarly, a parameter must be present in each message coming from a MIDCOM
Agent, identifying that MIDCOM Agent instance uniquely.

---

Requirement 2.1.4: deterministic Middlebox behaviour when multiple MIDCOM
Agents interact with it.

One step in meeting this requirement is to allow the Middlebox to send
messages indicating that particular requests have caused resource conflict.
There is obviously dynamic behaviour implied by such messages, but this
analysis is just about the information flows required.  We can debate
whether these messages should contain diagnostic material giving details
about the conflict.

---

Requirement 2.1.5: known and stable state

The explanation of this requirement suggests that a request identifier
parameter is needed for each request, that each request must have a reply,
and that the reply must include the request identifier parameter as well as
the result of the request.

It seems to me the requirement also implies the need for a MIDCOM Agent to
be able to audit the Middlebox state as it relates to requests made in the
past by that Agent.  The audit request might include parameters limiting the
scope of the audit.  The response includes a state parameter expressed as a
sequence of rulesets.  We may want to think about the additional parameters
needed to support segmentation of the response.

---

Requirement 2.1.6: Middlebox reporting state

This and the previous requirement may imply a need for a Middlebox to send
autonomous notifications to a MIDCOM Agent when it believes it is holding
stale state.  Such a notification would contain either a ruleset identifier
or an actual ruleset, and should also contain a reason parameter indicating
why the notification was generated.  Clearly on receipt of such
notifications the MIDCOM Agent must either allow the state to persist or
clear it, but we have a choice whether to model the Agent's action as a
response to the notification or simply as a new request if action is
required.

---

Requirement 2.1.7: autonomous reporting of conditions and autonomous actions

The discussion of the previous requirement partly covered this one.  The
additional elements in this requirement are that the reported condition may
not necessarily involve a ruleset.  On the other hand, there is the
additional need for an action parameter, composed of a field indicating the
action taken by the Middlebox and a field indicating either the rulesets if
any affected by the action or identifiers for those rulesets.

---

Requirement 2.1.8: mutual authentication

The discussion here is similar to that for 2.1.1, but in the reverse
direction.

---

Requirement 2.1.9: either entity can terminate a session

It is not clear what terminating a session means.  Does it mean that the
MIDCOM Agent is no longer allowed to make requests and receive notifications
without re-autheticating, or does it also mean that all state owned solely
by that MIDCOM Agent is also cleared?  I suspect it is the latter, given
that the framework limits discussion to in-path Agents.  In any event, the
minimal messaging requirement is that each entity be able to send a message
to the other indicating the end of the association.

---

Requirement 2.1.10: MIDCOM Agent can determine success or failure of a
request

Messaging requirement covered by discussion of 2.1.5.

---

Requirement 2.1.11: version interworking

There seems to be agreement to include protocol version in each message,
governing the content of that message.  It is possible the initial message
of a session should include an additional parameter listing the versions
supported by the originator.

If the protocol has identifiable options the initial message of the session
in each direction should include a parameter indicating what options the
message sender supports.

---

Requirement 2.1.12: overlapping rulesets

The behaviour required when overlapping rulesets are offered is out of scope
of this analysis.  However, there is clearly a requirement, addressed also
in 2.1.4, to indicate a resource conflict in the response to a request.  It
may be that we are prepared to support three parameters in response to a
request to install a ruleset: the ruleset installed and "owned by" the
requesting MIDCOM Agent alone, the ruleset already installed and also "owned
by" other MIDCOM Agents, and the ruleset denied because of resource conflict
and policy regarding resolution of that conflict.  Similarly, the response
to a request to modify or remove a ruleset may contain two parameters,
indicating the ruleset successfully changed or removed and the ruleset
unchanged because it also has other owners and policy regarding resolution
of the conflict indicated that it should be retained.  All of these rulesets
come about because of partitioning of the ruleset in the original request
according to the different logical possibilities.

---

Requirement 2.2.1: extensibility

Information requirements are probably sufficiently covered by the discussion
of 2.1.11.

---

Requirement 2.2.2: control of multiple functions

I believe this validates the framework's distinction between filter specs
and action specs as separate components of a ruleset parameter.  It also
implies that a ruleset can be represented as a sequence of {filter spec,
action spec} pairs, where the filter specs possibly overlap and the
corresponding action specs may differ so long as they are not contradictory.

---

Requirement 2.2.3: ruleset groups

I believe this implies a requirement for a message from a MIDCOM Agent
associating a ruleset group identifier with either a sequence of rulesets or
a sequence of ruleset identifiers.  It also implies that a message from a
MIDCOM Agent requesting modification or removal may include a ruleset group
identifier as an alternative to a ruleset or ruleset identifier.

---

Requirement 2.2.4: ruleset lifetime extension

This requires a message that a MIDCOM Agent can send, designating a ruleset
or ruleset identifier, which carries the meaning that the lifetime of that
ruleset should be extended.

---

Requirement 2.2.5: action on unknown attributes

This requires a sub-field within certain attributes indicating whether the
attribute can be ignored if not understood or stops the request from being
processed.  I can't be more specific until I've done detailed work on the
attributes which can be present in messages.  It also implies that the
responses to individual requests must identify components of the request
which have caused failure or which have been ignored.

---

Requirement 2.2.6: failure reasons

A detailed work item. 

---

Requirement 2.2.7: multiple Agents working on the same ruleset

See discussion of 2.1.4 and 2.1.12.

---

Requirement 2.2.8: filter specs

See 2.2.2 regarding filter specs as components of rulesets.  Also requires a
detailed specification of the possible content of a filter spec.  At a
minimum we need the basic 5-tuple with CHOOSE and ALL wildcards allowed for
individual components.

---

Requirement 2.2.9: matching parity ("oddity")

Semantically this that it must be possible to add qualifier to the CHOOSE
wildcard for a port, indicating whether it should be ODD or EVEN.

---

Requirement 2.2.10: ranges of ports

This adds another semantic qualifier for a CHOOSE-wildcarded port,
indicating the number of ports to assign.  The ODD/EVEN qulifier would be
interpreted to apply to the first port of a range.

---

Requirement 2.2.11: contradictory actions for sub-filters

No new information requirement, given other points addressed above.

---

I'll leave the 2.3.x requirements as an exercise for our security design.

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

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