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

[Toerless Eckert <[e-mail]>]

On Mon, Jul 29, 2019 at 10:46:33PM -0400, Michael Richardson wrote:
> It's not about keypair, it's about what IPsec would call the SPD, which is a
> way to select which traffic goes into which tunnel.  I would also have
> expected it to be able to select based upon VLAN tag and destination ethernet
> type, but people said that wasn't so.

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.

Your reference to IPsec is also another big question. 
Right now, there is all this convoluted, 802.1x and AAA server MacSec
session setup mechanism.  Which natively is asymmetric, and AFAIK,
the extensions to make it symmetric whee either done only very recently or are
still TBD in ieee.  One solution is just to leverage all of this and
just declare that nodes need to use and trust their ACP domain
certificates - and be done. It would just be anothrer parallel ACP
secure channel mechanism beside IKEv2 and DTLS.

Personally i would love a simpler mechanism, but there is a different
simpler/nicer architectural solution and a simpler/nicer programmatic
solution: The simpler architectural mechanism is to tie MacSec into
IKEv2. But who would be the critical mass of people doing that work.
It's not easy. The simple pragmatic solution is to put ACP on top of
some ethertype like EAPoL and exclude it from 802.1x, build normal IPsec
ACP and then have small new ASA that simply auto-instantiate existing
MACsec for the data-plane.

> I would love to be told I'm wrong.
> I can see if one was building the minimum viable solution that can deal with
> state-level attackers on point to point fiber runs, that just encrypting
> everything works well.  

The fiber runs in my apartment complex are in rooms open to the public.
No need to hire overpayed federal employees to plug a fiber snooping
device into them. And the city wide fibers are either on open poles or
in digging distance of shovels through somebody elses garden (learned
that from comcast workers that dug up those gardens too to find the
shovel made fiber cuts).

Sorry. not directly on-topic but hopefully entertaining. 

If we want the least overhead solution, then its the last option i
mentioned. We did program that in tcl in a week as small ASA (send
random generated PSK to direct neighbor, auto-configure existing
MACsec to neighbor. Done). Of course this expects ACP to already be in
place, and if you can't exclude ACP from the MacSec encryption you have
to have a bit of logic in the ASA to avoid shooting yourself into the
feet.

Cheers
    Toerless

>     > if ACP can be separately encrypted from data-plane, but as long as ACP
>     > is responsible to manage the encryption key, it can equally encrypt
>     > both ACP and data-plane. Its just that right now, ACP is not optimized
>     > for fast reconvergence, so a data-plane could converge faster and then
>     > it might still need to wait for ACP. But thats solely a matter of
>     > routing protocol and aliveness parameters of ACP/data-plane.
> 
> 
> -- 
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 



-- 
---
[e-mail]