Cross posting sucks. However, this is a special case as this discussion really ought to move to NANOG without losing context. Please edit headers to make sure replies go *only* to NANOG. On Tue, 19 Jun 2001 14:52:45 -0700 "Richard Barr Hibbs" wrote:

...

-----Original Message-----

*Snip!*

...

There are three reasons that one needs to be able to map an IP->MAC-> particular customer: 1) to provide customer support, 2) to provide network metrics and monitoring, 3) to provide identification in court cases.

If one builds a network that does not provide these three abilities, the public will eventually step in -- via the legislature, the courts or the marketplace.

If you can explain how you can provide quality customer support without a MAC map, provide network metrics and monitoring without a MAC map, and satisfy the courts without a MAC map, then I agree with you, there are valid different ways to provide this service.

However, if you can't meet the three criteria, then the only valid design for a public network is one that can track is an invalid way to build a public network. It is wrong.

*Snip!*

Let me try to rephrase this a bit: to achieve the three goals that you mention (customer support, network metrics and monitoring, and legal identification of users) you assert that the way to do so is to have a mapping between IP address and MAC address. I don't disagree that an association between IP and MAC can be useful in achieving those goals, but I do disagree that it is the only one.

I think we are in violent agreement. I don't like the IP->MAC->Customer mapping, it is forgeable, but it is the only one I know we have available. I agree with you that it is not the only possible mapping. If you can point me to a better existing mechanism, I would be greatful. My complaint is with people who could collect and use this information, but then throw it away and claim ignorance when their network is used to as a springboard for attacking other systems.

Other perfectly valid associations include a non-volatile system serial number of some sort, the "universal user identification" proposed by Intel, or some algorithmic generation of an identifier based on physical system characteristics in place of the MAC address.

I've supported very large client populations and would suggest that it would have been much more useful to have somehow been able to discern a client's physical address (for example, 1201 Central Avenue, Room 346) than their MAC address. MAC address is, of course, useful to distinguish among clients at the same physical address, but then so would be additional information such as "port 57, switch 3SW1201SNFC43." The DHCP client and IP stack that we used did not provide us the luxury of that additional identification, however.

Sounds like a large company or organization network. Frankly, not germane to this discussion. If a database was kept of client MACs, and this information was required before access to service was made available, you then have a network of known devices and have made a long step towards towards assigning responsibility.

Any sort of identifier that helps distinguish among different hardware classes (as the initial octets of a MAC address identify its manufacturer) can be crucial in developing a repair history or predictor of failures for stocking spare parts, but I don't quite see how knowledge of the MAC address is required to monitor network usage or generate performance metrics that are not tied to hardware type or specific device: IP address is much more useful for that, in my opinion, especially if additional information about physical connections (such as port and switch numbers) is available.

Please remember we are talking about large IP over Ethernet *public* networks (cable, Etherloop DSL, wireless) which are used by a completely heterogeneous population. The operator must support the connection of arbitrary devices. Many of the customers have very little knowledge of their configuration or networking. The network operator must support arbitrary devices and clueless customers. Some scenarios: 1) When a customer calls and reports a connection problem, many times the problem will occur before an IP is assigned. The MAC address is the only mechanism for debugging these problems. 2) When a customer's device is misbehaving, by slamming a DHCP server with many uncompleted requests, by broadcasting traffic, or by being hijacked for a DDOS, the only current method of identifying the device is through the MAC address. 3) ARIN has sent the strong message that they expect IP over E public network providers to use dynamic IP allocation in order to conserve IPv4 addresses. Public networks are oversold and a fundamental financial/quality requirement is that the rate of oversell can be accurately tracked, or that customers be accurately charged for their bandwidth usage. In gathering these statistics, a MAC address is a key bit of glue allowing one to tie flows to customers.

Finally, I would not want to declare under oath that a MAC address absolutely and uniquely identified a client host: it's just too easy to spoof.

Total and absolute agreement. There is no question that it is easy for a technical sophisticated customer to spoof a MAC address. This fact should always be kept in mind when analysing any information. However, there are a couple of possibilities for spoofing: 1) An existing, connected and valid MAC is spoofed. In that case, the spoofing becomes apparent pretty quickly; duplicate MACs make themselves known... 2) A non-existing, non-connected and non-valid MAC is spoofed. In that case, someone will have had to put them in the database in order to get service. One can then go to that person and ask why the spoofed

Having said all of this, I want to be sure you don't misunderstand: supporting customers, whether there are two or 2 million of them, is extremely important for any service business. Part of that support includes administering servers and facilities so that all customers can enjoy the services without interfering with other customers. So are we really in disagreement?

Mostly not.

I just don't know how to make the last part of the 3-way association IP-->MAC-->client work reliably without significant changes in most environments.

Yes, it is difficult to add this functionality after the fact. However, the original discussion was prompted by a question about the design of a future network. As others have pointed out, if you start from the beginning, it is possible to design in the simple capture and maintenance of IP -> MAC -> customer data. To do otherwise is irresponsible. regards, fletcher