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

[Toerless Eckert <[e-mail]>]

On Fri, Jul 26, 2019 at 07:33:41PM -0400, Michael Richardson wrote:
> 
> Toerless Eckert <[e-mail]> wrote:
>     > 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
> 
> Yes, but the key management packets can be packets that are "special"
> at the MACsec level.

My point was that the "special at MACsec level" propoerty that can
expected to be supported by MACsec capacle MIC chips is ethertype and
hopefully VLAN tag. But i don't think nothing else.

>     > 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.
> 
> The people in the line behind me did not agree.

Hmm... Don't remember if anyone else stated that there can be one one
keypair. As i said in the other mail, both a single and a douple keypair
solution are possible to build, i just think it would be nicer 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.

Cheers
    toerless