North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Cable Modem [really responsible engineering]
- From: Fletcher E Kittredge
- Date: Mon Jun 25 11:23:51 2001
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-----
> > 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.
> 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,
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
> 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.
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
> 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
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
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
> 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
> 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
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