[policedemil]

Great article! A lot of this is way beyond me, but I'm generally interested in the process of how a NIC filters based on MAC addresses.

I'm in the humanities and certain scholars working with culture and technology love to make a huge deal about data leakage and how intertwined we all are precisely because you can put a NIC in promiscuous mode and cap packets that weren't meant for you. The whole point is that because your NIC is constantly receiving data meant for others (i.e. because it's filtering the MAC addresses), something like privacy on networks is always problematic. I've always found the whole point somewhat overstated.

So, could anyone explain real quick the process of how a NIC decides whether a packet/frame is actually bound for it or link some good resources? For example, does the NIC automatically store the frame/packet in a buffer, then read the header, and then decide to discard? Or can it read the header before storing the rest of the frame? How much has been read at the point the NIC decides to drop it or move it up the stack? Reading all of every packet seems improbable to me because if it were the case, laptop 1 (awake but not downloading anything) would experience significant battery drain due to constantly filtering network traffic that was meant for laptop 2. I'm not sure that really maps to my experience. Also, I assume there are also differences for LAN vs WiFi?

Any help on the matter would be greatly appreciated! I've tried google diving on this question many times before and it's really hard to find much on it.

[skissane]

> I'm in the humanities and certain scholars working with culture and technology love to make a huge deal about data leakage and how intertwined we all are precisely because you can put a NIC in promiscuous mode and cap packets that weren't meant for you.

For wired networks, a lot of those concerns about machines receiving other machines traffic are somewhat outdated–they were very valid in the 1980s and 1990s, but now in the 2010s they are far less pressing (although not completely gone). Back when we used coax Ethernet or Ethernet hubs, the norm was every machine got every other machine's traffic, and the machine's NIC was responsible for filtering out the traffic destined for other machines, so spying on other people's traffic was easy, and could be done without being detected. Now, with Ethernet switches, the norm is that each machine only gets its own traffic (plus broadcast traffic destined for all machines.) It is possible to overload a switch into a hub by MAC flooding, but in a well-maintained corporate network you can't get away with that for long without being caught. (A home network or small business network you probably can do it for a long time without being detected, since those networks are usually poorly monitored.)

So, in a contemporary well-maintained Ethernet network, it is unlikely your traffic is being sent to other people's machines. Of course, you shouldn't rely on that if you care about your security and privacy. But, encryption is far more common (and far stronger) nowadays, so even if you see someone else's traffic, you are much less likely to understand it. That is the best answer to the concern – who cares if someone else gets your traffic if they can't read it? (Well, if they save it for a few decades, computers might become fast enough to be able to break it – but, it is very unlikely anyone could be bothered.)

For wireless networks, these concerns are still very valid. The best advice with wireless networks, even secure ones, is always use a VPN.

[javajosh]

The serial nature of the physical connection cannot be overstated. Bits flow to your NIC one at a time.

A 1Gb/s NIC is detecting a billion wiggles in voltage per second. Structure is imposed on these wiggles in stages: first, the A/D conversion happens, making the voltage wiggles 1's and 0's, then ethernet framing, then IP packet parsing, then TCP packet/ordering, then the application handles IO (and can, and often does, define even more structure, such as HTTP). You might look up the OSI network layering model (or the OSI 7-layer burrito, as I call it).

My understanding is that MAC filtering happens after ethernet framing, and before putting into the ring via DMA, and packets failing that test do not generate interrupts. Your NIC hardware is choosing to ignore packets not addressed to it because, generally, it's pretty useless to listen in on other people's packets. Especially these days when your most likely to capture HTTPS encrypted data.

[dom0]

> A 1Gb/s NIC is detecting a billion wiggles in voltage per second.

Well technically :) ... 1000BASE-T - regular gigabit ethernet - uses a five-level modulation and four pairs in parallel (which reduces high frequency components, making gigabit over old cables possible).

[javajosh]

No, thanks for the correction! Cool! It's actually something I'd like to learn more about. I get the 5-level modulation, but how are the 4-pairs demultiplexed? The timing constraints must be exquisite.

[dom0]

A DSP in the network card does quite a bit of work to make it work: Since the pairs are used at the same time, near-end and far-end crosstalk need to be cancelled out of the signals, it also removes the currently sent signal and it's reflection (echo cancellation), since each pair can be used in both directions at the same time (!). It also adjusts delay differences between the pairs.

Gigabit Ethernet is really cool and involved tech :)

[eriknstr]

I see you in comments here on HN every so often and I enjoy reading what you have to say. I've been wondering -- and sorry for going totally off-topic here -- whether or not you picked your username inspired by the Xen hypervisor initial domain dom0.

