Subject: RE: [midcom] Evaluation: COPS and session initialisation

From: "Cedric Aoun" <[email-masked]>
Date: Thu, 17 Oct 2002 18:12:57 +0200

Martin,

I think we discussed several times the "session" on the mailing list.
We never closed this on the list, I'm still hoping we could close this at
some point.
What do we mean by session?

There is a relation between the Middlebox and the Midcom agent, this
relation consists of:
-Establishing trust and authorization levels
-Establishing a security association
-This relation could have a real identifier or a pseudo one based on the
Midcom agent or Middlebox identity; this could be  used for hand-overs or
for softstate cleaning in case the Midcom agent goes down.

This relation doesn't really need to have a direction for its establishment,
I suggest that we take it out of the directionality of the relation from the
requirements document.

In addition COPS-PR could be used in the context of in path signaling for
authorization policy purposes.
As some of the Middleboxes will support both in path signaling (the NSIS WG
delivery) and the MIDCOM off path protocol COPS-PR has the best position to
be the MIDCOM protocol.

Cedric

-----Original Message-----
From: Martin Stiemerling [mailto:[email-masked]]
Sent: 17 October 2002 10:45
To: [email-masked]
Subject: [midcom] Evaluation: COPS and session initialisation

Just a poll about the working group opinion:
The MIDCOM framework and requirements say that the agent initiates the 
session to the middlebox. But in the COPS/COPS-PR case the way is vice 
versa: The middlebox initiates the session to the agent.

I see this a as major difference in the particular architecture. How 
does the working group feel about this. Is this just a minore point or a 
real concern.

Martin

-- 
Martin Stiemerling

NEC Europe Ltd. -- Network Laboratories  [email-masked]
IPv4: http://www.ccrle.nec.de  IPv6: http://www.ipv6.ccrle.nec.de

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

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 17 Oct 2002 19:17:07 +0200

Hi Cedric,

> I suggest that we take it out of the directionality of the relation from the

I disagree. Consider the ideas of dynamic service creation. NAT and firewall
are basic components of a network infrastructure. Services and corresponding
midcom agents have a more dynamic character. If you add a service, you do not
necessarily want to reconfigure the middlebox by telling: "There is a new
agent. Please establish a connection!". Contrarily, for the service setup
it is desirable just to configure the agent telling it to which middlebox(es)
it has to establish associations. The same applies to service removal.
How would a middlebox behave if you just disable a service including the agent.
Would it continuously poll the agent, because it cannot operate without?
The situation is different for the agent. It probably will find it hard to
operate if the middlebox goes down, particularly if its the only box
connecting inner side and outer side. In this case it makes sense that the
agent regularly polls if the middlebox is up again.

An extreme case also is supported much better when the agent establishes
connection: With the agent initiating the assiciation, the midcom protocol can
be used by each terminal that wants to communicate across a middlebox to
configure the box by itself. This becomes impractical if the association is
established in the other direction.

> delivery) and the MIDCOM off path protocol COPS-PR has the best position to

Would be great if we could identify one protocol that has the best position!

But I do not see your point. If COPS-PR is good for and used for authorization
then why is it automatically a good midcom protocol?

SNMP is good for and used for monitoring. Also it is implemented on almost all
boxes. Still this is no reason for me to consider SNMP as well positioned.

     Juergen

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 18 Oct 2002 20:44:01 +0200

> We never closed this on the list, I'm still hoping we could close this 
> at some point.
> Midcom agent or Middlebox identity; this could be  used for hand-overs 
> or for softstate cleaning in case the Midcom agent goes down.

Agreed.

> 
> This relation doesn't really need to have a direction for its 
> establishment, I suggest that we take it out of the directionality of 
> the relation from the requirements document.

The relationsship is from the framework document, section 4. "MIDCOM 
protocol": "MIDCOM shall be a client-server protocol, initiated by the
agent."
Section 6.2. "Registration and deregistration of MIDCOM agents" says:
"MIDCOM agent profile may be pre-configured on a middlebox.
Subsequent to that, the agent may choose to initiate a MIDCOM session
prior to any data traffic."

I always read "initiated" by the agent, that implies for me the agent 
starts the communication with the middlebox. We are definitely too late 
for deleting this directional component, because it is in our framework 
RFC.

Another point for not initiating the communication by the middlebox, the 
above mentioned hand-off between agents. Imaging you have three SIP 
proxies, two of them as a fall-back. All three are pre-configured to the 
middlebox. The primary, or in duty, SIP server has a server crash, now 
the third SIP server takes over. How should the middlebox know that the 
third SIP server is the one in charge and not the second? The middlebox 
has to know something about the failover mechanism. Furhtermore it has 
to maintain to all proxies a connection at any time, that's polling!

Martin

> 
> In addition COPS-PR could be used in the context of in path signaling 
> for authorization policy purposes.
> As some of the Middleboxes will support both in path signaling (the NSIS 
> WG delivery) and the MIDCOM off path protocol COPS-PR has the best 
> position to be the MIDCOM protocol.
> 
> Cedric
> 

-- 
Martin Stiemerling

---

From: Kwok Ho Chan <[email-masked]>
Date: Mon, 21 Oct 2002 15:08:58 -0400

