RE: RoE control packets and e2e security
Jouni,
Some of the DTLS specification relies heavily on IP data, which you might
not have, given that we are defining just a mapper function into Ethernet
payload. For all effects and purposes, it is not clear to me whether E2E
security for RoE is at all even within the scope of what we can specify.
Security is layer 6/7 in OSI stack, and we are defining how layer 2 packages
bits into an Ethernet frame.
Am I missing here anything?
Marek
-----Original Message-----
From: stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx] On Behalf Of
Jouni Korhonen
Sent: Friday, July 10, 2015 1:19 PM
To: STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Subject: 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