draft-ietf-pana-requirements-01.txt   draft-ietf-pana-requirements-02.txt 
PANA Working Group Alper E. Yegin, Editor PANA Working Group Reinaldo Penno, Editor
INTERNET-DRAFT Yoshihiro Ohba INTERNET-DRAFT Alper E. Yegin
Date: March 2002 Reinaldo Penno Date: June 2002 Yoshihiro Ohba
Expires: September 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-01.txt> <draft-ietf-pana-requirements-02.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 line 43 skipping to change at page 1, line 44
Abstract Abstract
It is expected that future IP devices will have a variety of access It is expected that future IP devices will have a variety of access
technologies to gain network connectivity. Currently there are technologies to gain network connectivity. Currently there are
access-specific mechanisms for providing client information to the access-specific mechanisms for providing client information to the
network for authentication and authorization purposes. In addition network for authentication and authorization purposes. In addition
to being limited to specific access media (e.g., 802.1x for IEEE 802 to being limited to specific access media (e.g., 802.1x for IEEE 802
links), some of these protocols are limited to specific network links), some of these protocols are limited to specific network
topologies (e.g., PPP for point-to-point links). The goal of the topologies (e.g., PPP for point-to-point links). The goal of the
PANA Working Group is to design a general network-layer protocol to PANA is to provide a layer two agnostic and IPv4/IPv6 compatible
authenticate clients to the networks. The protocol will run between client-server protocol that allows a host to be authenticated for
a client's device and an agent device in the network where the agent network access. The protocol will run between a client's device
might be a client of the AAA infrastructure. The protocol should be and an agent device in the network where the agent might be a client
independent of the underlying access-type and not be limited to of the AAA infrastructure. This document defines the common
specific network topologies. This document defines the common
terminology and identifies the requirements for PANA. terminology and identifies the requirements for PANA.
Yegin (Editor), et. al. Expires Sep 2002 [Page 1]
Table of Contents Table of Contents
Status of this Memo...............................................1 Status of this Memo...............................................1
Abstract..........................................................1 Abstract..........................................................1
Table of Contents.................................................2 Table of Contents.................................................2
1. Introduction...................................................2 1. Introduction...................................................2
2. Key Words......................................................3 2. Key Words......................................................3
3. Terminology....................................................4 3. Terminology....................................................4
4. Requirements...................................................4 4. Requirements...................................................4
4.1. Authentication...............................................4 4.1. Authentication...............................................4
skipping to change at line 81 skipping to change at page 2, line 33
4.2.4. Secure Channel.............................................6 4.2.4. Secure Channel.............................................6
4.3. Interaction with Other Protocols.............................6 4.3. Interaction with Other Protocols.............................6
4.4. Performance..................................................7 4.4. Performance..................................................7
4.5. Reliability and Congestion Control...........................7 4.5. Reliability and Congestion Control...........................7
4.6. Miscellaneous................................................7 4.6. Miscellaneous................................................7
4.6.1. IP Version Independence....................................7 4.6.1. IP Version Independence....................................7
4.6.2. Denial of Service Attacks..................................7 4.6.2. Denial of Service Attacks..................................7
4.6.3. Location Privacy...........................................7 4.6.3. Location Privacy...........................................7
Acknowledgements..................................................7 Acknowledgements..................................................7
References........................................................8 References........................................................8
Authors Addresses................................................9 Authors' Addresses................................................9
Full Copyright Statement.........................................10 Full Copyright Statement.........................................10
1. Introduction 1. Introduction
Currently there are a variety of access technologies available to Network access technologies for wired and wireless media are
the network clients. While most of the clients currently have single evolving rapidly. With the rapid growth in the number and type of
interface, it is expected that in the future they will have multiple devices and terminals that support IP stacks and can access the
interfaces of different types to access the network. Internet, users can potentially use a single device having the
capability of attaching via different multiple access media and
technologies to interface to the network.
An authentication mechanism is needed in order to provide secure If a client can have more than one type of interface, using
network access to the legitimate clients. Some of the current access-specific authentication mechanisms leads to running a
authentication mechanisms are access technology specific. For collection of protocols on the client for the same purpose.
example 802.1x [8021X] works for only IEEE 802 link layers. If a
client can have more than one type of interface, using access-
specific authentication mechanisms leads to running a collection of
protocols on the client for the same purpose. It is clearly
Yegin (Editor), et.al. Expires Sep 2002 [Page 2] For example, the authentication mechanisms in PPP are being used
advantageous to use a general protocol to authenticate the client for many wired access scenarios as well as some wireless access,
for network access on any type of technology. which requires using PPP encapsulation for the data packets. Using
PPP just for client authentication is viewed as a sub-optimal
solution as it causes extra round-trips, overhead of encapsulation
and processing,
and forces the network topology into a point-to-point
model. A point in case is PPPoE which is used over multi-access
networks primarily for the purpose of exploiting the authentication
scheme provided by PPP. Also, IEEE 802 relies on 802.1X which
provides EAP authentication that is limited to IEEE 802 link layers.
The most widely used protocol for authenticating clients is the PPP It is clearly advantageous to use a general protocol to authenticate
[PPP]. This protocol can run on various access types, but it the client for network access on any type of technology. There is
provides an inherently point-to-point interface. While it can currently no general protocol to be used by a client for gaining
efficiently be applied to such topologies, using PPP with a multi- network access, and the PANA Working Group will attempt to
access network creates sub-optimal solutions. Such multi-access fill that hole.
networks require either a full mesh of PPP links among clients, or a
designated router as the end-point of PPP links.
There is currently no general protocol to be used by a client for The protocol design will be limited to defining a client-server
gaining network access, and the PANA Working Group will attempt to messaging protocol (i.e., a carrier) that will allow authentication
fill that hole. The Working Group will design a protocol between a payload to be carried between the host/client (PaC) and an
client's device and an agent device in the network where the agent agent/server (PAA) in the access network for authentication and
might be a client of the AAA infrastructure. As a network-layer authorization purposes regardless of the AAA infrastructure that
may (or may not) reside on the network. As a network-layer
protocol, it will be independent of the underlying access protocol, it will be independent of the underlying access
technologies. It will also be applicable to any network topology. technologies. It will also be applicable to any network topology.
The protocol design will be limited to defining a messaging protocol The Working Group will not invent new security protocols and
(i.e., a carrier) for providing the clients' information to the mechanisms but instead will use the existing mechanisms. In
network for authentication and authorization purposes. The Working particular, the Working Group will not define authentication
Group will not invent new security protocols and mechanisms but protocols, key distribution or key agreement protocols, or key
instead will use the existing mechanisms. In particular, the Working derivation. The desired protocol can be viewed as the front-end
Group will not define authentication protocols, key distribution or of the AAA protocol or any other protocol/mechanisms the network
key agreement protocols, or key derivation. The desired protocol can is running at the background to authenticate its clients. It will
be viewed as the front-end of the AAA protocol or any other act as a carrier for an already defined security protocol or
protocol/mechanisms the network is running at the background to mechanism.
authenticate its clients. It will act as a carrier for an already
defined security protocol or mechanism.
As an example, Mobile IP Working Group has already defined such a As an example, Mobile IP Working Group has already defined such a
carrier for Mobile IPv4 [MIPV4]. Mobile IPv4 registration request carrier for Mobile IPv4 [MIPV4]. Mobile IPv4 registration request
message is used as the carrier for authentication extensions (MN-FA message is used as the carrier for authentication extensions (MN-FA
[MIPV4], or MN-AAA [MNAAA]) to receive forwarding service from the [MIPV4], or MN-AAA [MNAAA]) to receive forwarding service from the
foreign agents. In that sense, designing the equivalent of Mobile foreign agents. In that sense, designing the equivalent of Mobile
IPv4 registration request messages for general network access is the IPv4 registration request messages for general network access is the
goal of this work, but not defining the equivalent of MN-FA or MN- goal of this work, but not defining the equivalent of MN-FA or MN-
AAA extensions. AAA extensions.
skipping to change at line 151 skipping to change at page 4, line 5
requirements of a protocol for PANA. These terminology and requirements of a protocol for PANA. These terminology and
requirements will be used to define and limit the scope of the work requirements will be used to define and limit the scope of the work
to be done in this group. to be done in this group.
2. Key Words 2. Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEYWORDS]. document are to be interpreted as described in [KEYWORDS].
Yegin (Editor), et.al. Expires Sep 2002 [Page 3]
3. Terminology 3. Terminology
Device Identifier (DI) Device Identifier (DI)
The identifier used by the network as a handle to control and The identifier used by the network as a handle to control and
police the network access of a client. Depending on the access police the network access of a client. Depending on the access
technology, identifier might contain any of IP address, link- technology, identifier might contain any of IP address, link-
layer address, switch port number, etc. of a device. PANA layer address, switch port number, etc. of a device. PANA
authentication agent keeps a table for binding device authentication agent keeps a table for binding device
identifiers to the PANA clients. At most one PANA client identifiers to the PANA clients. At most one PANA client
skipping to change at line 197 skipping to change at page 4, line 49
by one of the users of the device or the device itself. PANA MUST by one of the users of the device or the device itself. PANA MUST
only grant network access service to the device identified by the only grant network access service to the device identified by the
DI, rather than granting separate access to multiple simultaneous DI, rather than granting separate access to multiple simultaneous
users of the device. Once the network access is granted to the users of the device. Once the network access is granted to the
device, the methods used by the device on arbitrating which one of device, the methods used by the device on arbitrating which one of
its users can access the network is outside the scope of PANA. its users can access the network is outside the scope of PANA.
PANA MUST NOT define new security protocols or mechanisms. Instead PANA MUST NOT define new security protocols or mechanisms. Instead
it must be defined as a "carrier" for such protocols. PANA MUST it must be defined as a "carrier" for such protocols. PANA MUST
identify which specific security protocol(s) or mechanism(s) it can identify which specific security protocol(s) or mechanism(s) it can
carry (the "payload"). An example of a carrier would be the carry (the "payload"). The current thinking is that a sufficient
registration request message of Mobile IPv4 [MIPV4] that carries MN- solution would be for PANA to carry EAP. If PANA WG decides that
FA authentication extension. extensions to EAP are needed, it will define requirements for an
EAP WG instead of defining these extensions.
Authentication and encryption of data traffic sent to and from an Authentication and encryption of data traffic sent to and from an
authenticated PaC is outside the scope of PANA. Providing a complete authenticated PaC is outside the scope of PANA. Providing a complete
Yegin (Editor), et.al. Expires Sep 2002 [Page 4]
secure network access solution by also securing router discovery secure network access solution by also securing router discovery
[RDISC], neighbor discovery [NDISC], and address resolution [RDISC], neighbor discovery [NDISC], and address resolution
protocols [ARP] is outside the scope as well. protocols [ARP] is outside the scope as well.
Both the PaC and the PAA MUST be able to authenticate each other for Both the PaC and the PAA MUST be able to authenticate each other for
network access. Providing capability of only PAA authenticating the network access. Providing capability of only PAA authenticating the
PaC is not sufficient. PaC is not sufficient.
PANA MUST be capable of carrying out both periodic and on-demand re- PANA MUST be capable of carrying out both periodic and on-demand re-
authentication. Both the PaC and the PAA MUST be able to initiate authentication. Both the PaC and the PAA MUST be able to initiate
skipping to change at line 230 skipping to change at page 5, line 32
as the source of the PANA message, the protocol has to make sure as the source of the PANA message, the protocol has to make sure
that the DI's integrity is protected by some other means (e.g., that the DI's integrity is protected by some other means (e.g.,
physical verification of incoming port number of the PANA message in physical verification of incoming port number of the PANA message in
the case of switch port number as a DI and PAA co-located with the the case of switch port number as a DI and PAA co-located with the
link-layer access device). Protecting PaCs against DI theft is link-layer access device). Protecting PaCs against DI theft is
outside the scope of PANA. outside the scope of PANA.
4.1.2. Authorization, Accounting and Access Control 4.1.2. Authorization, Accounting and Access Control
In addition to carrying authentication information, PANA MUST also In addition to carrying authentication information, PANA MUST also
carry a binary result (i.e., success or failure) of authorization provides only a binary authorization to indicate whether the PaC
for network access to the PaC. Providing finer granularity is allowed to access full IP services on the network. Providing
authorization is outside the scope of PANA. finer granularity authorization, such as negotiating QoS parameters,
authorizing individual services (http vs. ssh), individual users
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. PAA MAY communicate the DI associated with a PaC to scope of PANA. Client access authentication should be followed by
other entities in the network to setup access control and accounting access control to make sure only authenticated and authorized
state. This interaction is outside the scope of PANA as well. clients can send and receive IP packets via access network. Access
control can involve setting access control lists on the enforcement
points. Identification of clients which are authorized to access
the network is done by the PANA protocol exchange. Though,
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
PAA MAY use either a AAA backend, some other mechanism or a local PANA protocol MUST NOT make any assumptions on the backend
database to authenticate the PaC. PANA protocol MUST NOT make any authentication protocol or mechanisms. PAA may interact with
assumptions on the backend authentication protocol or mechanisms. backend AAA infrastructures such as RADIUS or Diameter, but it is
not a requirement. When the access network doesn't rely on a
IETF-defined AAA protocol (e.g., RADIUS, Diameter), then it can
still use a proprietary backend system, or rely on the information
locally stored on the authentication agents.
The interaction between the PAA and the backend authentication The interaction between the PAA and the backend authentication
entities is outside the scope of PANA. entities is outside the scope of PANA.
4.1.4. Identifiers 4.1.4. Identifiers
PANA SHOULD allow various types of identifiers to be used for the PANA SHOULD allow various types of identifiers to be used for the
PaC (e.g., NAI, IP address, FQDN, etc.) PaC (e.g., NAI, IP address, FQDN, etc.)
Yegin (Editor), et.al. Expires Sep 2002 [Page 5]
PANA SHOULD allow various types of identifiers to be used as the DI PANA SHOULD allow various types of identifiers to be used as the DI
(IP address, link-layer address, port number of a switch, etc.) (IP address, link-layer address, port number of a switch, etc.)
PAA MUST be able to create a binding between the PaC and the PAA MUST be able to create a binding between the PaC and the
associated DI upon successful PANA exchange. The DI MUST be carried associated DI upon successful PANA exchange. The DI MUST be carried
either explicitly as part of the PANA payload, or implicitly as the either explicitly as part of the PANA payload, or implicitly as the
source of the PANA message, or both. This binding is used for access source of the PANA message, or both. This binding is used for access
control and accounting in the network as described in section 4.1.2. control and accounting in the network as described in section 4.1.2.
4.1.5. IP Address Assignment
PANA does not perform any address assignment functions but MUST
only be invoked after the client has a usable IP address
(e.g., a link-local address in IPv6 or a DHCP-learned address
in IPv4)
4.2. Network 4.2. Network
4.2.1. Multi-access 4.2.1. Multi-access
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. PANA SHOULD define a "disconnect" provide disconnect indication. Such notification is desirable in
indication to allow PaCs to notify the PAA of their departure from order for the PAA to cleanup resources when a client moves away
the network. A similar indication SHOULD also be used to let PAA from the network (e.g., inform the enforcement points that the
notify a PaC about the discontinuation of the network access. Access client is no longer connected). PANA will need to provide a
discontinuation can happen due to various reasons such as network hearbeat-type mechanism to provide this functionality. It's
systems going down, or a change in access policy. usage will be optional, depending on the specific L2.
PANA SHOULD provide a hearbeat-type mechanism to allow PaCs to
notify the PAA of their departure from the network. A similar
indication SHOULD also be used to let PAA notify a PaC about the
discontinuation of the network access. Access discontinuation
can happen due to various reasons such as network systems going
down, or a change in access policy.
4.2.3. Location of PAA 4.2.3. Location of PAA
PAA MAY be one or more hop away from the PaC. PANA MUST define a The PAA must be on an IP capable network element on the same
method used by PaCs for locating the PAAs in a network. 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
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,
but may have to dynamically discover instead. Therefore PANA
protocol must define a dynamic discovery method. Given that
the PAA is on the same link as the PaC, there are number
of discovery techniques that could be used (e.g., multicast or
anycast) by the PaC to find out the address of the PAA.
Also, PANA assumes the PAA is co-located with the enforcement
point. Network access enforcement can be provided by one or more
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
Internet, depending on the network architecture). When the PAA and
the enforcement point(s) are separated, there needs to be another
transport for client provisioning. This transport is needed to
create access control lists to allow authenticated and authorized
clients on the enforcement points. This transport is outside the
scope of PANA.
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.
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
Yegin (Editor), et.al. Expires Sep 2002 [Page 6]
[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.
4.4. Performance 4.4. Performance
PANA design SHOULD give consideration to efficient handling of PANA design SHOULD give consideration to efficient handling of
authentication process. This is important for gaining network access authentication process. This is important for gaining network access
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.
skipping to change at line 331 skipping to change at page 8, line 32
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. The required robustness is no worse than that for network access.
TCP SYN attack.
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.
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.
Yegin (Editor), et.al. Expires Sep 2002 [Page 7]
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.
[8021X] "IEEE Standards for Local and Metropolitan Area Networks: [8021X] "IEEE Standards for Local and Metropolitan Area Networks:
Port Based Network Access Control", IEEE Draft 802.1X/D11, March Port Based Network Access Control", IEEE Draft 802.1X/D11, March
2001. 2001.
[PPP] W. Simpson (editor), "The Point-To-Point Protocol (PPP)", STD [PPP] W. Simpson (editor), "The Point-To-Point Protocol (PPP)", STD
skipping to change at line 389 skipping to change at page 9, line 35
[FMIPV6] G. Dommety (editor), et. al., "Fast Handovers for Mobile [FMIPV6] G. Dommety (editor), et. al., "Fast Handovers for Mobile
IPv6", July 2001. Work in progress. IPv6", July 2001. Work in progress.
[DHCP] R. Droms (editor), et. al., "Dynamic Host Configuration [DHCP] R. Droms (editor), et. al., "Dynamic Host Configuration
Protocol for IPv6", December 2001. Work in progress. Protocol for IPv6", December 2001. Work in progress.
[PRIVACY] T. Narten, R. Draves, "Privacy Extensions for Stateless [PRIVACY] T. Narten, R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001. Address Autoconfiguration in IPv6", RFC 3041, January 2001.
Yegin (Editor), et.al. Expires Sep 2002 [Page 8]
Authors' Addresses Authors' Addresses
Alper E. Yegin Alper E. Yegin
DoCoMo USA Labs DoCoMo USA Labs
181 Metro Drive, Suite 300 181 Metro Drive, Suite 300
San Jose, CA, 95110 San Jose, CA, 95110
USA USA
Phone: +1 408 451 4743 Phone: +1 408 451 4743
Email: alper@docomolabs-usa.com Email: alper@docomolabs-usa.com
skipping to change at line 408 skipping to change at line 444
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
2305 Mission College Boulevard 4555 Great America Parkway
Santa Clara, CA, 95054 Santa Clara, CA, 95054
USA USA
Phone: +1 408 565 3023 Phone: +1 408 565 3023
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
skipping to change at line 434 skipping to change at line 469
E-mail: G.Tsirtsis@Flarion.com, gtsirt@hotmail.com E-mail: G.Tsirtsis@Flarion.com, gtsirt@hotmail.com
Cliff Wang Cliff Wang
Smart Pipes Smart Pipes
565 Metro Place South 565 Metro Place South
Dublin, OH, 43017 Dublin, OH, 43017
USA USA
Phone: +1 614 923 6241 Phone: +1 614 923 6241
Email: cwang@smartpipes.com Email: cwang@smartpipes.com
Yegin (Editor), et.al. Expires Sep 2002 [Page 9]
Full Copyright Statement Full Copyright Statement
"Copyright (C) The Internet Society (2002). All Rights Reserved. "Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
skipping to change at line 462 skipping to change at line 495
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Yegin (Editor), et.al. Expires Sep 2002 [Page 10]
 End of changes. 

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