PAA-EP protocol considerations PANA wg - IETF 57 Vienna yacine.el_mghazli@alcatel.fr

Overview PAA/EP separation PAA-EP protocol requirements draft-ietf-pana-requirements-07 nice-to-have func. multiple PAAs issue Candidate protocols/applicability analysis SNMP COPS-PR Diameter ForCES

PAA/EP separation PANA terminology PAA (PANA Authetication Agent) verify the credentials provided by a PaC and grant/deny access to the associated device PaC (PANA client) provides the credentials to prove its identity for networkn access authorization EP (Enforcement Point) node in the NA where per-packet policies (filters) are applied on the inbound/outbound traffic of client device. Information such as DI and (optionally) cryptographic keys are provided by PAA per client for constructing filters on the EP

PAA/EP separation PAA co-located from AR NAP ISP PaC [D1] EP AR/PAA AAA backend PaC [D2] EP

PAA/EP separation PAA separated from AR NAP ISP PaC [D1] EP AR PaC [D2] EP AR PAA AAA backend

PAA-EP protocol requirements Discussion objective the PANA wg hopefully will not design a new protocol design It may involve the definition of extensions of an existing protocol fix the « multiple PAAs » issue compare the available configuration protocols against the PAA-to-EP requirements identified candidate protocols: SNMP COPS-PR Diameter ForCES ???

PAA-EP protocol requirements draft-ietf-pana-requirements-07.txt Secure PAA-EP protocol needs to guarantee identity, confidentiality and integrity One-to-many PAA-EP relation there might be several EPs provisioned by a single PAA Provosioned Data The protocol must carry DI-based filters and keys PAA-initiated communication Push model Event Notification depends on the PANA protocol design

PAA-EP protocol requirements Nice-to-have functionnalities (mailing list) additional to the PAA-EP reqs: pull model for newly introduced EP to learn the policies currently in effect on the NA EP-initiated requests implies a stateful approach inactive peer detection keep-alive messages recovery back-up PAA details here: http://yacine.free.fr/draft-yacine-pana-paa-ep-reqs-00.txt

PAA-EP relation issue PANA-specific needs objective: to find the right tradeoff for PANA-specific needs Scalability: How many EPs does the PAA have to provision ? Dynamicity: How frequent are the changes in the EPs configuration ? Inter-PAAs communication: How unlikely is an inter-PAAs (inter-ISPs !) relation ?

Protocol Comparison SNMP appicability DI-based filters and keys already defined MIBs (filters, ipsec policy, etc.) can be re-used. Secure SNMPv3 includes the User-based Security Model, which defines 3 standardized methods for providing authentication, confidentiality, and integrity.  Additionally, USM has specific built-in mechanisms for preventing replay attacks including unique protocol engine IDs, timers and counters per engine and time windows for the validity of messages. One-to-many PAA-EP relation An SNMP manager (PAA) can communicate simultaneously with several agents (EPs). Push/Pull model SET messages with bottom-up notifications.

Protocol Comparison SNMP appicability (cont’d) Pros: Widely spread Multi-manager allowed (option2-oriented) number of MIBs available Cons: UDP-based SET (push) almost never used stateless (need polling)

Protocol Comparison COPS-PR applicability Di-based filters and keys already defined PIBs (filters, ipsec policy, etc.) can be re-used. Secure COPS-PR has built-in message level security for authentication, replay protection, and message integrity. can also use TLS or IPSec. One-to-many PAA-EP relation PDPs are designed to communicate with several PEPs Push/Pull model DEC messages (top-down) & REP messages (async bottom-up)

Protocol Comparison COPS-PR applicability (cont’d) Pros: REQ message for PEP-initiated communication Heartbeat (KA messages) Stateful dynamic approach TCP-reliable Built-in sync and fail-over Transactional (roll-back) Cons: single PDP per PEP (option3-oriented) not used (but for 3GPP GGSN provisioning) Details here: http://www.ietf.org/internet-drafts/draft-yacine-pana-cops-ep-00.txt

Protocol Comparison Diameter applicability Di-based filters and keys IPfilterRule data type available, but a new PANA application extension of Diameter would certainly have to be defined. Secure Diameter relies on either IPSEC or TLS for these functions. One-to-many PAA-EP relation Diameter allows connection to more than one peer (and encourages this for improved reliability).  Whether the Diameter connection state machine is too heavy to support the number of connections needed is a matter for discussion. Push/Pull model The Diameter protocol permits either peer in a connection to originate transactions. Thus the protocol supports EP-originated messages.

Protocol Comparison Diameter applicability (cont’d) Cons: not a configuration protocol !

Protocol Comparison Diameter applicability Di-based filters and keys IPfilterRule data type available, but a new PANA application extension of Diameter would certainly have to be defined. Secure Diameter relies on either IPSEC or TLS for these functions. One-to-many PAA-EP relation Diameter allows connection to more than one peer (and encourages this for improved reliability).  Whether the Diameter connection state machine is too heavy to support the number of connections needed is a matter for discussion. Push/Pull model The Diameter protocol permits either peer in a connection to originate transactions. Thus the protocol supports EP-originated messages.

Protocol Comparison ForCES applicability DI-based filters and keys Secure One-to-many PAA-EP relation Push/Pull model

THANKS