Subject: RE: [midcom] Winnowing down the list

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

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

-----Original Message-----
From: Juergen Quittek [mailto:[email-masked]]
Sent: 12 November 2002 15:12
To: Aoun, Cedric [GOLF:MA01:EXCH]; 'Martin Stiemerling'; Hamer,
Louis-Nicolas [CAR:AN22:EXCH]
Cc: [email-masked]
Subject: RE: [midcom] Winnowing down the list

Cedric,

-- Cedric Aoun wrote on 12 November 2002 11:18 +0100:

> Martin,
> I believe that it is clearly stated in the protocol evaluation document
that
> several PDPs can access to the same resource by using an underlying
resource
> management function assisted with local policies. I think we have closed
on
> this
> one before the previous IETF meeting.

I agree, we have closed this issue as far as the text in the evaluation
document is concerend. All protocols have several advantages and some
problems. However, the evaluation document does neither weight the problems,
nor does it give a recommendation concerning protocol selection.

Therefore, we now have to enter the next stage. We have to weight the
advantages and disadvantages of the protocols in order to get closer to
a recommendation ot better: a protocol selection. And as far as I
understand Martin, he is not aiming at changing any line in the
evaluation, but at getting closer to a recommendation.

One step in this direction is looking again at the disadvantages of the
candidate protocols, which are described in the evaluation document.
And then we have to find out for each of them, whether it is just a minor
disadvantage or a serious problem.

In the case you are discussing with Martin, I see at first glance technical
problem that can be solved, but I am not happy with using COPS-PR while
violating its specification in RFC 3084.

RFC 3084 says:

    "There may be one or more PIBs for given area of policy and
     different areas of policy may have different sets of PIBs."
     (Section 1)

So let's assume we have a Midcom PIB in the Midcom area.

    "Second, as it [COPS] has a single connection between the
     policy client and server per area of policy control identified
     by a COPS Client-Type, it guarantees only one server updates
     a particular policy configuration at any given time.  Such a
     policy configuration is effectively locked, even from local
     console configuration, while the PEP is connected to a PDP
     via COPS." (Section 1.1)

Conclusion: only a single Midcom agent would be allowed to request
or release middlebox resources. I know that technically we could just
ignore this and it works, but I do not feel comfortable when doing so.

Support for doing so is given by

    "In order to support a model that includes multiple PDPs
     controlling non-overlapping areas of policy on a single PEP, the
     client-type specified by the PEP to the PDP is unique for the area
     of policy being managed.  A single client-type for a given area of
     policy (e.g., QoS) will be used for all PIBs that exist in that
     area.  The client should treat all the COPS-PR client-types it
     supports as non-overlapping and independent namespaces where
     instances MUST NOT be shared." (Section 1)

So maybe we can map agent identfiers to client types and use a lot of
existing COPS functonality. But still it leaves the impression of a
hack rather than of a solution.

    Juergen

> Cedric
>
>
> -----Original Message-----
> From: Martin Stiemerling [mailto:[email-masked]]
> Sent: 12 November 2002 11:03
> To: Hamer, Louis-Nicolas [CAR:AN22:EXCH]
> Cc: [email-masked]
> Subject: Re: [midcom] Winnowing down the list
>
>
>
> Louis-Nicolas Hamer wrote:
>
>> Melinda, all,
>>
> [....]
>
>
>>
>> The only reason invoked against COPS was the directionality requirement.
>> Kwok explained in great lengths how this was not a big deal - it can be
>> fixed quite easily. So I object to your proposal to remove COPS.
>
>
> Hmm, there is another reason against COPS:
> The COPS PEP is not able to receive configuration data from multiple PDP
> for the *same* resource, e.g. the middlebox can not receive policy rule
> configuration requests from different agents for the same packet filter
> at the same time.
>
> Martin
>
>
>>
>> As I have indicated before, I think COPS, SNMP and MEGACO are very good
>> fits for MIDCOM.
>> I would suggest that the best way forward would be to see what the WG
>> decides on the approach to take to
>> "pinpoint" the best protocol to use - I believe you have
>> that point on the agenda for the Atlanta meeting, right?
>>
>> l-n
>>
>>
>>  > -----Original Message-----
>>  > From: Melinda Shore [mailto:[email-masked]]
>>  > Sent: Friday, November 08, 2002 4:51 PM
>>  > To: [email-masked]
>>  > Subject: [midcom] Winnowing down the list
>>  >
>>  >
>>  > 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
>>  >
>>
>
>
> _______________________________________________
> midcom mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/midcom

---

From: "Juergen Quittek" <[email-masked]>
Date: Tue, 19 Nov 2002 21:07:37 +0100

Hi Cedric,

On the connection setup directionality:
You argue that you anyway need to establish a security association,
and you say you can use this step for telling the middlebox to
ahich agent it should establish a MIDCOM session. This does not
seem to be a flexible solution.
1. Your excluding manually installed keys at the middlebox.
2. You need to make sure, that the agent is up and running
   when you tell the middlebox about the keys and credentials
   of the particular agent.
3. You are requiring that each time the agent starts up,
   the security framework need to tell the middlebox about this.
   Particularly this point appears to be definitely too restrictive.
   I don't think we should run through installation of keys and
   credentials at the middlebox, each time a MIDCOM agent is started.
   A well configured system should be able to stop services (including
   the corresponding MIDCOM agents) and start them up again without
   running through the complete security management process again.

On the COPS client types:
The procedure you describe below is technically feasible. We agreed
so far already in the discussion with Kwok. However, it is a hack
rather than a clean solution.
You first establish a COPS connection with one client type and then
negotiate another client type dynamically, because COPS requires 
different client types for agents talking to the same middlebox.
Then you open a second connection with the dynamically agreed
client type.
I'm asking me immediately: why is COPS asking you to do such strange
things???? Maybe it's doing so for good reasons. If I read the COPS-PR
RFC well, you are required to do so, because COPS is explicitly not
intended for this kind of application (as MIDCOM protocol) where
several agents are in competition for shared resources (bindings,
IP addresses, port numbers). You circumvent this intention with your
proposed procedure (that I call a hack).

    Juergen

-- 
fier!