Subject: [midcom] Winnowing down the list

From: Melinda Shore <[email-masked]>
Date: Fri, 08 Nov 2002 16:50:45 -0500

I'd like to continue to try to narrow the list of midcom
candidates.  From the discussion so far it looks like a lot
of people are dubious about COPS, so here's the question:

Is there any objection to removing COPS from the list of
candidate midcom protocols?  If you object, please give a
reason.

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

---

From: "Cedric Aoun" <[email-masked]>
Date: Tue, 19 Nov 2002 17:15:49 +0100

hopefully you'll get the email this time, looks like the mail list server is
having problems ...

-----Original Message-----
From: Aoun, Cedric [GOLF:MA01:EXCH] 
Sent: 19 November 2002 17:08
To: 'Juergen Quittek'; 'Martin Stiemerling'; [email-masked]
Cc: Hamer, Louis-Nicolas [CAR:AN22:EXCH]; Chan, Kwok-Ho [BL60:470:EXCH]
Subject: RE: [midcom] Winnowing down the list

Hi,
Here is a small memo on how COPS-PR manages the directionality and policy
rule contention (many Midcom agents manipulating the same policy rule).
In this memo, COPS = COPS-PR

The first thing is to look at the applicability of off path Middle box
control, it applies to simple network topology where the Midcom agent has
awareness of the end points and the Middlebox connected to their network.

Brief walk thru on establishing communications between the Midcom agent and
the Middlebox, and the directionality requirement
-------------------
The MIDCOM agent and the Middlebox need to setup a trust relationship which
comprises of provisioning authorization policies on the Middlebox on which
Midcom agent is allowed to request MIDCOM policy rule installation. In
addition a security association is setup, in the case of COPS IPSEC ESP is
the preferred way, the MIDCOM agent sends the initial key management
protocol message (IKE or other).
Once the security association is up, the Middlebox establishes a TCP
connection with the Midcom agent, and send sends the COPS open message (I
won't go in much details in this note). When the Midcom agents requests a
policy rule installation, it will send an UNSOLLICITED COPS message etc ...
This behavior is compliant to the current COPS specification, as well as to
the requirement relevant to the establishment of communications between the
Middlebox and Midcom agent.

Handling resource contention happening due to manipulation of policy rules
by several Midcom agents
-----
In all protocol implementations, a resource coordination or management
function is required on the host to be able to handle resource contention.
The interaction between the COPS state machine and the resource management
function is quite simple, I didn't add it in this "brief" note, but could do
so in another separate mail if requested.
I have added some practicality in these walk thrus to show that this is real
and how is works with the current COPS specification, note that I tried to
keep it as simple as I can for readers not familiar with COPS.
The COPS PEP will establish a TCP connection (following the setup phase as
discussed above) to each MA, the PEP establishes a COPS "connection"  to
each MA, each using a different Client-Type, in this case MIDCOM_1,
MIDCOM_2, MIDCOM_3. (Note that a single PEP can not have multiple COPS
connections with the same Client-Type (with the exception of NULL
Client-Type)).
Hence the PEP must use a different Client-Type for each MA.  One method is
"Client-Type boot strapping".  The PEP first performs a COPS OPEN with the
well know (standardized) Client-Type of MIDCOM, using this COPS connection
to indicate to the MA that it will follow up with a second COPS OPEN with a
specific none standardized Client-Type (MIDCOM_1).  It is the second COPS
connection that will be used for the real MIDCOM communication.  This is
very much like the way well known port numbers are used for the initial TCP
connection request, with the actual TCP traffic handled using a different
TCP port/process.
Notice the Client-Type range used for MIDCOM_1 is in the none reserved
range.  And it is the MB that select the actual Client-Type to use.  Hence
there will not be collision of the same Client-Type used on a single MB.

Hope this helps clarifying on the resolution of the raised issues on the
list.

In the sake of moving things forward on the protocol evaluation front, would
the WG think that proposing implementation guides on protocol x (x being one
of the remaining protocols in the list) being MIDCOM help in the selection
process?  We need to address as well the authorization policy area and see
which protocol integrates best with authorization policy exchanges.

Cheers
Cedric