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

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 13 Mar 2003 14:37:06 +0100

hi again. 

i just looked at the "Middlebox Communications (MIDCOM) Protocol Evaluation"
draft:
http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol-eval-06.txt

in the conclusion section it says:

"                 T            P+           P            F         
    ----------------------------------------------------------------- 
    SNMP          22           5            0            0 
    RSIP          17           7            3            0 
    Megaco        19           5            3            0 
    Diameter      21           5            1            0 
    COPS          20           5            2            0 
     
                  Table 1: Totals across all Requirements 
"

to me it seems that snmp got the best rating. what is wrong with simply
following the conclusions reached in the midcom group (especially since it
is mainly a network operators choice what protocol to choose for paa <-> ep
communication)? 

ciao
hannes

> -----Original Message-----
> From: Tschofenig Hannes 
> Sent: Thursday, March 13, 2003 2:24 PM
> To: [email-masked]'
> Cc: 'Alper Yegin'; pana
> Subject: RE: COPS-PR for PAA-EP interface
> 
> 
> hi yacine!
> 
> -snip
> 
> > 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.
> ok. i see your point. 
> 
> for me it is particularly of interest to see new requirements 
> caused by pana
> which 
> - could also serve as an input to the midcom group 
> - provide us more insight into the pana protocol interaction. 
> 
> i only see a problem if pana wants to do the same work as midcom. 
> 
> > 
> > do we have such requirements in PANA that prevent us from taking 
> > advantage of the dynamic provisioning ability of COPS ? I 
> guess no...
> 
> i am not saying that cops-pr is a bad protocol for 
> controlling eps by a paa.
> 
> 
> > 
> > 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...
> 
> requirements or protocols?
> 
>  in the continuity of the 
> > discussions 
> > held on the ML and the work presented at atlanta.
> 
> discussing these things in atlanta is certainly a good idea. 
> 
> ciao
> hannes
> 
> 
> > 
> >  >
> >  > ciao
> >  > hannes
> > 
> > thanks,
> > yacine
> > 
> >  >
> >  >
> >  >
> >  >>-----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 15:10:33 +0100

a better way to proceed should be to first check if midcom requirements 
match those for the PAA-EP protocol.

is the working group ready for such a discussion now ?
... don't want to disturb any work plan w/ a premature debate.

thank you,
yacine

---

From: Alper Yegin <[email-masked]>
Date: Thu, 13 Mar 2003 12:40:24 -0800

Yacine,

> ... don't want to disturb any work plan w/ a premature debate.

I think first we need to see if we are capturing the PANA requirements on
the PAA-EP protocol correctly. Please see the requirements draft and let us
know. http://toshiba.com/tari/pana/draft-ietf-pana-requirements-05.txt

Then we can see if these requirements are readily satisfied by any generic
such protocol. PANA might not be really imposing additional requirement on
the existing protocols. Than, we can also check with MIDCOM requirements to
see if they are a superset of PANA requirements. If so, then result of
MIDCOM can readily satisfy PANA 's needs.

So, let's start with seeing if we are capturing the requirements adequately.

alper