https://wiki.xen.org/wiki/Dom0

[dom0]

Thanks and yes, I did.

[javajosh]

Excellent. You wouldn't happen to have links to someone with an oscilloscope showing what that cross-talk looks like, would you? Would be useful to visualize even at sub-GHz speeds. And also, where is that echo coming from, and how do you avoid generating microwaves if you're sending a GHz signal down a wire? (Or, perhaps you don't avoid it and that's the nature of the cross-talk?)

[dom0]

Since the same pair is used for transmission and reception at the same time, the echo is just removing what you are sending right now from what you are receiving. Similar to how you can hear / listen to someone while talking at the same time (air = ethernet pair).

> how do you avoid generating microwaves if you're sending a GHz signal down a wire?

The main spectral energy of GbE is around 125 MHz & it's harmonics (250 MHz, ...), since that's the symbol rate on the wire, but a cable is still an excellent antenna at these frequencies.

Emission is mainly avoided by using differential transmission over a twisted pair; the small loop area between the conductors minimizes emissions, and also improves rejection of outside electromagnetic noise (EMI) — an antenna always works both ways; a well-shielded mechanism will emit less and will also be less susceptible. Cables are supposed to have an outer shield (for Gigabit anyway), though it works without.

Meanwhile Ethernet avoids creating ground loops by isolating the cable on both ends with small pulse transformers (=high pass filter for the signal). The shields of the cables are also only grounded through small capacitors (=high pass filter for shield currents).

> (Or, perhaps you don't avoid it and that's the nature of the cross-talk?)

Almost! Crosstalk is mainly generate by more "intimate" coupling. Emissions means electromagnetic waves (=long range), while crosstalk in cabling and connectors comes from inductive (magnetic) and capacitive (electric field) coupling. This happens because the conductors and contacts are all very close to each other.

---

I found this video (10BASE-T): https://www.youtube.com/watch?v=i8CmibhvZ0c

[policedemil]

Thank you! This is starting to make a lot more sense! I guess what's still confusing to me has to do with the seriality (continuity?) of the process vs the OSI model, which seems like there are more discrete stages.

Does each stage of the model need to complete for the whole packet before moving on to the next stage? For example, does A/D conversion take place until all of the packet information is converted, then the whole binary blob is enframed as a header and a packet... then we filter for MAC address and move on up the stack in discrete and consecutive stages? Or are the voltages read off the line and once there is enough information to construct the header, compare it, then choose to continue reading the rest from the line or stop the A/D conversion because it is just a waste of energy? The latter makes a lot more sense to me.

EDIT: words

[mschuster91]

> Does each stage of the model need to complete for the whole packet before moving on to the next stage?

Usually, not. Massive core switches could not work if they had to wait for every frame being fully in the buffer before beginning to transmit it to the correct out port. All a core switch needs to look at is the destination MAC address.

Simple math explains why: MTU (max packet size) is usually 1500 bytes (due to most packets originating in Ethernet systems). The dstmac in the Ethernet frame is bytes 9 through 16, which means it would be an absolute waste of time to wait with forward transmission until the remaining 1484 bytes are in the buffer.

Let's calculate this with your ordinary 100 MBit/s home connection (to keep the numbers in reasonable magnitudes). 100 MBit/s means: 0.00000001 s/bit (or 0.01 us/bit, or 0.08 us/byte). With retransmit start after the first 16 bytes, the delay introduced by the equipment is 1.28 us (and needs, basically, 9 bytes of buffering capacity from start of packet to end of packet). Waiting for the full 1500 bytes would introduce 120 us (or 0.12ms) of latency, as well as require 1500 bytes of buffer during the transmission time.

[policedemil]

Excellently put! That's exactly what I was looking for! Thank you!

[mschuster91]

