RE: RoE control packets and e2e security
Marek,
DTLS record layer per se is not specific to IP - that is just the most commonly used environment. There is e.g. DTLS done over short messages. Below I wrote that presence of IP is not assumed.
Whether e2e security is in scope of RoE control flows that is another thing. The need / questions around it has just come up multiple times. Since IMHO it is not core part of RoE I said below this is something optional that we can write into informative appendix or such. After all this is just a proposal for the baseline subject to approval by the WG.
- Jouni
> -----Original Message-----
> From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
> Sent: Friday, July 10, 2015 10:49 AM
> To: Jouni Korhonen; STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
> Subject: 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