RE: RoE control packets and e2e security
Usually material in appendix includes either additional explanation (for
example, golden tables for FEC, architecture drawings, etc.) and not
something completely out of scope of the project. Discussion of encryption
seems to go in the direction of describing implementation of a complete
system and not just the mapper we are supposed to be working details of ...
-----Original Message-----
From: Jouni Korhonen [mailto:jouni.korhonen@xxxxxxxxxxxx]
Sent: Friday, July 10, 2015 3:23 PM
To: Marek Hajduczenia; STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Subject: 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