|
|
Many application types require the notion of the user: user monitoring and profiling, billing, security analysis, and so on. From the question of what to collect, you saw that various types of data can represent the same notion; for example, the application can be classified by many types of data. This is especially true for the notion of the user; hence, this section is dedicated to the topic. Throughout this section, billing examples illustrate the points.
Table 2-15 shows an example for a user called Mister Joe. He is the customer of an ISP and receives a monthly invoice with detailed records from his provider.
| User | Date | Traffic Transferred | Cost |
|---|---|---|---|
| Mister Joe | Monday | 122 MB | $12 |
| Mister Joe | Tuesday | 98 MB | $10 |
| Mister Joe | ... | ... | ... |
Who is Mister Joe? From the ISP's networking perspective, he is a subscriber to a service, but this label does not distinguish between a user, a group of users, a customer, an organization, and so forth. Even if Mister Joe is a human being, the ISP has to find a clear way to identify him from a networking point of view. Mister Joe can be a single interface if the ISP dedicates an access link to him. In that case, the key is the interface index (ifIndex in RFC 2863).
If several customers share the same access link, the ISP needs a different key. It could be the source IP address if the ISP assigns a static IP address to each customer. In case of dynamic IP address assignment, the IP address allocation could change. In that case, the MAC address, which is always unique because it is bound to a Network Interface Card (NIC), could be the new key. However, using the MAC address as a key entails that Mister Joe always uses the same NIC to access the network resource—that is, the same PC, the same cable modem, or the same DSL modem.
Instead of classifying the user with a networking characteristic (such as the access interface index, source IP address, or MAC address), another approach is user authentication. The Remote Authentication Dial-In User Service (RADIUS) is used for general login purposes: dial-in, Telnet, Secure Shell (SSH), Point-to-Point Protocol (PPP), and so on. The user first authenticates at a Network Access Server (NAS). The next phase is authorization, and the last one is accounting. Whereas RADIUS is a standard protocol defined by the IETF (RFC 2865), the Terminal Access Controller Access Control System + protocol (TACACS+) is a Cisco-specific protocol with similar capabilities. The advantage of both RADIUS and TACACS is that the username is automatically linked to the accounting record. Consequently, in case of RADIUS or TACACS, Mister Joe automatically appears in the data records.
The opposite situation occurs if no authentication takes place and a username is not part of the accounting record. In this case, translation is required to deduce Mister Joe from networking characteristics such as an IP address, a MAC address, an interface, a VPN, or a PVC. For a mediation device in charge of translating a networking characteristic into a user as Mister Joe, getting the real username can be a major challenge:
How accurate is the database linking the translation to the customer?
In case of changes in the networking characteristic allocation (IP address, MAC address, VPN, PVC, or the equivalent), what is the process to update the database?
In case of changes in the networking characteristic allocation, how long does the update take before the database is up-to-date?
Do multiple users in one location (such as a home network) use the same networking characteristics?
The notion of the user does not always concern individuals. For example, an enterprise may want to charge back the cost of its Internet link to the different departments. In this scenario, the department represents a user in a billing report. In some network designs, where each department is assigned a specific (sub)interface, the ifIndex is again a useful key. In other networks, the key could be the network prefix if the IP address allocation is planned by department. If the user is a prefix, the prefix is deduced from the IP address with the associated subnet mask. This entails that either the metering process takes place at a routing device, or the prefix and subnet mask are also exported as part of the data record and the aggregation is applied at a server. As a practical example, the user cannot be the prefix in case of an RMON collection, because RMON gathers no routing capabilities and traffic-forwarding information.
Furthermore, the user could be an entire company. If an ISP delivers Internet connections to enterprise companies, the ISP bills those companies individually, so the users are the companies. This leads to the same question: How can you distinguish the different users? The answer is: per interface, per IP address range, per ATM PVC, per Frame Relay DLCI, per VPN, and so on.
An ISP can offer different billing reports with different users, according to the level of services offered to customers. In other words, the ISP could offer the user billing-level granularity as a level of service:
Basic level of service— The report contains the billing for the entire company (for example, if the key is the interface index or the VPN).
Medium level of service— The report contains the billing per department within the company. This makes it easy for the department to charge back (for example, if the key is the network prefix).
Top level of service— The report contains the top talkers within the department and company (for example, if the key is the IP address).
Figure 2-6 shows the relationships between the different levels of users.
In this section, you learned that the generic notion of the user can be translated into many different types of data, depending on the network design and infrastructure, the network protocol in place, and the level of detail associated with your service.
|
|