On Fri, Jul 26, 2019 at 07:33:41PM -0400, Michael Richardson wrote: > > Toerless Eckert <t...@cs.fau.de> 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 _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima