11

I already asked this question on SF, but figured it might be a better fit here.

Is it at all possible to extend MACSec encryption over a provider bridge? Will the typical 802.1ad implementation be able to forward the encrypted frame, or will forwarding break frame integrity?

I do realize MACSec is intended for hop-by-hop security. Are there any reasons not to use MACSec for point-to-point encryption over a carrier, or other special considerations that should be taken into account?

The reason I ask is that MACSec hardware offers wirespeed encryption at a fraction of the typical cost associated with layer 2 encryption.

I don't have the rep to add new tags, but feel free to add relevant tags for MACSec, PBN, 802.1ad and 802.1ae etc

Mike Pennington
  • 29,989
  • 11
  • 79
  • 152
Roy
  • 298
  • 1
  • 4
  • 15

2 Answers2

4

MacSec (i.e. 802.1ae-2006) is a hop-by-hop encyption technology... Therefore provider-bridged MacSec isn't possible today; however, there is a talk of relaxing per-hop MacSec encryption

Mike Pennington
  • 29,989
  • 11
  • 79
  • 152
  • But if the MACSec encrypted frame is encapsulated and tagged with S-VLAN at ingress, forwarded through the PBN and the S-VLAN encapsulation is removed at egress on the other side. Won't the customer switches see this as a single hop, just like with EoMPLS? Perhaps supported by an encryption offset, so the C-VLAN tag is still visible? – Roy Jul 05 '13 at 12:11
  • Thanks for the link, btw. I already have that document sitting on my desk, although some of it is quite incomprehensible to me :) – Roy Jul 05 '13 at 12:14
  • If you read the first page of the paper, it explains very clearly that PBN is not supported today... "This note explains why IEEE 802.1AE–2006 does not include multi-hop possibilities that might appear ‘interesting’ at first glance" – Mike Pennington Jul 05 '13 at 12:17
  • 1
    Well, in the ingress is also says "This note explains why these bridges can be treated as a 'single hop'". I hope you can see why I find this just a little a confusing, especially considering that EoMPLS encapsulation seems to work just fine. – Roy Jul 05 '13 at 12:20
1

From what I gather thus far if the MACsec endpoint where to C-tag/ then add the sec header then the s-tag and the PBN forwarded the frame based on the s-tag that the MACsec endpoint created it should work. The fuzziness comes in where the PBN adds the s-tag to the frame which changes the FCS and possibly alerts the other endpoint that the frame has been tampered with/modified and therefore the integrity cannot be validated. I'm not 100% on this but that is what I think keeps end to end MACsec from working.

user6121
  • 11
  • 1