draft-ietf-pana-requirements-02.txt   draft-ietf-pana-requirements-03.txt 
PANA Working Group Reinaldo Penno, Editor PANA Working Group Reinaldo Penno, Editor
INTERNET-DRAFT Alper E. Yegin INTERNET-DRAFT Alper E. Yegin
Date: June 2002 Yoshihiro Ohba Date: June 2002 Yoshihiro Ohba
Expires: December 2002 George Tsirtsis Expires: December 2002 George Tsirtsis
Cliff Wang Cliff Wang
Protocol for Carrying Authentication for Protocol for Carrying Authentication for
Network Access (PANA) Network Access (PANA)
Requirements and Terminology Requirements and Terminology
<draft-ietf-pana-requirements-02.txt> <draft-ietf-pana-requirements-03.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 22 skipping to change at page 2, line 22
3. Terminology....................................................4 3. Terminology....................................................4
4. Requirements...................................................4 4. Requirements...................................................4
4.1. Authentication...............................................4 4.1. Authentication...............................................4
4.1.1. Authentication of Client...................................4 4.1.1. Authentication of Client...................................4
4.1.2. Authorization, Accounting and Access Control...............5 4.1.2. Authorization, Accounting and Access Control...............5
4.1.3. Authentication Backend.....................................5 4.1.3. Authentication Backend.....................................5
4.1.4. Identifiers................................................5 4.1.4. Identifiers................................................5
4.2. Network......................................................6 4.2. Network......................................................6
4.2.1. Multi-access...............................................6 4.2.1. Multi-access...............................................6
4.2.2. Disconnect Indication......................................6 4.2.2. Disconnect Indication......................................6
4.2.3. Location of PAA............................................6 4.2.3. Location of PAA............................................7
4.2.4. Secure Channel.............................................6 4.2.4. Secure Channel.............................................7
4.3. Interaction with Other Protocols.............................6 4.3. Interaction with Other Protocols.............................7
4.4. Performance..................................................7 4.4. Performance..................................................8
4.5. Reliability and Congestion Control...........................7 4.5. Reliability and Congestion Control...........................8
4.6. Miscellaneous................................................7 4.6. Miscellaneous................................................8
4.6.1. IP Version Independence....................................7 4.6.1. IP Version Independence....................................8
4.6.2. Denial of Service Attacks..................................7 4.6.2. Denial of Service Attacks..................................8
4.6.3. Location Privacy...........................................7 4.6.3. Location Privacy...........................................8
Acknowledgements..................................................7 4.7 Change Log....................................................8
References........................................................8 Acknowledgements..................................................9
References........................................................9
Authors' Addresses................................................9 Authors' Addresses................................................9
Full Copyright Statement.........................................10 Full Copyright Statement.........................................10
1. Introduction 1. Introduction
Network access technologies for wired and wireless media are Network access technologies for wired and wireless media are
evolving rapidly. With the rapid growth in the number and type of evolving rapidly. With the rapid growth in the number and type of
devices and terminals that support IP stacks and can access the devices and terminals that support IP stacks and can access the
Internet, users can potentially use a single device having the Internet, users can potentially use a single device having the
capability of attaching via different multiple access media and capability of attaching via different multiple access media and
skipping to change at page 5, line 44 skipping to change at page 5, line 44
finer granularity authorization, such as negotiating QoS parameters, finer granularity authorization, such as negotiating QoS parameters,
authorizing individual services (http vs. ssh), individual users authorizing individual services (http vs. ssh), individual users
sharing the same device, etc. is outside the scope of PANA. sharing the same device, etc. is outside the scope of PANA.
Providing access control functionality in the network is outside the Providing access control functionality in the network is outside the
scope of PANA. Client access authentication should be followed by scope of PANA. Client access authentication should be followed by
access control to make sure only authenticated and authorized access control to make sure only authenticated and authorized
clients can send and receive IP packets via access network. Access clients can send and receive IP packets via access network. Access
control can involve setting access control lists on the enforcement control can involve setting access control lists on the enforcement
points. Identification of clients which are authorized to access points. Identification of clients which are authorized to access
the network is done by the PANA protocol exchange. Though, the network is done by the PANA protocol exchange.
transporting the required information to the enforcement points in
the network is outside the scope of PANA as well since PANA assumes
the PAA is co-located with the enforcement point.
Carrying accounting data is outside the scope of PANA. Carrying accounting data is outside the scope of PANA.
4.1.3. Authentication Backend 4.1.3. Authentication Backend
PANA protocol MUST NOT make any assumptions on the backend PANA protocol MUST NOT make any assumptions on the backend
authentication protocol or mechanisms. PAA may interact with authentication protocol or mechanisms. PAA may interact with
backend AAA infrastructures such as RADIUS or Diameter, but it is backend AAA infrastructures such as RADIUS or Diameter, but it is
not a requirement. When the access network doesn't rely on a not a requirement. When the access network doesn't rely on a
IETF-defined AAA protocol (e.g., RADIUS, Diameter), then it can IETF-defined AAA protocol (e.g., RADIUS, Diameter), then it can
skipping to change at page 7, line 4 skipping to change at page 6, line 52
Protocol MUST support PaCs with multiple interfaces, and networks Protocol MUST support PaCs with multiple interfaces, and networks
with multiple routers on multi-access links. with multiple routers on multi-access links.
4.2.2. Disconnect Indication 4.2.2. Disconnect Indication
PANA MUST NOT assume connection-oriented links. Links may or may not PANA MUST NOT assume connection-oriented links. Links may or may not
provide disconnect indication. Such notification is desirable in provide disconnect indication. Such notification is desirable in
order for the PAA to cleanup resources when a client moves away order for the PAA to cleanup resources when a client moves away
from the network (e.g., inform the enforcement points that the from the network (e.g., inform the enforcement points that the
client is no longer connected). PANA will need to provide a client is no longer connected). PANA SHOULD have a mechanism to
hearbeat-type mechanism to provide this functionality. It's provide disconnect indication.
usage will be optional, depending on the specific L2.
PANA SHOULD provide a hearbeat-type mechanism to allow PaCs to This mechanism must allow PAAs to detect the departure of a PaC from
notify the PAA of their departure from the network. A similar the network. This mechanism SHOULD also allow a PaC to detect the
indication SHOULD also be used to let PAA notify a PaC about the discontinuation of the network access service. Access
discontinuation of the network access. Access discontinuation discontinuation can happen due to various reasons such as network
can happen due to various reasons such as network systems going systems going down, or a change in access policy.
down, or a change in access policy.
Several mechanisms can be used to provide disconnect indication,
e.g., frequent re-authentication; but the use of a heartbeat
function is not recommended.
4.2.3. Location of PAA 4.2.3. Location of PAA
The PAA must be on an IP capable network element on the same The PAA must be on an IP capable network element on the same
IP link as the PaC. Hence it can be on the NAS or WLAN AP or first IP link as the PaC. Hence it can be on the NAS or WLAN AP or first
hop router (most likely scenario). The use of PANA when the PAA is hop router (most likely scenario). The use of PANA when the PAA is
not on the same link as the PAA is outside the scope of PANA. not on the same link as the PAA is outside the scope of PANA.
Since a PaC maynot be pre-configured with the IP address of PAA, Since a PaC maynot be pre-configured with the IP address of PAA,
but may have to dynamically discover instead. Therefore PANA but may have to dynamically discover instead. Therefore PANA
protocol must define a dynamic discovery method. Given that protocol must define a dynamic discovery method. Given that
the PAA is on the same link as the PaC, there are number the PAA is on the same link as the PaC, there are number
of discovery techniques that could be used (e.g., multicast or of discovery techniques that could be used (e.g., multicast or
anycast) by the PaC to find out the address of the PAA. anycast) by the PaC to find out the address of the PAA.
Also, PANA assumes the PAA is co-located with the enforcement PANA does not assumes the PAA is co-located with the enforcement
point. Network access enforcement can be provided by one or more point. Network access enforcement can be provided by one or more
nodes on the same IP subnet as the client (e.g., multiple routers), nodes on the same IP subnet as the client (e.g., multiple routers),
or on another subnet in the access domain (e.g., gateway to the or on another subnet in the access domain (e.g., gateway to the
Internet, depending on the network architecture). When the PAA and Internet, depending on the network architecture). When the PAA and
the enforcement point(s) are separated, there needs to be another the enforcement point(s) are separated, there needs to be another
transport for client provisioning. This transport is needed to transport for client provisioning. This transport is needed to
create access control lists to allow authenticated and authorized create access control lists to allow authenticated and authorized
clients on the enforcement points. This transport is outside the clients on the enforcement points. This WG will identify a
scope of PANA. (preferably existing) protocol solution that allows the PAA
to deliver the authorization information to one or more EPs
when the PAA is separated from EPs.
4.2.4. Secure Channel 4.2.4. Secure Channel
PANA MUST not assume a secure channel between the PaC and the PAA. PANA MUST not assume a secure channel between the PaC and the PAA.
PANA MUST be able to provide authentication especially in networks PANA MUST be able to provide authentication especially in networks
which are not protected against eavesdropping and spoofing. PANA which are not protected against eavesdropping and spoofing. PANA
MUST provide protection against replay attacks on both PaCs and MUST provide protection against replay attacks on both PaCs and
PAAs. PAAs.
Alternatively a combination of PANA with its chosen payload (EAP)
can be used to meet the requirements stated above.
4.3. Interaction with Other Protocols 4.3. Interaction with Other Protocols
Mobility management is outside the scope of PANA. Though, PANA MUST Mobility management is outside the scope of PANA. Though, PANA MUST
be able to co-exist and not interfere with various mobility be able to co-exist and not interfere with various mobility
management protocols, such as Mobile IPv4 [MIPV4], Mobile IPv6 management protocols, such as Mobile IPv4 [MIPV4], Mobile IPv6
[MIPV6], fast handover protocols [FMIPV4, FMIPV6], and other [MIPV6], fast handover protocols [FMIPV4, FMIPV6], and other
standard protocols like IPv6 stateless address auto-configuration standard protocols like IPv6 stateless address auto-configuration
[ADDRCONF] (including privacy extensions [PRIVACY]), and DHCP [ADDRCONF] (including privacy extensions [PRIVACY]), and DHCP
[DHCP]. It MUST NOT make any assumptions on the protocols or [DHCP]. It MUST NOT make any assumptions on the protocols or
mechanisms used for IP address configuration of the PaC. mechanisms used for IP address configuration of the PaC.
skipping to change at page 8, line 22 skipping to change at page 8, line 30
with minimum latency. As an example, a method like minimizing the with minimum latency. As an example, a method like minimizing the
protocol signaling by creating local security associations can be protocol signaling by creating local security associations can be
used for this purpose. used for this purpose.
4.5. Reliability and Congestion Control 4.5. Reliability and Congestion Control
PANA MUST provide reliability and congestion control. It can do so PANA MUST provide reliability and congestion control. It can do so
by using techniques like re-transmissions, cyclic redundancy check, by using techniques like re-transmissions, cyclic redundancy check,
delayed initialization and exponential back-off. delayed initialization and exponential back-off.
In order to satisfy the these requirements, the PANA MAY specify
that high layer protocols, such as EAP, provide these
services
4.6. Miscellaneous 4.6. Miscellaneous
4.6.1. IP Version Independence 4.6.1. IP Version Independence
PANA MUST work for both IPv4 and IPv6. PANA MUST work for both IPv4 and IPv6.
4.6.2. Denial of Service Attacks 4.6.2. Denial of Service Attacks
PANA MUST be robust against a class of DoS attacks such as blind PANA MUST be robust against a class of DoS attacks such as blind
masquerade attacks through IP spoofing that swamp the PAA in masquerade attacks through IP spoofing that swamp the PAA in
spending much resources and prevent legitimate clients attempts of spending much resources and prevent legitimate clients attempts of
network access. network access.
4.6.3. Location Privacy 4.6.3. Location Privacy
Location privacy is outside the scope of PANA. Location privacy is outside the scope of PANA.
4.7. Change Log
Version 03
* In section 4.2.2 the requirement for a heartbeat mechanism to
provide disconnect indication was removed. Rewording of the
section was done
* In section 4.2.3 and 4.1.2 rewording was done to account for
the separation of PAA and EP and the protocol between them.
* In section 4.2.4 new text was added to account for the possibility
to rely on the high layer protocol (EAP) to meet the requirements
stated
* In section 4.5 new text was added to allow reliability and
congestion control to be provided by the payload protocol, e.g.,
EAP.
Acknowledgements Acknowledgements
We would like to thank Basavaraj Patil, Subir Das, and the PANA We would like to thank Basavaraj Patil, Subir Das, and the PANA
Working Group members for their valuable contributions to the Working Group members for their valuable contributions to the
discussions and preparation of this document. discussions and preparation of this document.
References References
[KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
skipping to change at line 444 skipping to change at page 10, line 37
Phone: +1 408 451 4743 Phone: +1 408 451 4743
Email: alper@docomolabs-usa.com Email: alper@docomolabs-usa.com
Yoshihiro Ohba Yoshihiro Ohba
Toshiba America Research, Inc. Toshiba America Research, Inc.
P.O. Box 136 P.O. Box 136
Convent Station, NJ, 07961-0136 Convent Station, NJ, 07961-0136
USA USA
Phone: +1 973 829 5174 Phone: +1 973 829 5174
Email: yohba@tari.toshiba.com Email: yohba@tari.toshiba.com
Reinaldo Penno Reinaldo Penno
Nortel Networks Nortel Networks
4555 Great America Parkway 600 Technology Park
Santa Clara, CA, 95054 Billerica, MA, 01821
USA USA
Phone: +1 408 565 3023 Phone: +1 978 288 8011
Email: rpenno@nortelnetworks.com Email: rpenno@nortelnetworks.com
George Tsirtsis George Tsirtsis
Flarion Technologies Flarion Technologies
Bedminster One Bedminster One
135 Route 202/206 South 135 Route 202/206 South
Bedminster, NJ, 07921 Bedminster, NJ, 07921
USA USA
Phone : +44 20 88260073 Phone : +44 20 88260073
E-mail: G.Tsirtsis@Flarion.com, gtsirt@hotmail.com E-mail: G.Tsirtsis@Flarion.com, gtsirt@hotmail.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/