One document matched: draft-penno-cdnp-nacct-userid-00.txt
<Working Group Name> R. Penno
Internet-Draft NortelNetworks
Expires: June, 2001 January, 2001
Category:Informational
A Framework for a User Profile Information Protocol
draft-penno-cdnp-nacct-userid-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum
of six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as 'work in
progress.' The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Discussion List & Archives
This document and related documents are discussed on the cdn mailing
list. To join the list, send mail to cdn-request@ops.ietf.org. To
contribute to the discussion, send mail to cdn@ops.ietf.org. The
archives are at ftp://ops.ietf.org/pub/lists/cdn.*.
Abstract
We present here a protocol in which edge network equipments, also
known as IPServices devices, Broadband RASes, Edge Routers and
so forth, can inform surrogates or traffic interception devices
extended information about the user, such as geographic location,
QoS policy, fully qualified login (name@domain.name)and start and
stop times (or its equivalent for non-session based users).
This protocol allows services provider, access providers and content
delivery networks to provide personalized or differentiated
treatment to each user individually, and also to enhance accounting
considerably.
Penno, R. [Page 1]
Internet-Draft User Profile Identification Protocol January,2001
Table of Contents
1. Subscriber Awareness. . . . . . . . . . . . . . . . . . . .2
2. Subscriber Awareness and Personalized Services. . . . . . .2
3. Personalized Services and Content Delivery. . . . . . . . .2
4. Framework for Session based users. . . . . . . . . . . . . 3
5. Framework for Non-Session based users. . . . . . . . . . . 4
6. Proposed Protocol. . . . . . . . . . . . . . . . . . . . . 4
7. Security Considerations. . . . . . . . . . . . . . . . . . 5
8. References. . . . . . . . . . . . . . . . . . . . . . . . .5
9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . 6
Author's Addresses. . . . . . . . . . . . . . . . . . . . .6
Full Copyright Statement. . . . . . . . . . . . . . . . . .7
1. Subscriber Awareness
Today there is a new class of devices that sit on the edge of the
network (between the access and the core), and represent the last
point on a network that there is subscriber awareness. One should
understand subscribers awareness as the capability to infer who is
the actual user on the network and his profile.
Examples of the identity of the user are (but not limited to) source
IP address or name@domain (PPPoE based) for Cable users, ATM VC or
name@domain (PPPoE or PPPoA based) for DSL users, name@domain (PPP
based) for dial-up subscribers, DS0 channels or a IP network for
leased line users.
The profile of the user may include (but is not limited to) QoS
parameters, geographic location, start and stop times (or its
equivalent for non-session based users), IP address in use.
2. Subscriber Awareness and Personalized Services
Since these devices know exactly who the subscriber is, they can
control the access of these subscribers to the network and offer
personalized services on an per user basis. Example of these
services are (but not limited to) traffic shaping, Diffserv marking
and policing, firewall and VPNs.
3. Personalized Services and Content Delivery
There is a lot of effort going on to standardize methods for
content-delivery, distribution, accounting and request-routing.
Penno, R. Draft-Expires June 2001 [Page 2]
Internet-Draft User Profile Identification Protocol January,2001
Although one can expect an major improvement on content delivery in
general from this effort, these will be done on a coarse level. We
believe that with the kind of information an edge device can pass to
a surrogate server or a traffic interception device, the delivery
and accounting of content can be done on a much more granular
level, on a per subscriber basis. This open up a whole new set of
possibilities of content delivery.
4. Framework for Session based users
We present here a framework of how the protocol would work for
session based users. Session based users include those that access
the network through one of the following (but not limited to)
protocols: Dial-up PPP, PPPoE, PPPoA and L2TP.
|------------|
4,5 |Traffic |
----->|Interception|
2,3 / |Device |
|------| 1 |------|_/ |------------|
| User |---->Access----->| Edge |
|------| Network |Device|_
|------| \
\ 4,5 |---------|
----->|Surrogate|
|Server |
|---------|
1. The user establishes a PPP session to the Edge Device
2. Edge device authenticates user locally or on an external server
such as a Radius or LDAP database.
3. If authentication sucessful, the Edge Device applies the services
associated to this user profile to his session.
4. The Edge device then package some or all the information that it
has about the user and sends it to one or more traffic
interception devices or surrogate servers.
The type of information the edge device MAY send is start time of
the session, name@domain, Diffserv policy, IP address in use and
geographic location. Of course this can be expanded to accommodate
several other useful parameters.
5.When the user is disconnected, the edge device MAY inform (as
approriate) surrogate servers or traffic interception devices the
stop time of the session, name@domain and IP adress that was in
use.
Penno, R. Draft-Expires June 2001 [Page 3]
Internet-Draft User Profile Identification Protocol January,2001
5. Framework for Non-Session based users
The framework for non-session based users is the same as for session
based users. What changes is the type of information you can pass to
other devices and the accuracy of identification of the subscriber.
For instance, if DSL provider A does not require that its users
access the network through some session based protocol such as
PPPoE, this means that a edge device could identify the subscriber
by ATM VC of his DSL modem or the source IP address of his personal
computer.
This method of course means that in the case of identification by
the ATM VC, all users behind the modem would be treated as the same
susbcriber. They are invisible to the edge device. One way to
address this is to identify the subscriber by its source IP address
so that if there are several personal computers behind a DSL modem,
a edge device could apply different services to each one.
The later solution also has a drawback when N:M NAT is used or when
several users share the same personal computer. The drawback when
N:M NAT is used is pretty straightforward. Since there is a device
translating several source IP address into some other subset, this
implies a loss of granularity on the identification of the actual
user.
In the case where several users share the same personal computer,
there is no way to differentiate when a particular user stopped
using and a new one started. One solution could be the use of some
web login method (similar to web mail used today). In other words,
when user A sits on his shared personal computer, he has to go to a
specific web page and put his username and password, which would be
passed to the edge device, allowing it to accurately identifiy the
subscriber and apply his personalized services. More on
identification of users can be found in [Identity]
In the cases where there is no web login, the start of the session
would be when the first packet with a specific source IP address or
that through a specific ATM VC reaches the edge device. The stop of
the session would be based on some idle or session timeout.
6. Proposed Protocol
The Radius Accounting Protocol is used to for carrying accounting
information between a Network Access Server and a shared Accounting
server. The User Profile Information Protocol is used to carry
profile information, which cab be used to offer personalized services
and to enahnce accounting, between an edge network equipment and a
suurogate server or traffic interception device .
Penno, R. Draft-Expires June 2001 [Page 4]
Internet-Draft User Profile Identification Protocol January,2001
The similarity between the two protocols is obvious, and hence the
User Profile Information Protocol could be modeled after the Radius
Accounting Protocol. Another similarity is that the Radius Accounting
protocol was made to pass tuples of attribute-value, which would suit
the User Information Protocol. For instance
|-------------------------------|
|start-time | YYYYMMDD HH:MM UTC|
|username | name@domain |
|diffserv | AFXDPY |
|... | ... |
|-------------------------------|
7. Security Considerations
To be provided.
8. References
[1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999,
<URL:http://www.rfc-editor.org/rfc/rfc2616.txt>.
[2] Cooper, I., Melve, I. and G. Tomlinson, "Internet Web
Replication and Caching Taxonomy",draft-ietf-wrec-taxonomy-
05.txt (work in progress), June 2000,
<URL:http://www.ietf.org/internet-drafts/draft-ietf-wrec-
taxonomy-05.txt>.
[3] Day, M. and D. Gilletti, "CDN Peering Scenarios",
draft-day-cdnp-scenarios-02.txt (work in progress), Novmber
2000,
<URL:http://www.ietf.org/internet-drafts/draft-day-cdnp-
scenarios-02.txt>.
[4] Gilletti, D., Nair, R. and J. Scharber, "CDN Peering
Authentication, Authorization, and Accounting Requirements",
draft-gilletti-cdnp-aaa-reqs-00.txt (work in progress),
November 2000,
<URL:http://www.ietf.org/internet-drafts/draft-gilletti-cdnp-
aaa-reqs-00.txt>.
[5] Green, M., Cain, B., Tomlinson, G. and S. Thomas, "CDN Peering
Architectural Overview", draft-green-cdnp-gen-arch-02.txt (work
in progress), November 2000,
<URL:http://www.ietf.org/internet-drafts/draft-green-cdnp-gen-
arch-02.txt>.
Penno, R. Draft-Expires June 2001 [Page 5]
Internet-Draft User Profile Identification Protocol January,2001
[6] Cain, B., Douglis, F., Green, M., Hoffmann, M., Nair, R.,
Potter, D. and O. Spatscheck, "Known CDN Request-Routing
Mechanisms", draft-green-cdnp-gen-arch-02.txt (work in
progress), November 2000,
<URL:http://www.ietf.org/internet-drafts/draft-cain-cdnp-known-
request-routing-00.txt>.
[7] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
[9] Penno, R., "Identification of Users on the Internet", draft-
penno-cdnp-identification-00.txt. Work in progress, January
2001
9. Acknowledgments
To be provided.
Author's Addresses
Reinaldo Penno
NortelNetwork, Inc.
2305 Mission College Boulevard
Building SC9
San Jose, CA 95134
Email: rpenno@tnortelnetworks.com
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
Penno, R. Draft-Expires June 2001 [Page 6]
Internet-Draft User Profile Identification Protocol January,2001
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
Penno, R. Draft-Expires June 2001 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-24 04:48:08 |