RE: RoE control packets and e2e security
Agree ;) ..and to be honest the less we try to define the less work to do..
- Jouni
> -----Original Message-----
> From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
> Sent: Friday, July 10, 2015 1:47 PM
> To: Jouni Korhonen; STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
> Subject: 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