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

First of all, there is obviously an ability to filter out packets
NOT to encrypt. Otherwise you would have a lot of problems negotiating
the encryption keys. To the best of knowledge, what MUST be supported
in ethernet chips is such filtering based on ethertype because thats
whats being used also in 802.1x, the basic security architecture. See
ACP draft section A.10.2

Secondly, i was told (and this is where i have not tried to validate),
that MacSec should equally be able to utilize multiple keypairs,
probably mapped by VLAN or ethertype. But the question of course is
whether you want/can expect that MACsec MIC chips have that feature.

So, the most simple solution would be to put all of ACP onto a separate
ethertype, run that all in software (including existing encryption)
and use MacSEC to HW encrypt all other traffic. 

If you wanted to then also accelerate encrypted ACP with MACsec
itself, you would not actually use the new ethertype to encapsulate
the secure channel packets, but just negotiate a separate VLAN for
that. In which case you just use IKEv2 from the scure channel protocol
(as an example) to negotiate keys but instead of IPsec/ESP you use
MACsec/VLAN).

CHeers
    Toerless

On Wed, Jul 24, 2019 at 07:03:42PM -0400, 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.
> 
> 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.
> 
> -- 
> ]               Never tell me the odds!                 | ipv6 mesh networks [ 
> ]   Michael Richardson, Sandelman Software Works        | network architect  [ 
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [ 
> 	
> 
> 

> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
tte@cs.fau.de