Subject: [midcom] Status

From: Melinda Shore <[email-masked]>
Date: Tue, 16 Oct 2001 13:01:00 -0400

R86 Accepted with revisions:
  R86: It should possible to define rulesets that contain a more specific
  filter spec than an overlapping ruleset. This should allow agents to
  request actions for the subset that contradict those of the overlapping
  set. This should allow Midcom agent to request to a Midcom server
  controlling a firewall function that a subset of the traffic that would
  be allowed by the overlapping ruleset be specifically disallowed.

R35 Delete
R38 Delete
R43 Delete
R47 Delete
R75 Needs more discussion
R?? Accepted:
  "The midcom protocol must provide protection against replay
  attacks"

Melinda

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

---

From: Scott Brim <[email-masked]>
Date: Tue, 16 Oct 2001 14:08:03 -0400

On Tue, Oct 16, 2001 01:01:00PM -0400, Melinda Shore allegedly wrote:
>   R86: It should possible to define rulesets that contain a more
>   specific filter spec than an overlapping ruleset. This should allow
>   agents to request actions for the subset that contradict those of
>   the overlapping set. This should allow Midcom agent to request to a
>   Midcom server controlling a firewall function that a subset of the
>   traffic that would be allowed by the overlapping ruleset be
>   specifically disallowed.

First I don't see what SHOULD statements are doing in requirements.
Is this a requirement or not?

Second, why is there a firewall example?  Why is there an example at
all?

>   "The midcom protocol must provide protection against replay

R73 is currently "The Midcom Protocol MUST define mechanisms to mitigate
reply attacks on the control messages." and was already accepted.

---

From: Mark Duffy <[email-masked]>
Date: Tue, 16 Oct 2001 16:41:20 -0400

Now that all but one of the requirements items have been dispositioned, I
re-read the list.  It strikes me that most of the remaining requirements
concern the protocol mechanisms and are pretty generic at that.  

There is not that much about what semantics may be conveyed between an
agent and a mb.  Sect. 2.7 contains some reqts that discuss things having
to do with rulesets but most of them are housekeeping types of reqts.  R83
and R84 are the only ones that say anything at all about what the ruleset
action specs may be.  (These are requirements about requesting NAT bindings
according to some constraints on port numbers.)

I would like to see us add a few more requirements about the action specs
that an agent may invoke.  It seems to me that this is a fundamental aspect
of what we are trying to accomplish.  What is the use of all the protocol
mechanism if we don't say what you can use it for?

Here are a few specific midlebox actions I think are needed:

.  Allocate a NAT address binding
.  Allocate a NAPT address & port binding
.  Create a firewall hole

For all the above I think we need several flavors of when the action spec
goes away, here are a few suggestions:
.  only when explicitly removed by an authorized agent
.  at the expiration of a timer (and/or at a specific date/time)
.  after a TCP connection associated with the filterspec closes (e.g. FINs
and ACKs exchanged)

And perhaps even some flavors of when the action spec goes into effect:
.  immediately
.  when TCP SYN is seen incoming
.  when tcp SYN is seen outgoing

If there is interest I can bundle theses into some requirements statements
for discussion.  If there is the outpouring of "that stuff is out of scope"
sentiment that I half expect, then I'll go back into my corner :-)

-Mark

P.S. One other requirement area that I think is still not addressed is a
way to scope a ruleset to only those packets that arrive/depart the
middlebox on cetain interface(s)/realm(s) etc.  I am presuming this will be
addressed when the "topology question" is resolved.  Yes?