Subject: [Detnet] Recent discussions on DetNet Security draft 15Nov17

From: "Grossman, Ethan A." <[email-masked]>
Date: Wed, 15 Nov 2017 02:41:48 +0000

Here are my notes on recent offline email and yesterday's informal meet-up related to the DetNet Security draft as of 15Nov17. If anyone has any additions, corrections or relevant thoughts please reply with them.
Ethan.
----------------------------------------------------
Ethan's proposal that the DetNet WG should engage with the IETF Security Directorate to provide early input to the DetNet Security draft, or possibly assign a Security Advisor to the WG was discussed. We concluded that this was not called for until
1)      More concrete decisions have been made about the specific protocols to be used by DetNet
2)      The nature of any modifications to these protocols that we will require has been determined
3)      The security implications of any such changes have been examined
Jean-Yves mentioned that an academic paper was published which showed that a successful attack against a time protocol had been carried out by modifying (via hardware) the differential path delays of a fiber optic link, resulting in a modification of the receiver's time reference. Presumably this is not a DetNet specific item and should be publicized to the Time Protocol Security draft - Jean-Yves to send Tal the link.
Pascal pointed out that we could discuss attacks on the UNI, e.g. buffering.
Norm observed that in general for DetNet if you are concerned about data integrity you need to secure your data "in the usual way". However there are also some specific security related requirements implied by the current design must go into arch draft. Two examples:
1)      If doing zero congestion loss, bounded latency, then it is often necessary for DetNet relay nodes to be able to determine the Flow ID to assign it to the proper class of service. E.g. per-flow queues. To determine the Flow ID they either need to look deep enough into the packet or it must be exported outside the packet. Can't expect the relay node to look far into aggregate flows. So however you secure the packet, you must not obscure the Flow ID.
2)      For PREF, there is a tunnel (security relationship) from whoever is creating the sequence numbers to whoever is eliminating packets. Such PREF can be done in various places in the network. At intermediate points they are peers, protecting the sequence number. So each has to decrypt and re-encrypt it. The eliminator has to be able to read the sequence number (not modify it). Replicator doesn't need to know seq num.
We discussed whether the DetNet Security draft was intended to become an RFC, and if so would it be Informational or perhaps Best Current Practices? (Presumably this would be determined by the WG Chairs, but we discussed it anyway in their absence). Or perhaps the intent was to just use it as a clearing house for security related information that eventually would be copied as needed into the architecture drafts (data plane, etc) and then eventually allowed to expire. It was pointed out that if it is Informational it cannot be normatively referenced by the Arch drafts, so probably multiple copies of the same information would be present in each of the Arch drafts, and that a possible strategy would be to have them all point to the Security draft.
Then there was discussion of which types of info would go in an Arch draft vs the Security draft. For example the Arch draft might say the "what" had to be done, and the Security draft could say "how" it could be done. Or the Arch draft could say both "what" and "how" in a general sense (e.g. "must be encrypted") and the Security draft would provide specifics of this. For example for interoperability of implementations, we could say "must support at least e.g. SHA 256". But must have a way to evolve e.g. crypto. They do that in QUICC. Not just "must be a good enough crypto".
For example Norm specifies where the seq number is written, read, obscured. The Sec draft could then reference the Arch draft, then provide more specifics. The Arch doc reader needs to know where to find the "how", and know that there is a solution.
The Security draft could continue to address architecture-level topics such as threat analysis which are informational in nature; this could be either the main focus of it as an informational draft, or could be the appendix to a BCP draft which might include more protocol specific and possibly normative information, i.e. if it described any required behavior.
Concentrating the security info in the Security draft takes burden off of Arch authors, i.e. the work is done by sec experts not forwarding experts. A negative of this is that it means one more doc to put through RFC process, which Pascal is concerned that the administration increasingly want to minimize. Jean-Yves points out that the DetNet Charter includes arch, data plane, security aspects.
It was noted that if you reference another draft, your draft can't be published until the reference is published - we would not want the Arch drafts to be held up by the Security draft.
Deborah pointed out that the current Sec draft includes info about Control plane which is out of scope for DetNet. Current thought is to move that info into an appendix for future reference.
------------------------------------------------------

---

From: Norman Finn <[email-masked]>
Date: Wed, 15 Nov 2017 03:47:38 +0000

THANKS, Ethan.  Some comments in-line.

________________________________
From: detnet [[email-masked]] on behalf of Grossman, Ethan A. [[email-masked]]
Sent: Tuesday, November 14, 2017 6:41 PM
To: [email-masked]
Subject: [Detnet] Recent discussions on DetNet Security draft 15Nov17

