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

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 13 Mar 2003 11:18:11 +0100

hi 

please see my comments inline:

> Hi Alper,
> 
> Alper Yegin wrote:
> 
> > 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.
> 
> 
> btw, I did not notice any list the different DI objects 
> supported/carried by the PANA protocol in the recent draft.
> does the working group plan to establish a list ?

we had a discussion on the different di objects. i personally think that the
di objects should be exensible since i think it should be possible to
support:

a) more than one ip address
b) network masks
c) maybe even packet filters offering more granularity 

ad a) in case of multi-homing, ipv6 (link local, site local), ip aliasing,
etc. 
ad b) for mobile networks
ad c) to be able to restrict access control a little bit (only allow certain
ports, protocols, destination, etc.)

i am also not very happy about link layer addresses. but that's a separate
story.  

> 
>  
> > 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. 

> 
> 
> 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: [email-masked]
Date: Thu, 13 Mar 2003 11:48:07 +0100

Hannes, Alper,

>>>COPS-PR already handle this?
>>>
> 

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 13 Mar 2003 10:11:40 -0500

> would not terminate a ipsec tunnel at the ep - that would be done at the

In some scenario, the EP is a link layer device, but in other scenario
the EP can be an IP layer device and IPsec tunnel can be terminated at
the EP (e.g., "PANA in the Absence of Any Lower-Layer Security"
scenario in the usage scenarios draft.)  So I think the current EP
definition in requirements-05 draft is valid.

Yoshihiro Ohba