RE: RoE control packets and e2e security
The group will do what they want, - project scope interpretation is always a
slippery slope ;)
-----Original Message-----
From: Jouni Korhonen [mailto:jouni.korhonen@xxxxxxxxxxxx]
Sent: Friday, July 10, 2015 4:40 PM
To: Marek Hajduczenia; STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Subject: RE: RoE control packets and e2e security
See inline,
> -----Original Message-----
> From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
> Sent: Friday, July 10, 2015 12:30 PM
> To: Jouni Korhonen; STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
> Subject: 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 ...
[JiK:] I could argue about the "describing complete system".. maybe it is
not a concern for IEEE to neglect system level security considerations.
Either way it is not an issue for me.
- Jouni
>
> -----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