RoE control packets and e2e security
Folks,
I've been working on a baseline proposal for the e2e security for RoE control plane packets. Hopefully I have some slide pollution to share later today on the list.
There are few assumptions I have:
* RoE control flows get terminated at the local CPU(s) - not the switch.
* The protection must be e2e even if there is a switched network between REs and RECs.
* There is no reason to protect anything else but the RoE content itself - the RoE payload.
I am also of an opinion that RoE control packet protection should be *optional* i.e. up to the product/deployment to decide whether to implement/deploy it or not - just like MACsec. This would be "appendix" material.
For the solution itself I would go for DTLS (see RFC6347). There is interesting work ongoing in IETF profiling DTLS for constrained devices, which serves the purposed for us trying to be minimal e.g. on overhead. They also consider transports other than UDP/IP, which is a good reference.
For the RoE purposes we would still need to have some specification text "profiling" DTLS. The places I identified so far are:
* Cookie generation - since we have no IP addresses it is better to use MAC address instead of IP.
* Multiplexing security associations - instead of typical IP address + UDP port we would use MAC address + RoE flow_id.
Other that the above, the use of DTLS *should* be straight forward. I have not put any thought on recommended ciphersuite set yet, though.
- Jouni
--
Jouni Korhonen, CTO Office, Networking, Broadcom Corporation
O: +1-408-922-8135, M: +1-408-391-7160