Differences

This shows you the differences between two versions of the page.

--- network_stuff:macsec [2026/10/08 13:33] – created admin
+++ network_stuff:macsec [2026/10/08 20:33] (current) – admin
@@ Line 1: / Line 1: @@
-  ====== MACsec explained ======
+====== MACsec explained ======
+===== The idea in one paragraph =====
-  ===== The idea in one paragraph =====
+MACsec encrypts **one Ethernet hop** (port to port). It has two parts:
+  * **MKA** (MACsec Key Agreement) is the **control plane**. The two ends prove they share a secret, elect one of them as the boss (the **Key Server**, KS), and that boss hands out the actual traffic key.
+  * **MACsec** proper is the **data plane**. Every frame gets encrypted, signed and numbered with that key.
-  MACsec encrypts **one Ethernet hop** (port to port). It has two parts:
+**Keep these apart when troubleshooting.** MKA can look perfectly healthy while the data plane is dropping everything.
+===== 1. The keys: three layers, each made from the one above =====
-    * **MKA** (MACsec Key Agreement) is the **control plane**. The two ends prove they share a secret, elect one of them as the boss (the **Key Server**, KS), and that boss hands out  the actual traffic key.
+^ Term ^ Plain English ^ Lifetime ^
+| **CAK** (Connectivity Association Key) | The master password. It's either pre-shared (configured in a key chain) or comes from 802.1X. It never encrypts traffic itself. | Until you change the config |
+| **CKN** (CAK Name) | The "username" that goes with that password. It's sent in clear text so the peer knows which CAK to use. Both ends must hold the same CKN/CAK pair. | Same as the CAK |
+| **ICK / KEK** | Two keys made automatically from the CAK. The **ICK** signs MKA messages so they can't be forged. The **KEK** encrypts the SAK when the Key Server sends it to the peer. You never configure them. | Same as the CAK |
+| **SAK** (Secure Association Key) | **The key that actually encrypts traffic.** The Key Server generates it at random and delivers it wrapped in the KEK. | One rekey period |
-    * **MACsec** proper is the **data plane**. Every frame gets encrypted, signed and numbered with that key.
+In short: **CKN says which password. The CAK proves who you are. The SAK encrypts the traffic.**
+A key chain can hold more than one CKN/CAK pair. That's normally used for hitless CAK rollover. Normally only one pair is the live session at a time, with a brief overlap during rollover.
-  **Keep these apart when troubleshooting.** MKA can look perfectly healthy while the data plane is dropping everything.
+===== 2. Who's who: the identifiers =====
+^ Term ^ Plain English ^
+| **CA** (Connectivity Association) | The "club" of ports holding the same CAK. On a point-to-point link that's just the two ends. **A CA rebuild means the session is torn down and rebuilt from scratch.** |
+| **SC** (Secure Channel) | **One direction** of traffic. Each sender has its own SC, so a link has two, one per direction. That's why MACsec faults can be one-way only. |
+| **SCI** (SC Identifier) | The SC's name tag: the sender's **MAC address (6 bytes) + port ID (2 bytes)** = 8 bytes. |
+| **SA** (Secure Association) | One SAK being used on one SC. Each rekey creates a new SA. |
+| **AN** (Association Number) | The **slot number** of an SA. It's a 2-bit field, so only **0 to 3**. AN + SCI identifies the SA. The 5th SAK reuses slot 0, the 6th reuses slot 1, and so on. Having 4 slots is what lets the new key overlap the old one during a rekey. |
+| **KN** (Key Number) | MKA's running count of SAKs: 1, 2, 3 and upwards. Typically **AN = (KN-1) mod 4**. If KN drops back to 1, the CA was rebuilt. |
+| **KS** (Key Server) | The elected boss that generates and distributes SAKs. Lowest ''key-server priority'' wins, with the lowest SCI as tie-break. "Non-KS" in logs means "I'm not the boss". |
+| **MKPDU** | An MKA protocol message. Peers exchange one about every 2 s, and the session dies after about 6 s without one. If a carrier in the path swallows them, MKA never comes up. |
-  ===== 1. The keys: three layers, each made from the one above =====
+===== 3. What's added to every frame =====
+<code>
+DA | SA | SecTAG | encrypted payload | ICV
+</code>
-  ^ Term ^ Plain English ^ Lifetime ^
+  * **SecTAG** sits in front of the payload. It carries the AN (which key slot), the PN (which frame number) and optionally the SCI. It adds 8 bytes, or 16 bytes when the SCI is included.
+  * **ICV** (Integrity Check Value) is the 16-byte signature. A bad ICV means a wrong key or a tampered frame, and it shows up in the "not valid" counters.
+  * **Cipher suite**: the algorithm, e.g. ''aes256-gcm-xpn''. Both ends must agree.
-  | **CAK** (Connectivity Association Key) | The master password. It's either pre-shared (configured in a key chain) or comes from 802.1X. It never encrypts traffic itself. | Until   you change the config |
+===== 4. Packet numbers and replay protection =====
-  | **CKN** (CAK Name) | The "username" that goes with that password. It's sent in clear text so the peer knows which CAK to use. Both ends must hold the same CKN/CAK pair. | Same as  the CAK |
+^ Term ^ Plain English ^
+| **PN** (Packet Number) | A frame counter, **32 bits**, that **restarts at 1 with every new SAK**. It stops an attacker re-sending a recorded frame. |
+| **XPN** (Extended PN) | The same counter at **64 bits**. **Only the low 32 bits go on the wire**, and the receiver works out the upper 32 bits itself. |
+| **Replay window** | How far **behind** the highest PN seen a frame may arrive and still be accepted. **0** means strict in-order only, which drops legitimate frames that QoS queues have reordered. |
+| **Lowest acceptable PN** | The highest PN seen minus the window. Anything below it is dropped as **"late"**. |
+| **SSCI / salt** | XPN-only extras. They're a compact SCI and a random value from MKA, used to build the encryption nonce. Invisible to you. |
-  | **ICK / KEK** | Two keys made automatically from the CAK. The **ICK** signs MKA messages so they can't be forged. The **KEK** encrypts the SAK when the Key Server sends it to the  peer. You never configure them. | Same as the CAK |
+**Why XPN matters:** what matters is packet rate, not link speed. A 32-bit counter allows about 4.3 billion frames per key. At 10G with minimum-size frames that's used up in **5-7 minutes**, which forces a rekey long before a typical hourly timer. XPN removes that limit, so it matters at 10G too, not only at 40G+.
-  | **SAK** (Secure Association Key) | **The key that actually encrypts traffic.** The Key Server generates it at random and delivers it wrapped in the KEK. | One rekey period |
+===== 5. The knobs you'll actually touch =====
+^ Knob ^ Effect ^
+| ''rekey-period'' | How often a new SAK is made. Very short periods mean rapid rekeys, and each one is a chance for something to go wrong. |
+| ''replay protection window'' | The window size above. On some platforms changing it rebuilds the CA, which means a few seconds of blocked traffic and routing protocol flaps. Treat it as disruptive. |
+| ''key-server priority'' | Decides which end is the boss. |
+| ''traffic unprotected drop'' / ''should-secure'' vs ''must-secure'' | What happens to traffic with no live SA. "Drop" or "must" means a blackhole rather than sending in clear text. |
+| ''confidentiality offset'' | Leaves the first 0/30/50 bytes unencrypted (for load balancers that need to see headers). Normally 0. |
-  In short: **CKN says which password. The CAK proves who you are. The SAK encrypts the traffic.**
+===== 6. How a session comes up =====
+  - Both ends send MKPDUs using the CKN. Each checks the other's ICK signature, which proves they have the same CAK. Now they're **peers**.
+  - They elect the **Key Server**.
-  A key chain can hold more than one CKN/CAK pair. That's normally used for hitless CAK rollover. Only one is the live session at a time.
+  - The KS generates a **SAK**, wraps it with the **KEK** and sends it.
+  - Both install it in slot **AN**: the receive side first, then transmit. Traffic is now encrypted, starting from **PN 1**.
+  - At each rekey: a new SAK goes into the next AN slot, the KN goes up by one, the PN restarts at 1, and the old slot is retired.
-  ===== 2. Who's who: the identifiers =====
-  ^ Term ^ Plain English ^
-  | **CA** (Connectivity Association) | The "club" of ports holding the same CAK. On a point-to-point link that's just the two ends. **A CA rebuild means the session is torn down and  rebuilt from scratch.** |
-  | **SC** (Secure Channel) | **One direction** of traffic. Each sender has its own SC, so a link has two, one per direction. That's why MACsec faults can be one-way only. |
-  | **SCI** (SC Identifier) | The SC's name tag: the sender's **MAC address (6 bytes) + port ID (2 bytes)** = 8 bytes. |
-  | **SA** (Secure Association) | One SAK being used on one SC. Each rekey creates a new SA. |
-  | **AN** (Association Number) | The **slot number** of an SA. It's a 2-bit field, so only **0 to 3**. AN + SCI identifies the SA. Rekey #5 reuses slot 0, #6 reuses slot 1, and so  on. Having 4 slots is what lets the new key overlap the old one during a rekey. |
-  | **KN** (Key Number) | MKA's running count of SAKs: 1, 2, 3 and upwards. Typically **AN = (KN-1) mod 4**. If KN drops back to 1, the CA was rebuilt. |
-  | **KS** (Key Server) | The elected boss that generates and distributes SAKs. Lowest ''key-server priority'' wins, with the lowest SCI as tie-break. "Non-KS" in logs means "I'm not  the boss". |
-  | **MKPDU** | An MKA protocol message. Peers exchange one about every 2 s, and the session dies after about 6 s without one. If a carrier in the path swallows them, MKA never comes  up. |
-  ===== 3. What's added to every frame =====
-  <code>
-  DA | SA | SecTAG | encrypted payload | ICV
-  </code>
-    * **SecTAG** sits in front of the payload. It carries the AN (which key slot), the PN (which frame number) and optionally the SCI. It adds about 16 bytes.
-    * **ICV** (Integrity Check Value) is the 16-byte signature. A bad ICV means a wrong key or a tampered frame, and it shows up in the "not valid" counters.
-    * **Cipher suite**: the algorithm, e.g. ''aes256-gcm-xpn''. Both ends must agree.
-  ===== 4. Packet numbers and replay protection =====
-  ^ Term ^ Plain English ^
-  | **PN** (Packet Number) | A frame counter, **32 bits**, that **restarts at 1 with every new SAK**. It stops an attacker re-sending a recorded frame. |
-  | **XPN** (Extended PN) | The same counter at **64 bits**. **Only the low 32 bits go on the wire**, and the receiver works out the upper 32 bits itself. |
-  | **Replay window** | How far **behind** the highest PN seen a frame may arrive and still be accepted. **0** means strict in-order only, which drops legitimate frames that QoS  queues have reordered. |
-  | **Lowest acceptable PN** | The highest PN seen minus the window. Anything below it is dropped as **"late"**. |
-  | **SSCI / salt** | XPN-only extras. They're a compact SCI and a random value from MKA, used to build the encryption nonce. Invisible to you. |
-  **Why XPN matters:** what matters is packet rate, not link speed. A 32-bit counter allows about 4.3 billion frames per key. At 10G with minimum-size frames that's used up in **5-7  minutes**, which forces a rekey long before a typical hourly timer. XPN removes that limit, so it matters at 10G too, not only at 40G+.
-  ===== 5. The knobs you'll actually touch =====
-  ^ Knob ^ Effect ^
-  | ''rekey-period'' | How often a new SAK is made. Very short periods mean rapid rekeys, and each one is a chance for something to go wrong. |
-  | ''replay protection window'' | The window size above. On some platforms changing it rebuilds the CA, which means a few seconds of blocked traffic and routing protocol flaps. Treat  it as disruptive. |
-  | ''key-server priority'' | Decides which end is the boss. |
-  | ''traffic unprotected drop'' / ''should-secure'' vs ''must-secure'' | What happens to traffic with no live SA. "Drop" or "must" means a blackhole rather than sending in clear  text. |
-  | ''confidentiality offset'' | Leaves the first 0/30/50 bytes unencrypted (for load balancers that need to see headers). Normally 0. |
-  ===== 6. How a session comes up =====
-    - Both ends send MKPDUs using the CKN. Each checks the other's ICK signature, which proves they have the same CAK. Now they're **peers**.
-    - They elect the **Key Server**.
-    - The KS generates a **SAK**, wraps it with the **KEK** and sends it.
-    - Both install it in slot **AN**: the receive side first, then transmit. Traffic is now encrypted, starting from **PN 1**.
-    - At each rekey: a new SAK goes into the next AN slot, the KN goes up by one, the PN restarts at 1, and the old slot is retired.
-G-RESEARCH believes the information provided herein is reliable. While every care has been taken to ensure accuracy, the information is furnished to the recipients with no warranty as to the completeness and accuracy of its contents and on condition that any errors or omissions shall not be made the basis of any claim, demand or cause of action. The information in this email is intended only for the named recipient. If you are not the intended recipient please notify us immediately and do not copy, distribute or take action based on this e-mail.
-All messages sent to and from this e-mail address will be logged by G-RESEARCH and are subject to archival storage, monitoring, review and disclosure. For information about how G-RESEARCH uses your personal data, please refer to our Privacy Policy.
-G-RESEARCH is the trading name of Barlowe LLP and its affiliates globally. Barlowe LLP is a limited liability partnership registered in England with number OC451516 and registered office 8th Floor One Soho Place, London, W1D 3BG.