Subject: [midcom] Back at it

From: Melinda Shore <[email-masked]>
Date: Thu, 20 Sep 2001 11:32:07 -0400

Let's get back to work on finishing up the requirements,
particularly now that we've got basic agreement on terminology.
Today's items:

R1a: The MIDCOM protocol must enable a MIDCOM agent requiring
    the services of a middlebox to establish an authorized
    association between itself and the middlebox.

Proposal: keep

R10: A middlebox must be able to notify a midcom agent of
    the following events: Session creation, session termination,
    MIDCOM protocol failure, middlebox function failure, or any
    other significant event.  Independently, ICMP error codes
    can be useful to notify transport layer failures to the agents.

Proposal: keep, align terminology, delete last sentence (mechanism
is out of scope)

R13: Agent hosting entity (whatever that is) must be identified in
    the midcom protocol.

Proposal: delete, unless this is intended to say more than the agent
must be identified.  Otherwise I think it's self-evident (we've got
authentication/authorization requirements - identity is implicit in
those).

R14: Once a connection is established between a middlebox and a MIDCOM
agent, that connection should be usable with multiple instances of
the application(s), as appropriate.

Proposal: if we're going to keep this we need to 1) align the language,
and 2) clarify the text quite a bit.  I think that this is intended to
say that the midcom protocol should be able to support multiplexing
requests from different applications and multiple requests from the same
application across a single midcom session, yes?

Melinda

Melinda

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

---

From: Scott Brim <[email-masked]>
Date: Thu, 20 Sep 2001 12:17:10 -0400

>     association between itself and the middlebox.

OK

> Proposal: keep, align terminology, delete last sentence (mechanism

OK.  I think we've agreed on 'session' so isn't the terminology aligned?  

> authentication/authorization requirements - identity is implicit in

OK

> application across a single midcom session, yes?

However, I don't think it means much.  The communication between a
middlebox and an agent is independent of what might have triggered it.
The middlebox is not going to hear about multiple instances of an
application.  Specifically, first it means an agent needs to be able to
ask for multiple different rulesets.  Enh.  That's obvious enough that
we can skip it.  Second, though, IF at some future date rules can
include stateful inspection mechanisms, then it also means that a single
agent must be able to request more than one of those.  Since we're not
going there in this incarnation of the working group, I think this
requirement should be punted.

..Scott

---

From: "Bob Penfield" <[email-masked]>
Date: Thu, 20 Sep 2001 12:46:21 -0400

----- Original Message -----
From: "Scott Brim" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, September 20, 2001 12:17 PM
Subject: Re: [midcom] Back at it

> >     association between itself and the middlebox.
agreed
> OK.  I think we've agreed on 'session' so isn't the terminology aligned?

I interpreted 'session' to be 'ruleset'. For example, if a ruleset has a
timer and the timer expired and the ruleset was deleted, the agent would
want notification that that occured.

Why would one midcom agent care about the establishment or termination of a
session with another midcom agent? I thought we agreed that any relationship
between midcom agents is out of scope.

> > authentication/authorization requirements - identity is implicit in
agreed
> requirement should be punted.

I can see two intrepretations of this:

1) multiple applications can use the midcom agents one 'session' with the
middlebox. How applications interact with a midcom agent or take the role of
a midcom agent is beyond the scope of the protocol.

2) the same 'session' between an agent and the middlebox could be used for
either the firewall or NAT function or both. I don't think we need to say
this.

Either way, let's drop it.

---

From: Mark Duffy <[email-masked]>
Date: Thu, 20 Sep 2001 17:12:32 -0400

>> >     association between itself and the middlebox.
Keep, but I think  s/authorized/authenticated
Either that or s/authorized//   and cover the security aspect somewhere
else (such as second half of R33), but in that case what of value is left
of R1a?
Presumably the authorization is controlled by policy mechanisms out of
scope of midcom and the parties will not bring up the session with
unauthorized peers.  But the authentication mechanism is a necessary part
of the "midcom protocol".  Indeed without authentication, the authorization
is vacuous.

>between midcom agents is out of scope.

My interpretation of "session" was like Bob's (e.g. VoIP media session).
If that's what it really means, I'd propose replacing "Session creation,
session termination" with "ruleset expiration".  This would cover notifying
the agent if the ruleset a) times out, or b) becomes obsolete because the
transport session the ruleset was for closed.

I would also propose removing "MIDCOM protocol failure".  If the midcom
protocol has failed, how can we use it to notify the peer of anything?

>> > authentication/authorization requirements - identity is implicit in
ditto

>Either way, let's drop it.
Yes.