Subject: [Detnet] Security draft should consider IEEE 802.1Qci

From: Norman Finn <[email-masked]>
Date: Sun, 11 Nov 2018 09:59:00 +0000

One of the drivers for writing IEEE Std 802.1Qci (an amendment to IEEE 802.1Q-2014, and now now incorporated into IEEE 802.1Q-2018) is protection of a TSN network from misbehaving stations or bridges, and/or deliberate attacks.

The facilities include:

  -- Restricting a flow to entering a a bridge on certain ports.
  -- Restricting a flow to a maximum frame size.
  -- Running a rotating schedule, synchronized with other devices in the network, that defines at what windows during a cycle that a flow can and cannot enter on certain ports.
  -- Attaching a "maximum wire-time bits per cycle" limitation for a flow on input.
  -- Attaching a typical burst/rate red/yellow/green (only red and green) rate limiting meter to a flow
  -- Restricting and/or remapping the QoS provided a packet depending on input port, input time gate, and flow ID.

You cannot see the details of what cannot and cannot be specified simply from the above list -- there is a processing flow defined, so that one can map control parameter settings (defined in the documents) to results on the wire, so one must read the documents to understand the feature fully.

In addition, some of the queuing methods described in IEEE Std 802.1Q and IEEE P802.1Qcr provide some protection against attacks/misbehaviors, for example, by ensuring that excess traffic in one flow can affect only that one flow's latency and loss guarantees, and not any other flows' guarantees.

>From the above description, it's obvious that there there are completed and in-process 802 standards that can be of some help in prevention or mitigation of some attacks.  Such items are probably worth mentioning in the security draft.

I hope, but cannot promise, to help with text.

-- Norm

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 12 Nov 2018 04:12:39 +0000

Dear all

I made a comment at the mike that with the PREOF redundancy one of the packets we get is probably the right one at the right time. The Good.
Then there is the wrong guy at the right time, which could be sorted out by usual crypto. The Bad.
Then there is the right packet at the wrong time, which can confused crypto-only security and cause rate limiters to filter out the Good. That's the Ugly.

The point I made at the mike is that we need to instrument packets so that the nodes that filter anything need to be able to sort the Good from the Bad and the Ugly. We need our DetNet security envelope to cover both cases, and admittedly, pure crypto does not cut it, and pure shaping/policing does not cut it either. This is why I see a particular usefulness in the security work that Tal presented yesterday.

All the best,

Pascal

From: detnet <[email-masked]> On Behalf Of Norman Finn
Sent: dimanche 11 novembre 2018 16:59
To: [email-masked]
Cc: [email-masked]
Subject: [Detnet] Security draft should consider IEEE 802.1Qci

The facilities include:

-- Norm