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

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 13 Mar 2003 12:52:20 +0100

hi yacine,

thank you for pointing to this issue. i guess we clearly need to
differentiate between link layer data protection and network layer data
protection. hence the data protection terminated at the link layer device
(ep) is clearly link layer specific and has nothing todo with ipsec. 

everyone is encouraged to read the drafts carefully to point to ambiguities
in the texts. this helps to prevent confusions. 

ciao
hannes

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]
> Sent: Thursday, March 13, 2003 11:48 AM
> To: Tschofenig Hannes
> Cc: Alper Yegin; pana
> Subject: Re: COPS-PR for PAA-EP interface
> 
> 
> Hannes, Alper,
> 
> >>>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?
> >>>
> > 
> > i guess that this is not fully correct. 
> > the ep is a link layer device from the perspective of the 
> pac. hence the pac
> > would not terminate a ipsec tunnel at the ep - that would 
> be done at the
> > paa. 
> > 
> 
> 
> actually that was my understanding until I read in the 
> draft-pana-req-05
> 
> *the new EP definition:
>    "Per-packet enforcement includes per-packet filtering and 
> may include
>    cryptographic per-packet protection as well."
> 
> *this statement in the PAA-EP section:
>    "The chosen protocol MUST be capable
>    of carrying DI and cryptographic keys for a given PaC from 
> PAA to EP."
> 
> 
> ... consistent clarifications needed.
> 
> thanks,
> yacine
> 
> 
> >>
> >>the IPSP wg has designed an IPSec PIB for that, see:
> >>http://www.ietf.org/internet-drafts/draft-ietf-ipsp-ipsecpib-07.txt
> >>
> > 
> > thanks for this information. if an ipsec sa has to be 
> established locally
> > only (at the paa) then "only" an api (e.g. pf_key) or a cli 
> is required. 
> > 
> > ciao
> > hannes
> > 
> > 
> > 
> >>No new data types needed.
> >>
> >>
> >>>Thanks.
> >>>
> >>>alper
> >>>
> >>
> >>thank you,
> >>yacine
> >>
> >>
> >>
> >>>
> >>>
> >>>
> >>>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: Tschofenig Hannes <[email-masked]>
Date: Thu, 13 Mar 2003 14:24:17 +0100

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

>  >>From: Alper Yegin [mailto:[email-masked]]
>  >>Sent: Thursday, March 13, 2003 8:01 AM
>  >>To: [email-masked]; pana
>  >>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
> >>>http://www.ietf.org/internet-drafts/draft-yacine-pana-cops-
> ep-00.txt
>  >>>

---

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 13 Mar 2003 15:20:08 +0100

hi 

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

sounds good to me. that also fits to the comment of my previous mail. 

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

ciao
hannes

> 
> thank you,
> yacine
> 
> 
> Tschofenig Hannes wrote:
> 
> > 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
> > 
> > 
> > 
> >>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 
> >>
> >>>advantage of the dynamic provisioning ability of COPS ? I 
> >>>
> >>guess no...
> >>
> >>>particularly dynamic context of PANA, it appears that we 
> >>>
> >>have already 
> >>
> >>>so yes I personnaly think that the working group should 
> >>>
> >>setup its own 
> >>
> >>> >>>[COPS]: provides message level security for 
> >>>
> >>authentication, replay
> >>
> >>> >>>protocol used between PAA and EP should be able to 
> >>>
> >>detect inactive
> >>
> >>> >>>PAA should be able to notify an EP for 
> >>>
> >>allowing/disallowing access
> >>