Subject: [Detnet] DetNet Security Considerations Meetup at IETF 103

From: "Grossman, Ethan A." <[email-masked]>
Date: Tue, 6 Nov 2018 02:30:25 +0000

Hi All,
Recent IESG draft reviews have resulted in a number of comments about how to handle the Security Considerations sections of the various drafts. Also now that the data plane technologies have settled down to IP and MPLS, we need some strategy on what aspects of these have security implications unique to DetNet.

I would really like to meet up this week with anyone who has any interest in DetNet Security. If you email me back I can put a group meeting together, or just have individual meetings with people (at which I can take notes on your thoughts, i.e. you won't have to write anything unless you volunteer :-)

Of course we can also use the list, but since we have the opportunity to meet face to face we can take advantage of it.

Write me back!!
Ethan (as DetNet Security Considerations draft editor).

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Tue, 6 Nov 2018 05:51:30 +0000

I claim we now have a quorum (thank you David and Loa) and a meeting time:
Wednesday (tomorrow) at 2pm.
I hope more of y'all will join us.
Let us meet at the tables outside the Terminal Room on the 9th floor North side, near "Apartment 1-4" rooms. If I can find an actual room between now and then I'll let you know.

Thanks,
Ethan.

From: detnet <[email-masked]> On Behalf Of Grossman, Ethan A.
Sent: Tuesday, November 06, 2018 9:30 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; Maik Seewald (maseewal) <[email-masked]>; Daniel Harkins <[email-masked]>; [email-masked]
Subject: [Detnet] DetNet Security Considerations Meetup at IETF 103

Hi All,

Write me back!!

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Wed, 7 Nov 2018 07:05:58 +0000

We are encamped in the "Apartment" meeting room immediately next door to the Terminal Room.

From: Grossman, Ethan A.
Sent: Tuesday, November 06, 2018 12:52 PM
To: [email-masked]; Tal Mizrahi <[email-masked]>; Carsten Bormann <[email-masked]>
Cc: [email-masked]; Daniel Harkins <[email-masked]>; [email-masked]; Black, David <[email-masked]>; Deborah Brungard <[email-masked]>; John Dowdell <[email-masked]>; Norman Finn <[email-masked]>; Subir Das <[email-masked]>; Henrik Austad <[email-masked]>
Subject: RE: DetNet Security Considerations Meetup at IETF 103

Thanks,
Ethan.

From: detnet <[email-masked]<mailto:[email-masked]>> On Behalf Of Grossman, Ethan A.
Sent: Tuesday, November 06, 2018 9:30 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Maik Seewald (maseewal) <[email-masked]<mailto:[email-masked]>>; Daniel Harkins <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: [Detnet] DetNet Security Considerations Meetup at IETF 103

Hi All,

Write me back!!

---

From: Norman Finn <[email-masked]>
Date: Wed, 7 Nov 2018 07:59:04 +0000

Timing security and CQF.

Cyclic Queuing and Forwarding (CQF) is described in IEEE Std 802.1Q-2018, Annex T.  It is a queuing technique in which every forwarding node in the network is synchronized in time with every other node.  In CQF there is a cycle time Tc, which must accommodate both the DetNet flows to be transmitted and a period of dead time.  The dead time may includes all of the time from when a packet is selected for output from a CQF queue until it has been inserted into a CQF queue at the next hop.  The dead time always includes at least any variability in output selection to first bit received plus clock inaccuracy.  Clock inaccuracy can easily be a significant determinant of the minimum cycle time Tc that can be configured, which in turn determines the best-case latency that DeetNet + CQF can deliver.  The clock inaccuracy used in calculating Tc includes inaccuracies induced by security considerations.  For example, a Tc value of 100 microseconds might budget a maximum of 4 microseconds for clock inaccuracy. See the timing security draft XYXYXYX for a discussion of how such accuracy can be obtained.  Of course, many DetNet applications have their own requirements for clock synchronization accuracy that may be even more stringent that those of DetNet, itself.

-- Norm

________________________________
From: Grossman, Ethan A. [[email-masked]]
Sent: Tuesday, November 06, 2018 11:05 PM
To: [email-masked]; Tal Mizrahi; Carsten Bormann; Ehsan MohammadPour; Loa Andersson
Cc: [email-masked]; Daniel Harkins; [email-masked]; Black, David; Deborah Brungard; John Dowdell; Norman Finn; Subir Das; Henrik Austad
Subject: RE: DetNet Security Considerations Meetup at IETF 103

We are encamped in the “Apartment” meeting room immediately next door to the Terminal Room.

From: Grossman, Ethan A.

I claim we now have a quorum (thank you David and Loa) and a meeting time:
Wednesday (tomorrow) at 2pm.
I hope more of y’all will join us.
Let us meet at the tables outside the Terminal Room on the 9th floor North side, near “Apartment 1-4” rooms. If I can find an actual room between now and then I’ll let you know.

Thanks,
Ethan.

Hi All,

I would really like to meet up this week with anyone who has any interest in DetNet Security. If you email me back I can put a group meeting together, or just have individual meetings with people (at which I can take notes on your thoughts, i.e. you won’t have to write anything unless you volunteer :-)

Write me back!!

---

From: Norman Finn <[email-masked]>
Date: Wed, 7 Nov 2018 08:14:26 +0000

Time-scheduled transmissions

DetNet also allows for IEEE 802.1Q-2018 Clause 34 time-scheduled transmissions.  In this technique, the opening and closing of a queue's ability to transmit packets is turned on and off with a schedule that has a nominal precision of 1 ns, although an implementation can have lower precision.  This schedule is synchronized to some accuracy.  The accuracy required of the time synchronization need not be much more accurate that the precision of the transmitters.  The overall accuracy requirement will depend on the application, of course (see the DetNet use cases draft).  Application requiring an accuracy of 100 ns are quite common, and 10 ns not unusual.

-- Norm

From: Grossman, Ethan A.

Thanks,
Ethan.

Hi All,

Write me back!!