Lost Ethertype in encrypted MACsec frames
up vote
4
down vote
favorite
MACsec uses an Ethertype of 88E5. This presents an obvious problem when encrypting frames which already have, or should have, another Ethertype. This RedHat blog, for example, states "[MACsec] can secure all traffic within a LAN, including DHCP and ARP, as well as traffic from higher layer protocols". How can ARP be secured when it has to have an Ethertype of 0806?
More generally, if you have an encypted backbone/switch/WLAN/whatever which talks to unencrypted endpoints, then the switch will encrypt plain Ethernet frames on ingress, and decrypt on egress. During this process, the original Ethertype is lost, since there's nowhere to store it in a MACsec frame, so what does the switch put in the outgoing Ethertype?
I guess one option is for the switch to only encrypt a specific Etherype - IPv4, say - and replace the incoming 0800 with 88E5, and reverse that at the output. This doesn't seem particularly useful though. Thanks.
ethernet security
add a comment |
up vote
4
down vote
favorite
MACsec uses an Ethertype of 88E5. This presents an obvious problem when encrypting frames which already have, or should have, another Ethertype. This RedHat blog, for example, states "[MACsec] can secure all traffic within a LAN, including DHCP and ARP, as well as traffic from higher layer protocols". How can ARP be secured when it has to have an Ethertype of 0806?
More generally, if you have an encypted backbone/switch/WLAN/whatever which talks to unencrypted endpoints, then the switch will encrypt plain Ethernet frames on ingress, and decrypt on egress. During this process, the original Ethertype is lost, since there's nowhere to store it in a MACsec frame, so what does the switch put in the outgoing Ethertype?
I guess one option is for the switch to only encrypt a specific Etherype - IPv4, say - and replace the incoming 0800 with 88E5, and reverse that at the output. This doesn't seem particularly useful though. Thanks.
ethernet security
"the original Ethertype is lost, since there's nowhere to store it in a MACsec frame" I'm not sure where you got that idea. MACsec actually adds to the frame. Remember that 802.1Q adds to the ethernet frame, moving the Ether Type field down, and inserting a different Ether Type field and other fields. MACsec adds eight octets to the ethernet frame header, and 16 octets at the end of the frame.
– Ron Maupin♦
Dec 3 at 19:20
Wow. Spent all day reading the docs and missed that. If you want to make that an answer I'll accept it.
– EML
Dec 3 at 19:26
OK. I did that.
– Ron Maupin♦
Dec 3 at 19:34
add a comment |
up vote
4
down vote
favorite
up vote
4
down vote
favorite
MACsec uses an Ethertype of 88E5. This presents an obvious problem when encrypting frames which already have, or should have, another Ethertype. This RedHat blog, for example, states "[MACsec] can secure all traffic within a LAN, including DHCP and ARP, as well as traffic from higher layer protocols". How can ARP be secured when it has to have an Ethertype of 0806?
More generally, if you have an encypted backbone/switch/WLAN/whatever which talks to unencrypted endpoints, then the switch will encrypt plain Ethernet frames on ingress, and decrypt on egress. During this process, the original Ethertype is lost, since there's nowhere to store it in a MACsec frame, so what does the switch put in the outgoing Ethertype?
I guess one option is for the switch to only encrypt a specific Etherype - IPv4, say - and replace the incoming 0800 with 88E5, and reverse that at the output. This doesn't seem particularly useful though. Thanks.
ethernet security
MACsec uses an Ethertype of 88E5. This presents an obvious problem when encrypting frames which already have, or should have, another Ethertype. This RedHat blog, for example, states "[MACsec] can secure all traffic within a LAN, including DHCP and ARP, as well as traffic from higher layer protocols". How can ARP be secured when it has to have an Ethertype of 0806?
More generally, if you have an encypted backbone/switch/WLAN/whatever which talks to unencrypted endpoints, then the switch will encrypt plain Ethernet frames on ingress, and decrypt on egress. During this process, the original Ethertype is lost, since there's nowhere to store it in a MACsec frame, so what does the switch put in the outgoing Ethertype?
I guess one option is for the switch to only encrypt a specific Etherype - IPv4, say - and replace the incoming 0800 with 88E5, and reverse that at the output. This doesn't seem particularly useful though. Thanks.
ethernet security
ethernet security
asked Dec 3 at 19:12
EML
1256
1256
"the original Ethertype is lost, since there's nowhere to store it in a MACsec frame" I'm not sure where you got that idea. MACsec actually adds to the frame. Remember that 802.1Q adds to the ethernet frame, moving the Ether Type field down, and inserting a different Ether Type field and other fields. MACsec adds eight octets to the ethernet frame header, and 16 octets at the end of the frame.
– Ron Maupin♦
Dec 3 at 19:20
Wow. Spent all day reading the docs and missed that. If you want to make that an answer I'll accept it.
– EML
Dec 3 at 19:26
OK. I did that.
– Ron Maupin♦
Dec 3 at 19:34
add a comment |
"the original Ethertype is lost, since there's nowhere to store it in a MACsec frame" I'm not sure where you got that idea. MACsec actually adds to the frame. Remember that 802.1Q adds to the ethernet frame, moving the Ether Type field down, and inserting a different Ether Type field and other fields. MACsec adds eight octets to the ethernet frame header, and 16 octets at the end of the frame.
– Ron Maupin♦
Dec 3 at 19:20
Wow. Spent all day reading the docs and missed that. If you want to make that an answer I'll accept it.
– EML
Dec 3 at 19:26
OK. I did that.
– Ron Maupin♦
Dec 3 at 19:34
"the original Ethertype is lost, since there's nowhere to store it in a MACsec frame" I'm not sure where you got that idea. MACsec actually adds to the frame. Remember that 802.1Q adds to the ethernet frame, moving the Ether Type field down, and inserting a different Ether Type field and other fields. MACsec adds eight octets to the ethernet frame header, and 16 octets at the end of the frame.
– Ron Maupin♦
Dec 3 at 19:20
"the original Ethertype is lost, since there's nowhere to store it in a MACsec frame" I'm not sure where you got that idea. MACsec actually adds to the frame. Remember that 802.1Q adds to the ethernet frame, moving the Ether Type field down, and inserting a different Ether Type field and other fields. MACsec adds eight octets to the ethernet frame header, and 16 octets at the end of the frame.
– Ron Maupin♦
Dec 3 at 19:20
Wow. Spent all day reading the docs and missed that. If you want to make that an answer I'll accept it.
– EML
Dec 3 at 19:26
Wow. Spent all day reading the docs and missed that. If you want to make that an answer I'll accept it.
– EML
Dec 3 at 19:26
OK. I did that.
– Ron Maupin♦
Dec 3 at 19:34
OK. I did that.
– Ron Maupin♦
Dec 3 at 19:34
add a comment |
1 Answer
1
active
oldest
votes
up vote
7
down vote
accepted
MACsec actually adds to the ethernet frame header and trailer. You end up with a different value in the Ether Type field position, much like you do with 802.1Q, but the original Ether Type field is preserved.
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
7
down vote
accepted
MACsec actually adds to the ethernet frame header and trailer. You end up with a different value in the Ether Type field position, much like you do with 802.1Q, but the original Ether Type field is preserved.
add a comment |
up vote
7
down vote
accepted
MACsec actually adds to the ethernet frame header and trailer. You end up with a different value in the Ether Type field position, much like you do with 802.1Q, but the original Ether Type field is preserved.
add a comment |
up vote
7
down vote
accepted
up vote
7
down vote
accepted
MACsec actually adds to the ethernet frame header and trailer. You end up with a different value in the Ether Type field position, much like you do with 802.1Q, but the original Ether Type field is preserved.
MACsec actually adds to the ethernet frame header and trailer. You end up with a different value in the Ether Type field position, much like you do with 802.1Q, but the original Ether Type field is preserved.
answered Dec 3 at 19:34
Ron Maupin♦
60.9k1160109
60.9k1160109
add a comment |
add a comment |
Thanks for contributing an answer to Network Engineering Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fnetworkengineering.stackexchange.com%2fquestions%2f55172%2flost-ethertype-in-encrypted-macsec-frames%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
"the original Ethertype is lost, since there's nowhere to store it in a MACsec frame" I'm not sure where you got that idea. MACsec actually adds to the frame. Remember that 802.1Q adds to the ethernet frame, moving the Ether Type field down, and inserting a different Ether Type field and other fields. MACsec adds eight octets to the ethernet frame header, and 16 octets at the end of the frame.
– Ron Maupin♦
Dec 3 at 19:20
Wow. Spent all day reading the docs and missed that. If you want to make that an answer I'll accept it.
– EML
Dec 3 at 19:26
OK. I did that.
– Ron Maupin♦
Dec 3 at 19:34