Subject: Re: [Detnet] DetNet Security Review

From: "Grossman, Ethan A." <[email-masked]>
Date: Mon, 7 Nov 2016 20:55:47 +0000

Hi Folks,

One of our members who is a security specialist sent me a list of preliminary comments and recommendations on DetNet Security, which I adapted into a set of slides (text below). I will add these slides into my DetNet Use Cases Update preso at IETF 97, but I am sending them out in advance so you can think about them and make comments. My cut and paste of the PPT text below may not be very readable - if anyone would rather see the original PPT or a PDF version please let me know and I can send it to you directly.

Thanks,

Ethan.

---------------------------------------------

•DetNet Security Topics
•Based on recommendations from Professor Andrew J Hacker
•Cybersecurity Expert in Residence, Harrisburg University of Science and Technology and CEO, MistIQ Technologies, Inc.
•Goals of this Presentation
•Thus far DetNet strategy has been “Don’t break security”
•Next steps:
1.Now: enumerate DetNet technologies that have potential security implications
2.Eventually: identify those DetNet technologies for which we must either
•Create a security related protocol that doesn’t already exist, or
•Modify an existing protocol for use with DetNet
•
•Not all DetNet use cases require the same level of security, so define a set of security functions that applications can choose from
•Overall Security Strategy Recommendation
•Consider DetNet security using “CIA” principle
•Confidentiality
•Path choices, predictability/unpredictability, encryption, privacy/masking
•Integrity
•Ingress device and message authorization and access control, device code validation, required code reviews, buffer/field/queue integrity validations, parameter/config validations, vulnerability management
•Availability
•Availability versus attack surface, denial of service, manipulation of time sensitivity
•This preso follows this organization, ordered by DetNet function
•Documentation Recommendations
•Consolidate security discussions into a “DetNet Cybersecurity” doc
•Ethan has done a first cut at this – should it be submitted as a DetNet draft?
•If so, then should security discussions in existing drafts be replaced with a reference to the new security draft?
•Define set of “DetNet-specific security components”
•Refer to specific existing standards where possible
•Create spec for those we must create
•Determine which use cases require which security components
•
•DetNet Functions with Security Implications (1/3)
•Packet replication & elimination
•Effect on existing security protocols?
•HTTPS?
•Ipsec tunneling?
•Encrypted packets/payloads?
•How does the predictability/unpredictability of the results of the algorithms used (e.g. IEEE 802.1cb) affect overall security of the system?
•Effect on attacker’s ability to inject and validate malicious packets?
•Effects of trade-off between increased availability and attack surface?
•DetNet Functions with Security Implications (2/3)
•Path choice(s) and information about path choice(s)
•Effect of increased attack surface?
•Can an attacker predetermine a path or flow?
•Possibility/effect of attacker changing, influencing, adding a path or flow?
•Logical segmentation between DetNet/non-DetNet paths and flows
•Requirements?
•Network slicing?
•Query/response/process execution considerations/differences
•Information Technology vs
•Operational Technology
•
•DetNet Functions with Security Implications (3/3)
•Packet fields which require encryption/obfuscation
•Examples
•Path routes
•Timing fields
•Duplicate packet flags
•Packet content (e.g. control messages)
•Device authorization and access to DetNet domain
•At ingress, egress, along path
•Part of DetNet or higher level application?
•Message authorization
•Part of DetNet or higher level application?
•If vulnerabilities in DetNet affect message, waiting until message it passed up to higher level application may affect higher level applications ability to properly and securely assess the message
•Runtime Monitoring Recommendations
•Runtime mechanisms to
•Detect and disconnect misbehaving components and/or devices
•Monitor OAM integrity and DetNet security framework integrity
•Monitor performance - provide alerts and corrective action at appropriate points
•Validate sensitive/critical parameter configurations
•Validate (and prevent manipulation of) time-sensitive algorithms/values
•Use backup algorithms for this?
•Log operations (which operations require logging?)
•Validate active DetNet devices’ executable code?
•Embed portions of DetNet security intelligence directly into data
•Packets can contain dynamic data in addition to content calculated by network infrastructure
•Refer to Author’s research and IP on this topic, for example a cybersecurity framework that places functionality and intelligence directly within data packets to provide dynamic and contextual correlation of information to improve control and precision over packet security, privacy and network flow
•Considerations for DOS attacks - validation/priority mechanisms must account for
•Global device overruns making DetNet goals unobtainable
•Attacker pre-provisioning DDOS conditions
•Service lost due to malicious timing changes
•DetNet Implementation/Development Process
•Certification/validation of DetNet components
•HW components
•SW components
•Devices
•Reviews of DetNet SW, HW designs
•Buffers
•Important fields
•Duplication/deduplication/path and packet management
•OAM management algorithms
•How much of this is in DetNet scope?
•None?
•Work with AVnu Alliance?
------------------------------------------------------------------------

________________________________
From: Maik Seewald (maseewal) <[email-masked]>
Sent: Tuesday, October 11, 2016 4:09 AM
To: nfinn; Grossman, Ethan A.
Cc: [email-masked]
Subject: Re: [Detnet] DetNet Security Review

In parallel, IEEE 1588 has a sub working group defining security (in terms of profiles/prongs) for the 1588 protocol.
For time-sensitive networking, security for critical services (such as time) is essential, especially in WAN use cases…
Regards, Maik

