Transcript PPT Version

PANA in DSL networks
draft-morand-pana-panaoverdsl-00.txt
Lionel Morand
Roberta Maglione
John Kaippallimalil
Alper Yegin
IETF-67, San Diego
Output of IETF66
• After IETF66, it was decided to simplify the
PANA framework document (-06)
• One of the consequences was to:
– Remove the PANA use cases for DSL and WLAN
• Done in version -07
– Spin off to independent drafts
• This draft covers the DSL case
– Reusing and expanding the previous material in the
PANA framework
IETF-67, San Diego
Summary
• Provides guidelines for PANA deployment
over DSL access networks
• Focus on DSL networks migrating from:
– a traditional PPP access model
• Where PPP is used to carry authentication
parameters (PAP/CHAP or EAP methods)
– to a pure IP-based access environment
• that lacks a standard network access
authentication protocol between terminal/CPE and
IP Edge router
IETF-67, San Diego
Context and Use Case
• Evolution of DSL architecture
• Evolution in two steps:
– Moving from ATM to Gigabit Ethernet
– Moving from PPP-based environment to IP-based model
• "IP Sessions" model introduced in DSL Forum
– Basically, an IP session represents the subscriber IP traffic
associated with an IP address
• A subscriber may have multiple IP addresses (or sessions) in
simultaneous use.
• An IP session may be associated with multiple IP flows.
• The same subscriber policies govern all IP sessions/flows
• No built-in authentication mechanism
– A solution is needed in a DHCP-based DSL environment
– PANA is a natural candidate
IETF-67, San Diego
Why PANA?
• PANA fulfills basic and advanced security requirements
within an IP session based environment
• Examples (non-exhaustive list):
– Native support of EAP frames over IP;
– IP address based session management mechanisms, using an
explicit session identifier;
– Authentication mechanism independent of the physical medium
type;
– Per-session enforcement policies (i.e. filters) depending on the
creation and deletion of the PANA session;
– Session keep-alive and session monitoring functionalities.
IETF-67, San Diego
Location of the PAA and EP
• In a PPP based environment
– the BRAS is in charge of:
• interfacing with CPE for authenticating and authorizing them for the
network access
• performing policy control by acting as an enforcement point.
• In an IP session based environment
– Such functionalities may be provided at the same level by
locating the PAA and EP entities in the BRAS.
– Preserve an improved and well-established DSL network
configuration.
– No need for an external PAA-to-EP interface
• However, it is possible to have PAA and BRAS/EP not
collocate
– PAA-to-BRAS interface may be based on SNMP or on the future
ANCP
IETF-67, San Diego
Location of the PaC
• The possible location of the PaC depends on the CPE configuration
– If CPE is a L2 Ethernet bridge, the PaC should be implemented in hosts
• Host and BRAS are on the same IP link.
• Any host connected to the CPE is authenticated by the PAA
• Network access control on a per-host basis, as required by the IP session
model.
– If CPE is an IPv4 router, the PaC should be implemented in CPE
• Only the CPE is authenticated
• Hosts use private IP@, the CPE acting as a NAT
• All hosts connected to the CPE have access to the ISP network using
private IP@ obtained by the CPE's subscriber
– If CPE is an IPv6 router, the PaC should be implemented in the CPE
and the hosts
• The hosts have to use an non-local IP address
• Network access control is also performed on a per-host basis, in
addition to the handling of the CPE own IP sessions.
IETF-67, San Diego
Other contents
• Consideration on IP Address Configuration
– How to configure a Pre-PANA address?
– How to configure a Post-PANA address?
• If needed (e.g. IPv4 case with temporary IP@ as PRPA)
• Consideration on Dynamic ISP selection
– For BRAS shared by multiple ISP
• Consideration on Cryptographic Protection
– That may not be needed in all cases
• An example of basic IP flows
– For the IPv4 case, with hosts using temporary IP@
until authenticated
IETF-67, San Diego
Next Step
• Collect inputs from the PANA WG
– During the meeting
– On the PANA mailing list
• Is the level of details sufficient?
– General guidelines, no specific implementation
• Adopt this draft as WG document?
– With the objective to have an Informational RFC.
IETF-67, San Diego
Thank You
IETF-67, San Diego