From owner-freebsd-questions Wed Mar 14 16:55:32 2001 Delivered-To: freebsd-questions@freebsd.org Received: from be-well.ilk.org (lowellg.ne.mediaone.net [24.147.184.128]) by hub.freebsd.org (Postfix) with ESMTP id C072937B718 for ; Wed, 14 Mar 2001 16:55:25 -0800 (PST) (envelope-from lowell@be-well.ilk.org) Received: (from lowell@localhost) by be-well.ilk.org (8.11.3/8.11.3) id f2F0tDr68716; Wed, 14 Mar 2001 19:55:13 -0500 (EST) (envelope-from lowell) To: freebsd-questions@freebsd.org, davep@afterswish.com (David Preece) Subject: Re: Adding route using mac address References: <44ae6odui3.fsf@lowellg.ne.mediaone.net> <5.0.2.1.1.20010315085251.02281748@pop3.paradise.net.nz> From: Lowell Gilbert Date: 14 Mar 2001 19:55:12 -0500 In-Reply-To: davep@afterswish.com's message of "14 Mar 2001 21:08:17 +0100" Message-ID: <448zm7onpr.fsf@lowellg.ne.mediaone.net> Lines: 147 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG davep@afterswish.com (David Preece) writes: > At 14:24 14/03/2001 -0500, you wrote: > >amour@bugs.elitsat.net (Alexander) writes: > > > > > How can I add route for host using the mac address. > > > >You can't. Routes have nothing to do with media layer information. > > Okay, I realise I'm on shaky ground here, but would like to disagree. You're squarely in my main field of expertise here, and although it's a somewhat esoteric point by the standards of most implementations, I don't think I'm going overboard by saying flatly that you're wrong. > Routes - next hop ones at least - have everything to do with layer 2. Say > my machine is 1.2.3.8 on a class C, and my default router is 1.2.3.1. What > we are effectively saying here is that I am layer 2 connected to > 1.2.3.everything, and that if I want to get a packet outside of that I have > to use the machine at 1.2.3.1. So when a packet goes off to 3.4.5.6, on > layer 2 the packet is addressed over to the router. "Layer". To borrow a line from "The Princess Bride," you keep using that word, but I don't think you know what it means. The way you use OSI terms to refer to IP concepts, even though they don't quite map cleanly ("layer 2" is not precisely equivalent to "MAC layer") just strengthens my suspicion. Using the archaic term "class C" just ticks off one of my pet peeves. Your example is a perfectly good one, and aside from my pedantic dislike of your terminology, nothing in the above quoted paragraph is incorrect. I'll use the same example later on. > Conceptually it may be truer to describe a default route in terms of mac > address. "The route out of the layer 2 network is at this address". > However, it would be a pain in the arse, so we give routers an IP address > and rely on arp to convert it to a mac address for us. No. You are breaking the IP layering model completely. The network layer (at which IP operates) *does* *not* know MAC addresses. At all. This is an important point, because it is what allows the *same* IP layer code to easily work with many different kinds of physical media. A IP route is actually defined strictly at the IP level. On a detailed level, it consists of a set of destination (IP) addresses, a next-hop (IP) address, and an interface to send over. The "set of destination addresses" is the address and netmask of a network that can be reached, the interface is an abstraction that sits between the IP layer and the MAC layer, and the next-hop address belongs to another host which is (assuming everything is set up correctly) both closer to the destination network and directly reachable by that interface. Thus, a route consists of a database 4-tuple: destination address, destination netmask, the next-hop IP address, and the interface through which the destination network can be reached. [The first two, obviously, are the database key.] None of this is MAC information, because it's independent of the physical media, and in fact different interfaces may well have different physical media, and yet still have routes in this same table. [For completeness, I'll note that the next hop's IP address may not exist -- the link may be unnumbered -- but that the IP code doesn't need to know this.] We go back to the earlier example: > Routes - next hop ones at least - have everything to do with layer 2. Say > my machine is 1.2.3.8 on a class C, and my default router is 1.2.3.1. What > we are effectively saying here is that I am layer 2 connected to > 1.2.3.everything, and that if I want to get a packet outside of that I have > to use the machine at 1.2.3.1. So when a packet goes off to 3.4.5.6, on > layer 2 the packet is addressed over to the router. In that last sentence, the two phrases are occurring at different levels, not (as the wording implies) the same time. It's true that at the MAC layer, the packet is addressed to the MAC address of 1.2.3.1, but the IP layer doesn't know that -- and can't, without changing the IP forwarding code for every new media type you add. What happens in forwarding an IP packet is that the destination address (3.4.5.6) is extracted from the packet, and looked up against the database, using a longest-prefix match. In this case, apparently you're assuming it matches a default route, which essentially means that the longest prefix to match will be zero bits long. The resulting entry gives the IP address of the router, 1.2.3.1, and the machine's interface onto the LAN which it shares with that router. The IP forwarding code then hands the packet to the interface, along with the next-hop address, and in the Ethernet example, the interface uses ARP to determine the MAC-layer information to tag on the packet header. > > > Because on the LAN some ppl are changing IPs to skip the traffic counters > > > for them. > > Oh. This isn't really a routing question then. Perhaps go to a dhcp network > and set up the dhcpd.config (or whatever it's called) with very very long > leases so everyone gets the same IP every time. Hmmm, no, I guess that > wouldn't help. Right. If they're already changing their IP addresses by hand, every OS I know will let them do so whether a DHCP server is around or not. DHCP does absolutely nothing to keep unauthorized machines off your LAN. > Perhaps we need a mac layer accounting daemon that could sit off a tee > socket. This wouldn't be too hard, and yes, I might be volunteering. Is > this something the community in general might find useful? Quite possibly, although it would be worth surveying the state of the art first; certainly a lot of bandwidth monitoring tools will turn up this kind of abuse as a side effect of their main purpose. The original poster seemed to be using such a tool already, which was what they were trying to evade, so for his purpose it might be easier to see if that tool can track address usage, or even try another that can. Or my other suggestion, of hard-wiring the ARP entries in the router, so that the guilty parties' MAC addresses won't be *useful* with other IP addresses. > >You should also, in my opinion, consider non-technical solutions, like > >terminating these people's accounts, firing them, failing them in your > >course, slapping their wrists with #6 linguine, whatever's appropriate > >in your environment. > > Might also prove appropriate. However, you're still facing the ultimate > problem of catching the bastards. In theory, yes. In practice, this isn't much of a problem. After all, he already knows this is happening; he probably has reason for thinking so. Occasionally, it *is* a problem, but that generally involves people changing their MAC addresses as well, and you can't detect that without securing the link itself in some way. This is, for example, the point behind managed Ethernet switches which let you lock addresses to a particular port. > Perhaps we need something that just > correlates mac addresses to IP's? Maybe just leaving running for 24hrs off > a bpf then compare the answers to what you should've seen. Yep. Generally this is all that's needed. A lot of these kinds of cases have been turned up by no more than a tcpdump process output piped through grep. Be well. Lowell -- Common sense is the collection of prejudices acquired by age eighteen. -- Albert Einstein To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message