PANA in DSL networks draft-morand-pana-panaoverdsl-00.txt

1
PANA in DSL networksdraft-morand-pana-panaoverds
l-00.txt

• Lionel Morand
• Roberta Maglione
• John Kaippallimalil
• Alper Yegin

IETF-67, San Diego
2
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
3
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
4
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
5
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
6
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
7
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_at_, the CPE acting as a NAT
• All hosts connected to the CPE have access to the
  ISP network using private IP_at_ 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
8
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_at_ 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_at_
  until authenticated

IETF-67, San Diego
9
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
10
Thank You
IETF-67, San Diego