From: Norm Finn <[email-masked]<mailto:[email-masked]>>
Date: Dienstag, 11. Oktober 2016 08:05
To: "Grossman, Ethan A." <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Detnet] DetNet Security Review

You are a regular fountain of good questions lately, Ethan!

There are people in NTP/TICTOC looking at time security.

Not much else that I know about.

— Norm

On Oct 7, 2016, at 1:13 PM, Grossman, Ethan A. <[email-masked]<mailto:[email-masked]>> wrote:

Hi Folks,
Security is of paramount importance for most if not all of the networks described in the DetNet use cases. I gather that DetNet itself doesn’t have a lot of explicit security aspects, however since security in such networks needs to be considered from the start as opposed to later, do we have someone among us who is our “security guru” who is keeping an eye on our development to make sure we don’t miss a trick anywhere? One way or another, I would like to be confident that we have this totally covered.
Thanks,
Ethan.

_______________________________________________
detnet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/detnet<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_detnet&d=DQMFAw&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=W4_8szPlllWiEi0_jSw9Fn4cXKwLHz7G4dAb4O8CLhE&s=oAgQMPFbBI9qmtnr4HqDkAJvJ9MxBgYBzmepAcnIf6g&e=>

---

From: Norman Finn <[email-masked]>
Date: Mon, 7 Nov 2016 15:07:44 -0600

There are some good points, here.  There are a few more points that, I think, would be useful additions to the discussion:

  • How much time required to set up and/or validate security relationships at power up, or to check them after power up?

  • What effect do various encryption/validation choices have on latency and latency variation?

  • Given that on-time delivery can be just as important to the proper functioning of some applications as correct data, and that encrypting data does not prevent attacks based on manipulating the delivery time, what are the advantages/disadvantages of end-to-end vs hop-by-hop trust relationships?

I’m sure there are more.

— Norm

> On Nov 7, 2016, at 14:55, Grossman, Ethan A. <[email-masked]> wrote:
> 
> Hi Folks,
> •This preso follows this organization, ordered by DetNetfunction
> •Ethan has done a first cut at this – should it be submitted as a DetNetdraft?
> From: Maik Seewald (maseewal) <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
> From: Norm Finn <[email-masked] <mailto:[email-masked]>>
> To: "Grossman, Ethan A." <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> On Oct 7, 2016, at 1:13 PM, Grossman, Ethan A. <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Folks,
>> [email-masked] <mailto:[email-masked]>
>> MailScanner has detected a possible fraud attempt from "urldefense.proofpoint.com" claiming to be https://www.ietf.org/mailman/listinfo/detnet <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_detnet&d=DQMFAw&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=W4_8szPlllWiEi0_jSw9Fn4cXKwLHz7G4dAb4O8CLhE&s=oAgQMPFbBI9qmtnr4HqDkAJvJ9MxBgYBzmepAcnIf6g&e=>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/detnet <https://www.ietf.org/mailman/listinfo/detnet>

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Mon, 7 Nov 2016 21:13:24 +0000

Thanks Norm, I'll add these to my preso. Keep those cards and letters coming.

Ethan.

________________________________
From: Norman Finn <[email-masked]>
Sent: Monday, November 7, 2016 1:07 PM
To: Grossman, Ethan A.
Cc: [email-masked]
Subject: Re: [Detnet] DetNet Security Review

I’m sure there are more.

— Norm

On Nov 7, 2016, at 14:55, Grossman, Ethan A. <[email-masked]<mailto:[email-masked]>> wrote:

Hi Folks,

•DetNet Security Topics

________________________________
From: Maik Seewald (maseewal) <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, October 11, 2016 4:09 AM
To: nfinn; Grossman, Ethan A.
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Detnet] DetNet Security Review

— Norm

Hi Folks,

_______________________________________________
detnet mailing list
[email-masked]<mailto:[email-masked]>
MailScanner has detected a possible fraud attempt from "urldefense.proofpoint.com" claiming to be https://www.ietf.org/mailman/listinfo/detnet<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_detnet&d=DQMFAw&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=W4_8szPlllWiEi0_jSw9Fn4cXKwLHz7G4dAb4O8CLhE&s=oAgQMPFbBI9qmtnr4HqDkAJvJ9MxBgYBzmepAcnIf6g&e=>

_______________________________________________
detnet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/detnet<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_detnet&d=DQMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=arffBfSvfmRPthAKC__0EGe20Or1I6lbp6MPcGH4e68&s=AldgR5SU3g2BbuliOjBj-d_kTr1Vh5wdxenF1YpnIdA&e=>

---

From: Tim Chown <[email-masked]>
Date: Tue, 8 Nov 2016 11:44:18 +0000

Hi,

On 7 Nov 2016, at 21:13, Grossman, Ethan A. <[email-masked]<mailto:[email-masked]>> wrote:

Perhaps one aspect is the impact of security appliances (or indeed any other ‘middlebox’ on a DetNet path) on the DeNet service.

Many firewalls are very bad at handling high throughput flows due to their internal architecture, for example.

Or is the DetNet architecture assuming a clean path e2e?

Tim

Ethan.
From: Norman Finn <[email-masked]<mailto:[email-masked]>>

I’m sure there are more.

— Norm

Hi Folks,

•DetNet Security Topics

— Norm

Hi Folks,

_______________________________________________
detnet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/detnet