Martin, All:
I will try to answer your question. As we have already identified in the 
protocol evaluation document,
   "COPS does not meet the directionality part of the requirement.  The 
definition of COPS
    allows a PEP (Middlebox) to establish communication with a PDP (MIDCOM 
Agent)."
But, we added the following explanations:
   "However, nothing explicitly prohibits a PDP from establishing 
communication with a
    PEP. The PEP could have local policies dictating what action to take 
when it is
    contacted by an unknown PDP. These actions, defined in the local 
policies, would
    ensure the proper establishment of an authorized association. "

Once the COPS connection is open, it is perfectly within the COPS protocol for
the PDP to send unsolicited decisions to the PEP (for example the midcom agent
sending an open pinhole decision to the middlebox.

Also to address the fail over points you made below.
The PEP (Middlebox) can have local policy indicating the order by which it will
contact the PDPs (MIDCOM Agents).  This local policy can actually be installed
by the primary SIP server (in the example you gave), indicating if 
communication
is lost between it (the primary SIP server) and the Middlebox, the 
Middlebox MUST
contact the THIRD SIP server as the highest priority back-up SIP server, then
the SECOND SIP server if the both the PRIMARY/FIRST SIP server and the
THIRD SIP server is not available to provide the required services.
Notice the fail over is totally deterministic and also controlled by Policy 
of the
controlling domain.

Also only a single connection  between a Middlebox and a MIDCOM Agent
is maintain at any given time, the one that is being used.

Also lets say the PRIMARY SIP server degrades/dies/off-load its service
gracefully (you can also view this as part of load balancing between
multiple SIP servers), the PRIMARY SIP server can REDIRECT the
Middlebox to get its service from a specific other SIP server, in the
example you gave below, this should be the THIRD SIP server.
This is done without any interruption to the functionality the Middlebox
is providing.

This is how COPS is intent to be used without any modification to the 
current RFCs.

With the above, one may take a step back and think:
"Is the directional requirement really 'required' ??  Or is it the 
FUNCTIONALITY that is
really 'required' ??"

I have shown how COPS satisfy the fail over and high availability 
FUNCTIONALITIES
without talking about the directional 'requirement'.

Hope I have clarify some of the points raised.

-- Kwok Ho Chan --

At 08:44 PM 10/18/02 +0200, Martin Stiemerling wrote:
>>establishment, I suggest that we take it out of the directionality of the 
>>relation from the requirements document.
>
>for deleting this directional component, because it is in our framework RFC.
>
>middlebox. The primary, or in duty, SIP server has a server crash, now the 
>third SIP server takes over. How should the middlebox know that the third 
>SIP server is the one in charge and not the second? The middlebox has to 
>know something about the failover mechanism. Furhtermore it has to 
>maintain to all proxies a connection at any time, that's polling!
>
>Martin
>
>>-- Martin Stiemerling

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 21 Oct 2002 22:27:08 +0200

Kwok,

-- Kwok Ho Chan wrote on 21 October 2002 15:08 -0400:

> Martin, All:
> I will try to answer your question. As we have already identified in the protocol evaluation document,
>    "COPS does not meet the directionality part of the requirement.  The definition of COPS
>     allows a PEP (Middlebox) to establish communication with a PDP (MIDCOM Agent)."
>    "However, nothing explicitly prohibits a PDP from establishing communication with a
>     PEP. The PEP could have local policies dictating what action to take when it is
>     contacted by an unknown PDP. These actions, defined in the local policies, would

Yes, I think this is exactly the point. You can create a framework, for example using
policies, for initiating the association between middlebox and agent. You also can
use a new Midcom Session Initiation Protocol to be used by the agent for telling
the middlebox: "Please contact me for establishing a midcom session".

The question is, whether this would be a good choice considering operational issues.
I see service installation, modification and removal to be much more dynamic than
middlebox installation, modification and removal. Therefore, I consider it an
operational disadvantage having to configure the middlebox each time a service is
installed, is modified (changes the failover sequence), or is removed.

    Juergen

> by the primary SIP server (in the example you gave), indicating if communication
> is lost between it (the primary SIP server) and the Middlebox, the Middlebox MUST
> Notice the fail over is totally deterministic and also controlled by Policy of the
> controlling domain.
>
> This is how COPS is intent to be used without any modification to the current RFCs.
>
> "Is the directional requirement really 'required' ??  Or is it the FUNCTIONALITY that is
> really 'required' ??"
>
> I have shown how COPS satisfy the fail over and high availability FUNCTIONALITIES

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 22 Oct 2002 11:43:44 +0200

Hi Kwok,

first of all thank you for the clarification! But are you talking about 
COPS or COPS-PR in your email?

Please find my further comments inline.

> Once the COPS connection is open, it is perfectly within the COPS 

Here is the point: an open COPS connection. How does the COPS PEP know 
when to open the connection? I see that the agent only knows the point 
of time when it needs to be connected to the middlebox.

> sending an open pinhole decision to the middlebox.
[...]

> This is how COPS is intent to be used without any modification to the 

OK ,I see that COPS (or do mean COPS-PR?) can fulfil these requirements.

> "Is the directional requirement really 'required' ??  Or is it the 

We need the functionality that the agent determines its needs about 
being connected to the middlebox.

Martin