Network Working Group R. Penno
Internet-Draft A. Albuquerque
Expires: October, 2001 Nortel Networks
April, 2001
User Profile Information Protocol
draft-penno-cdnp-nacct-userid-03.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, and so forth, can
inform surrogates, network edge proxy servers 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-03.txt March,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. Definitions. . . . . . . . . . . . . . . . . . . . . . . . 3
2. Subscriber Awareness. . . . . . . . . . . . . . . . . . . .3
3. Subscriber Awareness and Personalized Services. . . . . . .4
4. Personalized Services and Content Delivery. . . . . . . . .4
5. Framework for Session based users. . . . . . . . . . . . . 4
6. Framework for Non-Session based users. . . . . . . . . . . 5
7. Proposed Protocol. . . . . . . . . . . . . . . . . . . . . 6
8. Packet Format. . . . . . . . . . . . . . . . . . . . . . . 6
9. Packet Types. . . . . . . . . . . . . . . . . . . . . . . .8
9.1 Profile-Information. . . . . . . . . . . . . . . . . . . . 9
9.2 Profile-Response. . . . . . . . . . . . . . . . . . . . . 10
10. Attributes. . . . . . . . . . . . . . . . . . . . . . . . 11
10.1 Subscriber-Name. . . . . . . . . . . . . . . . . . . . . .11
10.2 Edge-Device-IP-Address. . . . . . . . . . . . . . . . . . 12
10.3 Edge-Device-Port. . . . . . . . . . . . . . . . . . . . . 13
10.4 Subscriber-IP-Address. . . . . . . . . . . . . . . . . . .13
10.5 Subscriber-IP-Netmask. . . . . . . . . . . . . . . . . . .14
10.6 Profile-Status-Type. . . . . . . . . . . . . . . . . . . .15
10.7 Session-Timeout. . . . . . . . . . . . . . . . . . . . . .16
10.8 Idle-Timeout. . . . . . . . . . . . . . . . . . . . . . . 16
10.9 DiffServ-Code-Point. . . . . . . . . . . . . . . . . . . .17
10.10 ISP-Name. . . . . . . . . . . . . . . . . . . . . . . . . 17
10.11 ISP-Service-Package. . . . . . . . . . . . . . . . . . . .18
10.12 Geodetic Granularity. . . . . . . . . . . . . . . . . . . 19
10.12 Geodetic-Latitude. . . . . . . . . . . . . . . . . . . . .21
10.13 Geodetic-Longitude. . . . . . . . . . . . . . . . . . . . 21
10.14 Upstream Bandwidth. . . . . . . . . . . . . . . . . . . . 22
10.15 Downstream Bandwidth. . . . . . . . . . . . . . . . . . . 23
11. Security Considerations. . . . . . . . . . . . . . . . . .24
12. References. . . . . . . . . . . . . . . . . . . . . . . . 24
13. Acknowledgments. . . . . . . . . . . . . . . . . . . . . .25
Author's Addresses. . . . . . . . . . . . . . . . . . . . 25
Full Copyright Statement. . . . . . . . . . . . . . . . . 25
Penno, et al. [Page 2]
Internet-Draft draft-penno-cdnp-nacct-userid-03.txt March,2001
1. Definitions
User: A unique person that has access to the Internet or some other
IP network. One or more user can be treated as a single
subscriber.
Subscriber: A logical unit to which services are applied. It can
be (but not limited to) a ATM VC, a IP address or a PPP session. A
subscriber can composed of one of more users.
Subscriber Granularity: This is a measure of how accurate the
subscriber identification can be.
o If each subscriber corresponds to a unique user we can say
that this is the highest level of granularity the subscriber
identification can reach.
o If each subscriber corresponds to a personal computer or any
logical device that is shared by more than one person, we say
that the network can provide a medium level granularity of
subscriber identification.
o If each subscriber corresponds to a logical connection or
device that is shared by a company or corporation, we say that
this is the lowest level granularity of subscriber
identification.
Server: The Edge Device or any device in the network that has
knowledge of the subscriber's profile, start and stop session times
and the correspondence between users and subscriber.
Client: A surrogate server, proxy server, raffic interception or
any other device in the network that is going to receive subscriber
profile information in order to provide customized services.
2. 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, or 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) and IP address in use.
Penno, et al. [Page 3]
Internet-Draft draft-penno-cdnp-nacct-userid-03.txt March,2001
3. 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, VPNs, traffic steering (allowing some custom
applications, such as anti-virus scanning in some selected
subscriber's mail traffic), and personal portals.
4. Personalized Services and Content Delivery
There is a lot of effort going on to standardize methods for
content-delivery, distribution, accounting and request-routing
[3-8]. 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 for content delivery and personalization.
5. Protocol Operation for Session based subscribers
We present here a framework of how the protocol would work for
session based subscriber. Session based subscribers 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 |------|_/ |------------|
| Subs |---->Access----->| Edge |
|------| Network |Device|_
|------| \
\ 4,5 |---------|
----->|Surrogate|
|or proxy |
|Server |
|---------|
1. The subscriber establishes a PPP session to the Edge Device
2. Edge device authenticates the subscriber 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 subscriber profile to his session.
Penno, et al. [Page 4]
Internet-Draft draft-penno-cdnp-nacct-userid-03.txt March,2001
4. The Edge device then package some or all the information that it
has about the subscriber and sends it to one or more traffic
interception devices, surrogate or proxy servers. If the profile
of the subscriber changes within a session, the Edge Device MAY
send a update message.
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 subscriber is disconnected, the edge device MUST inform
(as appropriate) proxy servers, surrogate servers or traffic
interception devices the stop time of the session, name@domain and
IP address that was in use.
6. Protocol Operation for Non-Session based subscribers
The framework for non-session based subscribers is the same as for
session based subscribers. 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.
Penno, et al. [Page 5]
Internet-Draft draft-penno-cdnp-nacct-userid-03.txt March,2001
More on identification of users can be found in [11]
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.
7. 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:
- 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.
8. Packet Format
Exactly one UPIF packet is encapsulated in the UDP Data field [4],
where the UDP Destination Port field indicates <port> (decimal).
When a reply is generated, the source and destination ports are
reversed.
A summary of the UPIF data format is shown below. The fields are
transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Penno, et al. [Page 6]
Internet-Draft draft-penno-cdnp-nacct-userid-03.txt March,2001
Code
The Code field is one octet, and identifies the type of UPIF
packet. When a packet is received with an invalid Code field, it
is silently discarded.
UPIF Codes (decimal) are assigned as follows:
1 Profile-Information
2 Profile-Response
Identifier
The Identifier field is one octet, and aids in matching updates
and replies. The client can detect a duplicate request if
it has the same client source IP address and source UDP port and
Identifier within a short span of time.
Length
The Length field is two octets. It indicates the length of the
packet including the Code, Identifier, Length, Authenticator and
Attribute fields. Octets outside the range of the Length field
MUST be treated as padding and ignored on reception. If the
packet is shorter than the Length field indicates, it MUST be
silently discarded. The minimum length is 20 and maximum length
is 4095.
Authenticator
The Authenticator field is sixteen (16) octets. The most
significant octet is transmitted first. This value is used to
authenticate the messages between the UPIF Server to an UPIF
client.
Request Authenticator
In Profile-Information Packets, the Authenticator value is a 16
octet MD5 [12] checksum, called the Request Authenticator.
Penno, et al. [Page 7]
Internet-Draft draft-penno-cdnp-nacct-userid-03.txt March,2001
All implementations of Request Authenticator MUST support manual
keying. It is used extensively in RADIUS implementations. In
manual keying, two sides agree on the secret to be used in the
MD5 checksum offline. The process of assigning the shared secret
is manual. Needless to say, this process is error-prone,
cumbersome, insecure, and does not scale. Another limiting factor
is that the trust relationship never expires. Once it is created,
it remains good until it is changed in both sides. Manual keying
is a useful feature for debugging the base UPIF protocol when the
key management protocol is failing. However, with a stable key
management protocol, the use of manual keying is questionable.
In an environment where UPIF is deployed, manual keying
implementation MUST be available. The availability of a key
management protocol, such as ISAKMP [13], SHOULD be included.
The UPIF client and server share a key. The Request Authenticator
field in Profile-Information packets contains a one- way MD5 hash
calculated over a stream of octets consisting of the Code +
Identifier + Length + 16 zero octets + request attributes +
shared secret (where + indicates concatenation). The 16 octet
MD5 hash value is stored in the Authenticator field of the
Profile-Information packet.
Response Authenticator
The Authenticator field in an Profile-Response packet is called
the Response Authenticator, and contains a one-way MD5 hash
calculated over a stream of octets consisting of the Profile-
Response Code, Identifier, Length, the Request Authenticator
Field from the Profile-Information packet being replied to, and
the response attributes if any, followed by the shared secret.
The resulting 16 octet MD5 hash value is stored in the
Authenticator field of the Profile-Response packet.
All the considerations about manual keying or the use of a key
management protocol stated above are valid for the Response
Authenticator implementation.
Attributes
Attributes may have multiple instances, in such a case the order
of attributes of the same type SHOULD be preserved. The order of
attributes of different types is not required to be preserved.
9. Packet Types
The UPIF packet type is determined by the Code field in the first
octet of the packet.
Penno, et al. [Page 8]
Internet-Draft draft-penno-cdnp-nacct-userid-03.txt March,2001
9.1 Profile-Information
Description
Profile-Information packets are used to transfer subscriber
profile information from a UPIF Information Server (usually a
edge device) to a client (usually a traffic interception device,
surrogate or proxy server). This information is used to provide
personalized content and services to the subscriber. The server
transmits an UPIF packet with the Code field set to 1
(Information).
A summary of the Update packet format is shown below.
The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Request Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
1 for Profile-Information
Identifier
The Identifier field MUST be changed whenever the content of the
Attributes field changes, and whenever a valid reply has been
received for a previous request. For retransmissions where the
contents are identical, the Identifier MUST remain unchanged.
Request Authenticator
The Request Authenticator value MUST be changed each time a new
Identifier is used.
Attributes
The Attribute field is variable in length, and contains the list
of Attributes that are required for the type of service, as well
as any desired optional Attributes.
Penno, et al. [Page 9]
Internet-Draft draft-penno-cdnp-nacct-userid-03.txt March,2001
9.2 Profile-Response
Description
Profile-Response packets are sent by the UPIF client, and provide
acknowledgment that the Profile-Information message was received
sucessfully.
On reception of an Profile-Response, the Identifier field is
matched with a pending Profile-Information. The Response
Authenticator field MUST contain the correct response for the
pending Profile-Information. Invalid packets are silently
discarded.
A summary of the Profile-Reponse packet format is shown below. The
fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Response Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
2 for Profile-Response.
Identifier
The Identifier field is a copy of the Identifier field of the
Profile-Information which caused this Profile-Response.
Response Authenticator
The Response Authenticator value is calculated from the Access-
Request value, as described earlier.
Attributes
The Attribute field is variable in length, and contains a list of
zero or more Attributes.
Penno, et al. [Page 10]
Internet-Draft draft-penno-cdnp-nacct-userid-03.txt March,2001
10. Attributes
UPIF Attributes carry the specific information and configuration
details for the information and reply messages.
10.1 Subscriber-Name
Description
This Attribute indicates the name of the subscriber.
It MUST be sent in Profile-Informations packets if available.
A summary of the User-Name Attribute format is shown below. The
fields are transmitted from left to right.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
1 for Subscriber-Name.
Length
>= 3
String
The String field is one or more octets. The Edge Device may limit
the maximum length of the User-Name but the ability to handle at
least 63 octets is recommended.
The format of the username MAY be one of several forms:
text Consisting only of UTF-8 encoded 10646 [7] characters.
network access identifier
A Network Access Identifier as described in RFC 2486
[8].
distinguished name
A name in ASN.1 form used in Public Key authentication
systems.
Penno, et al. [Page 11]
Internet-Draft draft-penno-cdnp-nacct-userid-03.txt March,2001
10.2 Edge-Device-IP-Address
Description
This Attribute indicates the identifying IP Address of the Edge
Device which is informing the profile of the subscriber, and
SHOULD be unique to the Edge Device within the scope of the UPIF
client.
Either Edge-Device-IP-Address or Edge-Device-Identifier MUST be
present in an Profile-Information packet.
If the Edge Device uses the concept of Virtual Routers (VR), the
Edge-Device-IP-Address informed MUST be associated to the VR the
subscriber is part of.
Note that Edge-Device-IP-Address MUST NOT be used to select the
shared secret used to authenticate the update. The source IP
address of the Profile-Information packet MUST be used to select
the shared secret.
A summary of the Edge-Device-IP-Address Attribute format is shown
below. The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
2 for Edge-Device-IP-Address.
Length
6
Address
The Address field is four octets.
Penno, et al. [Page 12]
Internet-Draft draft-penno-cdnp-nacct-userid-03.txt March,2001
10.3 Edge-Device-Port
Description
This Attribute indicates the physical port number of the Edge
Device which is authenticating the subscriber. Note that this is
using "port" in its sense of a physical connection on the Edge
Device, not in the sense of a TCP or UDP port number. Either
Edge-Device-Port or Edge-Device-Port-Type (61) or both SHOULD be
present in an Profile-Information packet, if the Edge Device
differentiates among its ports.
A summary of the Edge-Device-Port Attribute format is shown below.
The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
3 for Edge-Device-Port.
Length
6
Value
The Value field is four octets.
10.4 Subscriber-IP-Address
Description
This Attribute indicates the address the subscriber uses to
access the Internet. It MUST be used in Profile-Information
packets.
A summary of the Subscriber-IP-Address Attribute format is shown
below. The fields are transmitted from left to right.
Penno, et al. [Page 13]
Internet-Draft draft-penno-cdnp-nacct-userid-03.txt March,2001
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
4 for Subscriber-IP-Address.
Length
6
Address
The Address field is four octets.
10.5. Subscriber-IP-Netmask
Description
This Attribute indicates the IP netmask associated to the
Subscriber-IP-Adress attribute. It MUST be used in Profile-Update
packets if the subscriber is associated to more than one IP
address at the same time, for example, when the subcriber in the
Edge Device's point of view is a network. If the
Subscriber-IP-Netmask is not present in the Profile-Information
packet, it is assumed a 32 bits netmask, in other words, it is
assumed the subscriber is associated to a single IP address.
A summary of the Subscriber-IP-Netmask Attribute format is shown
below. The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
5 for Subscriber-IP-Netmask.
Penno, et al. [Page 14]
Internet-Draft draft-penno-cdnp-nacct-userid-03.txt March,2001
Length
6
Address
The Address field is four octets specifying the IP netmask of the
subscriber.
10.6 Profile-Status-Type
Description
This attribute indicates whether this Profile-Information marks
the beginning of the subscriber service (Start), change of a
subscriber profile in the middle of a session or the end (Stop).
Several edge devices allow the subscriber to change parameters
for his session like (but not limited to) upstream and downstream
bandwidth, diffserv marking and ISP Service package during a
session. So the Interim-Update type would be used to indicate
other devices in the network the the original profile informed
for a particular subscriber have changed.
A Profile-Update message with a Profile-Status-Type equal to
Update MUST inform the changed attributes of the subscriber
A summary of the Profile-Status-Type attribute format is shown
below. The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
6 for Profile-Status-Type.
Length
6
Penno, et al. [Page 15]
Internet-Draft draft-penno-cdnp-nacct-userid-03.txt March,2001
Value
The Value field is four octets.
1 Start
2 Stop
3 Interim-Update
10.7 Session-Timeout
Description
This Attribute sets the maximum number of seconds of service will
be provided to the subscriber by the Edge Device before
termination of the session or prompt. This Attribute is available
to be sent by the server to the client in an Profile-Information
message.
A summary of the Session-Timeout Attribute format is shown below.
The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
7 for Session-Timeout.
Length
6
10.8 Idle-Timeout
Description
This Attribute sets the maximum number of consecutive seconds of
idle connection allowed to the subscriber before termination of
the session or prompt.
Penno, et al. [Page 16]
Internet-Draft draft-penno-cdnp-nacct-userid-03.txt March,2001
A summary of the Idle-Timeout Attribute format is shown below. The
fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
8 for Idle-Timeout.
Length
6
Value
The field is 4 octets, containing a 32-bit unsigned integer with
the maximum number of consecutive seconds of idle time this
subscriber should be permitted before being disconnected by the
Edge Device.
10.9 DiffServ-Code-Point
Description
This attribute indicates the a specific value of the DSCP portion
of the DS field, used to select a Per Hop Behavior.
The DS field is the IPv4 header TOS octet or the IPv6 Traffic
Class octet when interpreted in conformance with the definition
given in [DSFIELD]. The bits of the DSCP field encode the DS
codepoint, while the remaining bits are currently unused.
[TBD]
10.10 ISP-Name
Description
This Attribute indicates the ISP which is providing Internet
access to the subscriber.
It MUST be sent in Profile-Informations packets if available.
Penno, et al. [Page 17]
Internet-Draft draft-penno-cdnp-nacct-userid-03.txt March,2001
A summary of the ISP-Name Attribute format is shown below. The
fields are transmitted from left to right.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
10 for ISP-Name.
Length
>= 3
String
The String field is one or more octets. The ED may limit the
maximum length of the User-Name but the ability to handle at
least 63 octets is recommended.
The format of the username MAY be one of several forms:
text Consisting only of UTF-8 encoded 10646 [7] characters.
network access identifier
A Network Access Identifier as described in RFC 2486
[8].
distinguished name
A name in ASN.1 form used in Public Key authentication
systems.
10.11 ISP-Service-Package
[TBD]
Penno, et al. [Page 18]
Internet-Draft draft-penno-cdnp-nacct-userid-03.txt March,2001
10.12 Geodetic-Granularity
Description
The geodetic location of anything on Earth may be indicated by
its geodetic coordinates, which are Latitude and Longitude. The
Geodetic-Granularity, Geodetic-Latitude, and Geodetic-Longitude
attributes are used to define the actual position of a
subscriber. But, there is no reason to know the exact location of
a subscriber at a given time. Our purpose with this kind of
identification is to gather some useful data based on location
and to provide an even more personalized or regional content to
all subscribers within our network.
Is is worth noticing that this attribute allows the delivery of
subscriber specific regional data even if the proxy or surrogate
server providing the content is not on the same area as
the subscriber.
A Geographic Information System (GIS) MAY be used to gather
whatever information I may want based on geographic location
linked to an appropriate database. Some statistical information
about subscribers in a certain region, such as language, age,
income, culture, and a myriad of other data can be useful to
enhance the subscriber experience.
The precision of the geographic position of a subscriber may vary
depending on the identification requirements and available
information about some region in the planet.
It would be quite complex to build a system which could map the
subscriber's latitude and longitude to a specific data with a
high level of accuracy. The definition of the latitude and
longitude allows the specification of the precision needed in
order to gather the required information from a GIS.
The Geodetic-Granulariry attribute defines the precision of the
position information provided by the Geodetic-Latitude and
Geodetic-Longitude attributes. The precision is defined by the
number of seconds, which composes the "identification area",
i.e., the larger area which contains all the information needed
to provide the required subscriber's experience.
The Geodetic-Granularity MAY vary from 1 to 60". The length of a
degree of Geodetic Latitude or Geodetic Longitude varies from
Equator to Pole. The term Geodetic (loosely speaking: Geographic)
refers to the mathematical surface used to approximate the actual
shape of the Earth, which is an ellipsoid. Each second defines an
approximate 934 m^2 area, at a Latitude of 0 degrees.
Penno, et al. [Page 19]
Internet-Draft draft-penno-cdnp-nacct-userid-03.txt March,2001
The table [14] bellow illustrates the variation considering an
area of 10 degrees x 10 degrees:
Latitude Area (Km^2) Length of Length of
(degrees) a degree of a degree of
Geodetic Geodetic
Longitude (on Longitude (on
the WGS 84 the WGS 84
Ellipsoid)-KM Ellipsoid)-KM
0 1224480 110.57 111.32
10 1188528 110.61 109.64
20 1117359 110.70 104.65
30 1011480 110.85 96.49
40 875136 111.04 85.39
50 711510 111.23 71.70
60 525312 111.41 55.80
70 322195 111.56 38.19
80 108584 111.66 19.39
90 111.69 0
A summary of the Geodetic-Granularity Attribute format is shown
below. The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
12 for Geodetic-Granularity
Length
6
Value
The Value field is four octets.
Penno, et al. [Page 20]
Internet-Draft draft-penno-cdnp-nacct-userid-03.txt March,2001
10.13 Geodetic-Latitude
The Geodetic-Latitude contains the subscriber latitude information,
with the precision indicated by the Geodetic-Granularity
attribute. Read the Geodetic-Granularity definition above to have
the big picture of the "Geodetic" Attributes.
A summary of the Geodetic-Latitude Attribute format is shown
below. The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
13 for Geodetic-Latitude
Length
6
Value
The Value field is a string of 9 octets and has the following
format:
[+-]gg:mm:ss (gg => degrees, mm => minutes, ss => seconds)
The first field MUST be a minus sign (-) or a plus sign (+).
(+) => N (North of the Equator Parallel)
(-) => S (South of the Equator Parallel)
10.14 Geodetic-Longitude
The Geodetic-Longitude contains the subscriber longitude
information, with the precision indicated by the
Geodetic-Granularity attribute. Read the Geodetic-Granularity
definition above to have the big picture of the "Geodetic"
Attributes.
Penno, et al. [Page 21]
Internet-Draft draft-penno-cdnp-nacct-userid-03.txt March,2001
A summary of the Geodetic-Longitude Attribute format is shown
below. The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
14 for Geodetic-Longitude
Length
6
Value
The Value field is a string of 10 octets and has the following
format:
[+-]ggg:mm:ss (ggg => degrees, mm => minutes, ss => seconds)
The first field MUST be a minus sign (-) or a plus sign (+).
(+) => EGr (East of Greenwich Meridian)
(-) => WGr (West of Greenwich Meridian)
10.15 Upstream-Bandwidth
Description
This Attribute indicates the Layer 3 upstream bandwidth
(subscriber->Internet) available to the subscriber in kbps. In
some networks such as xDSL this bandwidth may be the same as the
Layer 2 bandwidth available to the subscriber.
This attributes allows traffic interception devices to apply the
same upstream bandwidth policy as the IP Services Switch.
A summary of the Upstream-Bandwidth attribute format is shown
below. The fields are transmitted from left to right.
Penno, et al. [Page 22]
Internet-Draft draft-penno-cdnp-nacct-userid-03.txt March,2001
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
15 for Upstream-Bandwidth.
Length
6
Value
The Value field is four octets.
10.16 Downstream-Bandwidth
Description
This Attribute indicates the Layer 3 downstream bandwidth
(Internet->subscriber) available to the subscriber in kbps. In
some networks such as xDSL this bandwidth may be the same as the
Layer 2 bandwidth available to the subscriber.
This attributes allows traffic interception devices to apply the
same downstream bandwidth policy as the IP Services Switch. This
attribute also allows surrogate and proxy servers to adapt the
requested web content to the users downstream bandwidth. If
adaption is not available it is possible to allow the user to see
the content anyway, present a web page suggesting that the user
upgrades his bandwidth or upgrade his bandwidth on-demand through
some signalling protocol between the proxy or surrogate server
and the IP Services Switch.
A summary of the Upstream-Bandwidth attribute format is shown
below. The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Penno, et al. [Page 23]
Internet-Draft draft-penno-cdnp-nacct-userid-03.txt March,2001
Type
16 for Downstream-Bandwidth.
Length
6
Value
The Value field is four octets.
11. 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.
12. 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,
<URL:http://www.rfc-editor.org/rfc/rfc2616.txt>.
[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
Penno, et al. [Page 24]
Internet-Draft draft-penno-cdnp-nacct-userid-03.txt March,2001
[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] A. Beck et al, "Example Services for Network Edge Proxies",
draft-beck-opes-esfnep-01.txt (word in progress), November 2000
[11] Penno, R., "Identification of Users on the Internet", draft-
penno-uid-00.txt. Work in progress, January
2001
[12] Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm",
RFC 1321, April 1992.
[13] Maughan, D., Schertler, M., Schneider, M., and J. Turner,
"Internet Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.
13. Acknowledgments
RADIUS and RADIUS Accounting were originally developed by Steve
Willens of Livingston Enterprises for their PortMaster series of
Network Access Servers.
Author's Addresses
Reinaldo Penno
Nortel Networks, Inc.
2305 Mission College Boulevard
Building SC9-B1240
San Jose, CA 95134
Email: rpenno@nortelnetworks.com
Andre Gustavo de Albuquerque
Nortel Networks, Inc.
Av. Lauro Muller, 116
Room 605
Rio de Janeiro, Brazil
Email: gustavoa@nortelnetworks.com
Penno, et al. [Page 25]
Internet-Draft draft-penno-cdnp-nacct-userid-03.txt March,2001
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.