Subject: [midcom] Thought you'd want to know

From: Melinda Shore <[email-masked]>
Date: Thu, 11 Oct 2001 16:36:11 -0400

We are down to six (give or take my sloppy counting) unresolved
requirements bullets.  We'll get these wrapped up ASAP.  

PLEASE:
1) if you think there's still something missing or that needs
   further attention, tell us NOW, and
2) if you're responsible for completing a piece of work as input
   to the requirements document, it's time to deliver.

Many thanks for all your hard work,

Melinda

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

---

From: Scott Brim <[email-masked]>
Date: Thu, 11 Oct 2001 18:01:17 -0400

> requirements bullets.  We'll get these wrapped up ASAP.  

My opinions on the remaining ones ...

   R86: It should possible to define rulesets that contain a more
        specific filter than an overlapping ruleset, and a different set
        of attributes.  This should allow Midcom agent to request that a
        subset of the traffic that would be allowed by the overlapping
        ruleset be specifically disallowed.

        Reasoning: this is required for rapid response to intrusion
        detection.

Accept.

   R35: Once the need for the relationship between a Midcom Agent and a
        Middlebox established during the registration process has
        lapsed, a deregistration process will be required.  This will
        break the trust relationship between the specific Middlebox and
        Midcom Agent.  Once this has been done, a Middlebox MUST NOT
        service any further requests from a given Midcom Agent without
        the Midcom Agent first re-establishing the appropriate trust
        relationship with the Middlebox.

           Wording problems.  "Registration" needs better definition (in
           framework?).  "Lapsed" is not understood the same by
           everyone.

This is obvious.  Discard.

   R38: The Midcom Protocol MUST enable the Middlebox and/or Midcom
        Agent to determine when a registration session is no longer
        valid.  This is to address cases such as when either a Middlebox
        or MIDCOM Agent restarts.

"Registration", as used by Suresh and in this case, is a policy issue.
It's what happens when a middlebox (or agent) hears from some policy
entity that an agent (or a middlebox) is allowed to communicate at all.
This doesn't have anything to do with the midcom protocol, but rather
with policy interactions.  So far we've done close to nothing wrt
policy.  I say discard this one, since it will be included in whatever
we finally do with policy.

   R43: The Midcom Protocol SHOULD allow the aggregation of commands,
        requests and responses.

           We don't know what this one really means, but we're putting
           off judgment until we know more about our other
           requirements.

Already covered by already accepted ones.  Discard.

   R47: When accepting a request for a pin-hole, the Middlebox MUST be
        able to provide the MIDCOM Agent with information that may be
        used to identify the resource in subsequent operations.

           Temporarily changed "flow" to "resource".  Need better word
           than "resource".

I think we should discard this too.  We don't know how midcom will be
used, especially when multiple agents and middleboxes get involved.
There are two possible approaches.  First, accept this requirement, and
require a field in the protocol packets with a note that it *might* be
used for an identifier, but keep it reserved and do our best not to use
it.  After a while we'll know if we need it.  If we don't we can use it
for future expansion.  The other option is to abandon this requirement,
and if in the future someone decides they really need an identifier,
they can add it using the protocol's extensibility features.  The only
reason to stick the field in now is if there are performance issues.

   R75: The Midcom Protocol must produce robust operation even when
        routing changes such that traffic from a particular end system
        passes through a different middlebox.  (Huitema)

           Eliot Lear says "this takes too much state".

I don't think supporting this kind of robustness is the job of the
midcom protocol.  I think the model underlying this one is poorly
formed.  Discard.

..Scott

---

From: Mark Duffy <[email-masked]>
Date: Thu, 11 Oct 2001 19:22:07 -0400

>        Reasoning: this is required for rapid response to intrusion

Yes, accept.  But terminology needs to be updated.  Here is proposed
wording (I also changed the bit about 'allowing' traffic to 'affecting'
traffic, to be less firewall-centric):

   R86: It should be possible to define rulesets which contain filter 
        spec(s) that overlap with those of other rulesets.  This should
        allow a Midcom agent to install a ruleset affecting only a
        subset of the traffic that would be affected by the overlapping
        ruleset.

>This is obvious.  Discard.

Yes, discard.

>we finally do with policy.

Yes, discard.

>Already covered by already accepted ones.  Discard.

I'm not sure what accepted reqts cover this one.  But I vote for discard
anyway.

>midcom protocol.  I think the model underlying this one is poorly

Isn't this really part of the topology question?  What is the result of the
breakfast ^h^h^h^h^h^h^h^h^h contest of champions and how does that result
feed back into the requirements??

---

From: "Christopher A. Martin" <[email-masked]>
Date: Mon, 15 Oct 2001 10:39:34 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Scott Brim
> Sent: Thursday, October 11, 2001 5:01 PM
> To: midcom
> Subject: Re: [midcom] Thought you'd want to know
>
>

How about this, :
------------
R35: If MIDCOM peer authentication timer has expired, assuming that an
authentication timeout is implemented, MIDCOM peers must renegotiate for
proper authentication. If renegotiation fails further MIDCOM requests MUST
be denied by the Middlebox until authentication negotiation is successful.
------------

This should possibly also be coupled with a maximum retry period to lock out
renegotian after n*failed attempts.

>         or MIDCOM Agent restarts.

Maybe we should reword it to place it more in line with the actual
authentication between the two entities (Middlebox and MIDCOM agent). We
should address some form of authentication mechanism if not within the
protocol, then at least require some form of authentication such as SSL/TLS
be used.

Policy server would be more inline with the fact that the two entities are
allowed to authenticate.

>            off judgment until we know more about our other

This could possibly be used in relation to a protocol such as SIP that can
initiate several conversations through the same middle box (as in the case
of a conference call) to request multiple rulesets for the call leg(s) at
the same time...to lower call setup time. Just my two cents...for further
discussion during judgement  :^)

>            Temporarily changed "flow" to "resource".  Need better word

How about initiator/terminator... to identify an end host within the
Middleboxes realm that may either be intitiating or terminating IP traffic.

---

From: Melinda Shore <[email-masked]>
Date: Mon, 15 Oct 2001 13:27:35 -0400

>How about this, :

No, I think it's not what we mean (we don't care why authentication
would be terminated, but we might care that it is - and this is really
an authorization question, anyway).  I'm with Scott.  R35 is obvious
and should be deleted.

>authentication between the two entities (Middlebox and MIDCOM agent). 

No, because it needs to be consistent across authenticated
and unauthenticated sessions.  I'm all for deleting it, especially
since we've got another requirement mandating the ability to
notify agents of various middlebox events, including restarts.

Melinda