Network Working Group R. Penno Internet-Draft A. Albuquerque Expires: June, 2001 Nortel Networks January, 2001 A Framework for a User Profile Information Protocol draft-penno-cdnp-nacct-userid-01.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. Abstract We present here a protocol in which edge network equipments, also known as IP Services 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). The User Profile Information Protocol, herein called UPIF, allows services providers, access providers and content delivery networks to provide personalized or differentiated treatment to each user individually, and also to enhance accounting considerably. Penno, et al. [Page 1] Internet-Draft draft-penno-cdnp-nacct-userid-01.txt January,2001 Specification of Requirements The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [1]. Table of Contents 1. Subscriber Awareness. . . . . . . . . . . . . . . . . . . .2 2. Subscriber Awareness and Personalized Services. . . . . . .2 3. Personalized Services and Content Delivery. . . . . . . . .3 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. . . . . . . . . . . . . . . . . . . . .7 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 represents 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. Penno, et al. [Page 2] Internet-Draft draft-penno-cdnp-nacct-userid-01.txt January,2001 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. 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 successful, 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 appropriate) surrogate servers or traffic interception devices the stop time of the session, name@domain and IP address that was in use. Penno, et al. [Page 3] Internet-Draft draft-penno-cdnp-nacct-userid-01.txt 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 subscriber. 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 identify 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 existing similarities between the User Profile Information Protocol and the Radius Accounting Protocol [2] led us to define the UPIF based on the Radius Accounting Protocol definitions. The similarities considered are: Penno, et al. [Page 4] Internet-Draft draft-penno-cdnp-nacct-userid-01.txt January,2001 - The Radius Accounting Protocol is used to carry accounting information between a Network Access Server and a shared Accounting server. The User Profile Information Protocol is used to carry profile information between an edge network equipment and a surrogate server or traffic interception device. - In the RADIUS Protocol, all transactions are comprised of variable length Attribute-Length-Value 3-tuples. This characteristic and the flexibility of adding new attributes suits the UPIF requirements. We antecipate that the new protocol MAY use most of the Radius Accouting protocol state machine but will have different attributes, session start and stop events,and a closest interaction with the Domain Name System. An example of the attribute-value pairs can be seen below. |-------------------------------| |start-time | YYYYMMDD HH:MM UTC| |username | name@domain | |diffserv | AFXDPY | |... | ... | |-------------------------------| 7. Security Considerations We are considering an environment where two or more companies are sharing user information, most times over a public network. In such environments, confidentiality MAY be required, hence some values SHOULD be transmitted encrypted. The encryption support may be object of later discussion about the enhancements the UPIF may have. 8. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March, 1997. [2] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [3] 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, . Penno, et al. [Page 5] Internet-Draft draft-penno-cdnp-nacct-userid-01.txt January,2001 [4] Cooper, I., Melve, I. and G. Tomlinson, "Internet Web Replication and Caching Taxonomy",draft-ietf-wrec-taxonomy- 05.txt (work in progress), June 2000, . [5] Day, M. and D. Gilletti, "CDN Peering Scenarios", draft-day-cdnp-scenarios-02.txt (work in progress), Novmber 2000, . [6] 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, . [7] 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, . [8] 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, . [9] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [11] Penno, R., "Identification of Users on the Internet", draft- penno-cdnp-identification-00.txt. Work in progress, January 2001 9. Acknowledgments To be provided. Penno, et al. [Page 6] Internet-Draft draft-penno-cdnp-nacct-userid-01.txt January,2001 Author's Addresses Reinaldo Penno Nortel Networks, Inc. 2305 Mission College Boulevard Building SC9 San Jose, CA 95134 Email: rpenno@tnortelnetworks.com Andre Gustavo de Albuquerque Nortel Networks, Inc. Av. Lauro Muller, 116 Room 605 Rio de Janeiro, Brazil Email: gustavoa@nortelnetworks.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. 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.