Here are my notes on recent offline email and yesterday’s informal meet-up related to the DetNet Security draft as of 15Nov17. If anyone has any additions, corrections or relevant thoughts please reply with them.
Ethan.
----------------------------------------------------
Ethan’s proposal that the DetNet WG should engage with the IETF Security Directorate to provide early input to the DetNet Security draft, or possibly assign a Security Advisor to the WG was discussed. We concluded that this was not called for until

  1.  More concrete decisions have been made about the specific protocols to be used by DetNet
  2.  The nature of any modifications to these protocols that we will require has been determined
  3.  The security implications of any such changes have been examined

Jean-Yves mentioned that an academic paper was published which showed that a successful attack against a time protocol had been carried out by modifying (via hardware) the differential path delays of a fiber optic link, resulting in a modification of the receiver’s time reference. Presumably this is not a DetNet specific item and should be publicized to the Time Protocol Security draft – Jean-Yves to send Tal the link.
Pascal pointed out that we could discuss attacks on the UNI, e.g. buffering.
Norm observed that in general for DetNet if you are concerned about data integrity you need to secure your data “in the usual way”. However there are also some specific security related requirements implied by the current design must go into arch draft. Two examples:

  1.  If doing zero congestion loss, bounded latency, then it is often necessary for DetNet relay nodes to be able to determine the Flow ID to assign it to the proper class of service. E.g. per-flow queues. To determine the Flow ID they either need to look deep enough into the packet or it must be exported outside the packet. Can’t expect the relay node to look far into aggregate flows. So however you secure the packet, you must not obscure the Flow ID.
  2.  For PREF, there is a tunnel (security relationship) from whoever is creating the sequence numbers to whoever is eliminating packets. Such PREF can be done in various places in the network. At intermediate points they are peers, protecting the sequence number. So each has to decrypt and re-encrypt it. The eliminator has to be able to read the sequence number (not modify it). Replicator doesn’t need to know seq num.

<NWF> Yes, I said this.  But I take it back.  :)  As someone mentioned (Tal?), the trust relationship is between the guy that adds the sequence number and the guy that removes the sequence number.  Sometimes the sequence number goes end-to-end source to destination, sometimes its added/deleted by network edge devices.  The adder and remover(s) have the relationship because they're the ones that ensure that the sequence numbers are not modifiable.  Between those two points, there may or may not be replication and elimination functions.  The elimination function(s) are between the sequence number adder and remover(s).  The elimination functions must be able to see the sequence numbers.  Therefore any encryption that is done between adders and removers must not obscure the sequence number.  (If the sequence removers and the eliminators are in the same box, you can usually get away with obscuring the sequence number, but it's a layer violation, and someday, you'll be sorry.)

We discussed whether the DetNet Security draft was intended to become an RFC, and if so would it be Informational or perhaps Best Current Practices? (Presumably this would be determined by the WG Chairs, but we discussed it anyway in their absence). Or perhaps the intent was to just use it as a clearing house for security related information that eventually would be copied as needed into the architecture drafts (data plane, etc) and then eventually allowed to expire. It was pointed out that if it is Informational it cannot be normatively referenced by the Arch drafts, so probably multiple copies of the same information would be present in each of the Arch drafts, and that a possible strategy would be to have them all point to the Security draft.
Then there was discussion of which types of info would go in an Arch draft vs the Security draft. For example the Arch draft might say the “what” had to be done, and the Security draft could say “how” it could be done. Or the Arch draft could say both “what” and “how” in a general sense (e.g. “must be encrypted”) and the Security draft would provide specifics of this. For example for interoperability of implementations, we could say “must support at least e.g. SHA 256”. But must have a way to evolve e.g. crypto. They do that in QUICC. Not just “must be a good enough crypto”.
For example Norm specifies where the seq number is written, read, obscured. The Sec draft could then reference the Arch draft, then provide more specifics. The Arch doc reader needs to know where to find the “how”, and know that there is a solution.
<NWF> Norm specifies?  Well, the architecture document does.  Pascal and Balázs made it right.
The Security draft could continue to address architecture-level topics such as threat analysis which are informational in nature; this could be either the main focus of it as an informational draft, or could be the appendix to a BCP draft which might include more protocol specific and possibly normative information, i.e. if it described any required behavior.
Concentrating the security info in the Security draft takes burden off of Arch authors, i.e. the work is done by sec experts not forwarding experts. A negative of this is that it means one more doc to put through RFC process, which Pascal is concerned that the administration increasingly want to minimize. Jean-Yves points out that the DetNet Charter includes arch, data plane, security aspects.
It was noted that if you reference another draft, your draft can’t be published until the reference is published – we would not want the Arch drafts to be held up by the Security draft.
Deborah pointed out that the current Sec draft includes info about Control plane which is out of scope for DetNet. Current thought is to move that info into an appendix for future reference.
------------------------------------------------------