If you want to read further, this is a part of network delay (https://en.wikipedia.org/wiki/Network_delay). A highly interesting field.

By the way, one thing I have forgotten: an instant-forward has much less latency (obviously), but it cannot retract packets that were corrupted during receiving at the ingress port - simply because the checksum can only be calculated when the whole packet is in the buffer.

So basically you choose between safety (corrupted packets do not travel as long, because they don't even reach the final station) and latency (e.g. 10 hops a 0.12ms = 1.20ms delay on 100MBit/s), and also for the cost in buffer memory.

[dom0]

> For example, does A/D conversion take place until all of the packet information is converted, then the whole binary blob is enframed as a header and a packet

The "A/D stage" only gives off a stream of bytes, so something similar to a state machine will be used to separate it into packets that are then further processed.

That doesn't mean you have to wait for a whole packet to come through, though. E.g. a switch (or router) could start to forward the packet as soon as it sees the destination address.

[toast0]

For wired Ethernet, a (decoded) frame starts with a 7-octet preamble of alternating 1 and 0 (0x55), then a "start of frame delimiter" which continues the alternation, except the last bit is 1 instead of zero (0xD5 -- least significant bit is sent first). Then the next 6 octets are the destination mac address. If the NIC is in normal mode, it will wake up when it sees a preamble, use the alternating pattern to synchronize its clock, wait for the start of frame delimiter (which is really the two 1 bits together -- in case the wakeup was a little slow); and then compare the destination mac address to its own mac address one bit at a time. The least significant bit of the first octet of the mac address indicates if it's a broadcast/multicast or intended for only one station; this is the first bit sent on the wire, so that the adapter knows to not do the normal comparison right away. Once the adapter determines the destination address doesn't match, it can stop processing the line. Ethernet requires 96 bits of idle between frames (interframe gap), which it can detect to rearm the preamble trigger.

Different versions of ethernet encode the logical signals differently, so the adapter may decode multiple bits at the same time (100BaseTX transmits in 4-bit groups, 1000BaseT in 8-bit groups), so preamble detection and address comparison would likely be a little different, but the same idea applies.

The Ethernet frame page [1] might be a helpful place to look for more info.

Also, as mschuster91 pointed out, an ethernet switch that can do cut-through switching [2], will be able to avoid buffering the whole packet to decrease latency; although it will need to have some capacity for buffering whole packets anyway -- if it's already sending a packet on the destination port, cut through switching isn't appropriate. An IP router can also do cut-through switching, once the IP header with destination comes in (or as much addressing as required for hashing among multiple links, if the destination is link aggregated)

[1] https://en.wikipedia.org/wiki/Ethernet_frame [2] https://en.wikipedia.org/wiki/Cut-through_switching

[eru]

To answer the first point you brought up: privacy does not depend on who reads your network packages---it depend on encryption.

[walrus01]

> scholars working with culture and technology love to make a huge deal about data leakage

one of the fundamental considerations is that if things are very sensitive, they need to be on their own air gapped network. Or at least not on the same layer 2 fabric as a ton of other things that it can arp. Network engineers who understand all of the myriad possible ways that topology can be set up (both at OSI layer 1 and logically) are key.

Properly set up with a secure gateway/VLAN delivery for a critical workstation that has a special route outbound to the internet through a firewall, there will be only two MACs showing up on the fabric: The workstation itself and the device that is serving as its default route/gateway.

[dom0]

> one of the fundamental considerations is that if things are very sensitive, they need to be on their own air gapped network.

Or maybe consider not using an information-dispersal machine for "very sensitive things".

[walrus01]

tell that to the people who run siprnet/jwics... they're not going to go back to pencil and paper.

[nickpsecurity]

The rules back to the Conputer Security Initiative & Orange Book said that high-assurance, security systems should be used there or at least at interface points. Currently called a Controlled Interface IIRC. Numerous products hit market under Orange Book and later Common Criteria that passed 2-5 years of pentesting each. Most of that was killed off by NSA and DOD acquisition policies about getting more shiny COTS in full of dangerous features and lockin. All kinds of problems resulted. Certain orgsnizations still use the high-assurance stuff, though, at least for cross-domain.

So, it's provably not going from what we have to paper. They could reduce a lot of risk using high-assurance products (esp compartmentalizing ones) that are on market right now. Plus port them to those secure CPU architectures NSF and DARPA funded. Hell, given CHERIBSD, NSA would get really far just paying for it to be put on an ASIC as is with ATI doing custom, MLS firmware. Boom. Immune to most attacks plus POLA for security-critical components. They just dont care enough to do it across DOD.

[ams6110]

MAC is a hexadecimal number so testing a packet header is literally a bitwise AND and then drop the packet if the result is not equal to the card's MAC address, or an XOR and drop if the result is not zero. I am not speaking from knowledge but I'd be astonished if this doesn't happen on the card and never involves the CPU.

[0x0]

It can't possibly an AND operation, can it? If your MAC address has a lot of zero bits you'd get a ton of false positives?

[adrianratnapala]

I think ams... is talking about masking about whatever parts of the header are not the MAC address.

Although whether even that requires AND gates depends on the details of the hardware. Maybe the appropriate bits in the buffer are just directly wired to a comparison unit.

[JdeBP]

Such an equality comparison unit would generally be an XOR-NAND combination.