Subject: RE: COPS-PR for PAA-EP interface

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 13 Mar 2003 10:17:03 +0100

hi all,

i have briefly looked at the COPS-PR draft. 

for the interface between the paa and the ep(s) any protocol proposal
published in the midcom group would just work fine. am i wrong with this
observation?

are the requirements in a pana environment different to those in the midcom
group. if so then we should add them somewhere (e.g. requirements document).

ciao
hannes

> -----Original Message-----
> From: Alper Yegin [mailto:[email-masked]]
> Sent: Thursday, March 13, 2003 8:01 AM
> To: [email-masked]; pana
> Subject: Re: COPS-PR for PAA-EP interface
> 
> 
> 
> Hello Yacine,
> 
> Thanks for the draft analizing COPS-PR. One question/comment:
> 
>    In the context of PANA, the access control information 
> provisioned by
>    the PAA to the EP consists are DI-based filters. Depending on the
>    access technology, DIs might contain any of IP address, link-layer
>    address, switch port number, etc. of a device.
> 
> In some scenarios, some keying material will be passed along 
> with the DI to
> the EPs. Would new data types necessary for this, or does 
> COPS-PR already
> handle this?
> 
> Thanks.
> 
> alper
> 
> 
> 
> 
> On 3/10/03 2:50 AM, "[email-masked]"
> <[email-masked]> wrote:
> 
> > hi folks,
> > 
> > this proposal considers the applicability of existing 
> COPS-PR protocol
> > for the PAA-EP communication:
> > http://www.ietf.org/internet-drafts/draft-yacine-pana-cops-ep-00.txt
> > 
> > below is a summary of how COPS-PR meets the PAA-EP protocol
> > identified requirements. I'll do an update as soon as these 
> requirements
> > are finalized.
> > 
> > 
> > --- security
> > the PAA-EP protocol needs to guaranty identity, confidentiality and
> > integrity
> > 
> > [COPS]: provides message level security for authentication, replay
> > protection, and message integrity. COPS can make use of existing
> > protocols for security such as IPSEC or TLS to authenticate 
> and secure
> > the channel between the PEP(EP) and the PDP(PAA).
> > 
> > --- keep-alives
> > protocol used between PAA and EP should be able to detect inactive
> > peer within an appropiate time period and delete the related states.
> > 
> > [COPS]: KA messages are sent with a time-period set by the PDP(PAA)
> > at session startup.
> > 
> > --- event notification
> > architecture needs to allow PaC and PAA initiated authentication
> > 
> > [COPS]: COPS-PR can also be used following the outsourcing 
> (pull) model.
> > For example, in a very similar context, 3GPP does it this 
> way for PCF to
> > control GGSN (Go interface).
> > 
> > --- pull method
> > have a mechanism for a newly introduced EP to learn the policies
> > currently in effect on that access network.
> > 
> > [COPS]: the initial configuration request/decision can do this.
> > 
> > --- push method
> > PAA should be able to notify an EP for allowing/disallowing access
> > for a particular client. This should happen without EP 
> sending a request
> > to the PAA.
> > 
> > [COPS]: the successive configuration decisions do this.
> > 
> > 
> > thanks,
> > yacine
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
>

---

From: [email-masked]
Date: Thu, 13 Mar 2003 13:55:42 +0100

Hannes,

Tschofenig Hannes wrote:
 > published in the midcom group would just work fine. am i wrong with
 > this observation?
 >
 > are the requirements in a pana environment different to those in the
 > midcom group. if so then we should add them somewhere (e.g.
 > requirements document).

the technical requirements which "disqualified" COPS-PR as the midcom 
protocol are the following:
* Multiple Agents operating on the same ruleset.
* MIDCOM requires that the MIDCOM Agent establish the session.

do we have such requirements in PANA that prevent us from taking 
advantage of the dynamic provisioning ability of COPS ? I guess no...

moreover, I carefully red the PAA-EP requirements thread and, above the 
particularly dynamic context of PANA, it appears that we have already 
some PANA specific requirements which are directly adressed by COPS-PR.

so yes I personnaly think that the working group should setup its own 
requirements for this interface... in the continuity of the discussions 
held on the ML and the work presented at atlanta.

thanks,
yacine