Re: [Anima] MACsec as an alternative to L3-tunnels

[Brian E Carpenter <[e-mail]>]

Hi,

In the context of the L2ACP draft (draft-carpenter-anima-l2acp-scenarios):

It seems that MACsec keying and associations are generally pair-wise, but IEEE Std 802.1AE-2018 says:

"The guarantees provided by MACsec support the following security services for stations participating in MACsec:
a) Connectionless data integrity [6.8a), 6.8b)]
b) Data origin authenticity [6.8a)]. If the connectivity model is point-to-point, the originator is authenticated, but _if the connectivity model is multipoint, then the authenticated originator is any member of the CA, rather than a particular individual station._
c) Confidentiality [6.8d)]
d) Replay protection [6.8c), 6.8d)]
e) Bounded receive delay"

Also 802.1 bridges do forward MACsec. So multicast should work. However

1) This does not carry over to 802.11. An L2ACP that was a mixture of 802.1 and 802.11 would need to deal with two different security solutions.

2)

On 25-Jul-19 11:03, Michael Richardson wrote:

> I was asked to decode words mangled at the mic at Tuesday morning's ANIMA
> meeting.
> The word was "MACsec", and 
>     https://en.wikipedia.org/wiki/IEEE_802.1AE
>     https://1.ieee802.org/security/802-1ae/        
> 
> provides a reasonable description, and probably the getieee mechanism
> might get you a copy for free, but IEEE doesn't have a URL that
> leads to the actual document.  I did read it once.
> (One of the URLs in the wikipedia page leads to 404)
> 
>     https://ieeexplore.ieee.org/document/8585421
> might get you the document if you have a valid password, which
> I used to, but apparently not anymore.

We should use the 2018 version of the standard, which should be freely available via
https://ieeexplore.ieee.org/browse/standards/get-program/page

> Given my newly acquired understanding that MACsec applies on a per-port
> basis, not on a per-VLAN basis, this means that it would be rather difficult
> to do peer discovery and security for a L2-bridged LAN.

As I read the current standard, it should work, but if you do MACsec then the user plane VLAN is apparently protected by the same keys as the ACP VLAN. However, the two VLANs would still be completely protected from each other by 802.1Q, so I think it's OK.

On 31-Jul-19 08:41, Toerless Eckert wrote:
...
> I think my reference was more to what chips can do as to what
> necessarily existing standaerds may say. There is this one issue of
> having an 802.1ae capable switch port connected via a hub to multiple
> host, in which case you could imagine to use a different set of keys to
> each host but the public vendor documentation i found was quite
> inconclusive whether this actually works in todays products.

Yes, Google finds various different proprietary explanations that seem incompatible. Re the VLAN question, StackExchange says: "There is no standard for MACSec and 802.1Q, so manufacturers have come up with their own solutions." That is no longer true; 802.1AE-2018 explains exactly how it co-exists with 802.1Q. But I doubt if the products have all been updated yet. We need an expert.

I like this explanation, but it's now out of date:
https://developers.redhat.com/blog/2016/10/14/macsec-a-different-solution-to-encrypt-network-traffic/

    Brian