IETF PANA working Group liaison to:
Gavin Young, DSL Forum Technical Committee Chair
Alper Yegin, IETF PANA WG co-chair, email@example.com
Basavaraj Patil, ITEF PANA WG co-chair, firstname.lastname@example.org
Date: December 12, 2007
Subject: Information about PANA as an applicable protocol for subscriber
authentication in DSL networks
The PANA (Protocol for carrying Authentication for Network Access) Working
Group in the IETF is chartered to work on defining a link-layer type
independent network access authentication protocol. WG has completed its work
on specifying the PANA protocol and the specification is now in the RFC
editors queue for publication as a proposed standard
Earlier this year, the DSL Forum had sent a liaison statement to the IETF
requesting information about a protocol or work in the IETF which would meet
the DSL Forumâ€™s requirements for subscriber authentication in the context of
the evolution of the DSL architecture. DSL Forumâ€™s migration away from PPP
has been identified as one of the candidate deployments for PANA from the
early days of the WG as documented in RFC 4058
(http://ietf.org/rfc/rfc4058.txt). Additionally, the specific DSLF
requirements were discussed at the PANA WG meeting at IETF70 in Vancouver (Dec
5, 2007) and on the PANA WG mailing list afterwards. WG believes that PANA is
applicable to the current requirements presented by DSLF. The PANA WGâ€™s
analysis is presented below.
We would like to request the DSL Forumâ€™s technical committee to review the
suitability of PANA for addressing your requirements especially in view of the
fact that the protocol is now lined up to be published as a proposed standard
RFC by the IETF. If you have further questions or need clarifications, please
do not hesitate to contact the PANA WG.
Alper Yegin (PANA WG co-chair) Basavaraj Patil (PANA WG co-chair)
IPAuth-1: Authentication must not depend on the use of any given
eg web browser.
Explanation: PANA implementation does not rely on other applications.
IPAuth-2: Must re-use existing SP Authentication infrastructure (use
Database) and allow mixed mode operation (eg PPP and IP) on the
same L3 edge device
Explanation: PANA does not require any changes on the AAA database. It can
be used over IP networks that co-exist with PPP networks.
IPAuth-3: Must offer L3 edge device (BRAS) subscriber policy enforcement
via pull and push methods, ie L3 edge must be aware of
authentication status and any subscriber credentials
Explanation: PANA Authentication Agent (PAA) can be implemented on the BRAS,
IPAuth-4: Must allow for authorization purposes the use of any additional
identifiers that may be available, eg MAC address, Option82
Explanation: MAC address is already available on the IP messages that carry
PANA. PANA does not prevent use of Option 82 with DHCP.
IPAuth-5: Should allow for subscriber nomadicity and support tracking of
changes to location.
Explanation: PANA allows establishing a new session or maintaining the same
session upon mobility/nomadicity.
IPAuth-6: Must fit into TR-101 operational model
Explanation: Although we do not see any issues there, IETF does not have the
expertise to fully evaluate this requirement.
IPAuth-7: Must support revoking authentication
Explanation: PANA Termination message is explicitly designed for that
IPAuth-8: Must handle L3 CPE device authentication and end-device (PC) user
based authentication (likely with L2 CPEs in the latter case)
Explanation: PANA Client (PaC) can be implemented on both CPEs and
IPAuth-9: Should be simple to implement on client (PC or CPE)
Explanation: Implementation does not require changes to the operating system.
Open source implementation available.
IPAuth-10: Must be independent of medium type (eg Fixed Ethernet, Legacy
PON, WiFi, WiMax, etc)
Explanation: This is the original design goal of PANA.
IPAuth-11: Must not require major re-work for IPv6. None ideally.
Explanation: Same protocol can be used for both IPv4 and IPv6.
IPAuth-12: Must be resilient to attacks on the subscriber, eg against
brute-force challenge attacks, or spoofing of an authenticator
Explanation: Rate limiting, message validation, message authentication are
against such threats.
IPAuth-13: Must offer authenticator edge device resiliency, eg not be prone
DOS authentication attacks
Explanation: Stateless handshake and rate limiting are used against such
IPAuth-14: Must allow for authentication and download of subscriber service
profile before service IP address is assigned
Explanation: PANA requires an IP address be configured prior to authentication
(a IPv4/IPv6 link-local, or a short-lease DHCP address), but
the â€œservice IP addressâ€? be assigned after authentication.
IPAuth-15: Must offer an option to re-authenticate periodically or on
Explanation: Both the client-side and network-side are capable of initiating
IPAuth-16: At an absolute minimum, must provide equivalent or better
than PPP CHAP/MD5 does today. Must include the ability to move to
more secure authentication methods over time.
Explanation: Supports any EAP method (including CHAP/MD5 equivalent of
IPAuth-17: Should offer authentication fail/success reason message to
subscriber from authenticator .
Explanation: Supports explicit authentication and authorization result codes
IPAuth-18: Must allow for multiple authenticated subscribers on same
or logical interface.
Explanation: PANA Session-ID can demultiplex multiple authenticated sessions
over the same physical/logical interface.
IPAuth-19: Must offer scalable subscriber management, eg not rely on
subscriber credentials configured on the authenticator Edge
Explanation: PANA is independent of any backend protocol (RADIUS, Diameter,
LDAP, etc.) that may or may not be used by the authenticator
IPAuth-20: Must have a logical path towards standardization
Explanation: PANA specification is already approved by IESG and currently in
IETF RFC queue.
IPAuth-21: Must scale to 10000s of subscribers per L3 edge device (ie must
be conservative in use of resources)
Explanation: See PANA Session Attributes in the spec.