1 / 10

PANA Deployment Guidelines for DSL Networks

This document provides guidelines for deploying PANA over DSL access networks, focusing on the migration from PPP-based models to IP-based models without a standard network access authentication protocol.

nicholej
Télécharger la présentation

PANA Deployment Guidelines for DSL Networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. PANA in DSL networksdraft-morand-pana-panaoverdsl-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@, 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

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

  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

More Related