Subject: [Detnet] FW: New Version Notification for draft-sdt-detnet-security-01.txt

From: "Grossman, Ethan A." <[email-masked]>
Date: Wed, 5 Jul 2017 17:18:56 +0000

FYI, we (the DetNet Security Design Team) have posted an update to the DetNet Security draft (see below). Tal will present the draft update at the IETF99 DetNet WG session. The draft is still a work in progress, and it is our intent to seek adoption of the draft by the WG. 
Best,
Ethan.
Ethan Grossman
DetNet Security draft editor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Sunday, July 02, 2017 10:01 PM
To: John Dowdell <[email-masked]>; Norman Finn <[email-masked]>; Tal Mizrahi <[email-masked]>; Kevin Stanton <[email-masked]>; Subir Das <[email-masked]>; Andrew J. Hacker <[email-masked]>; Andrew Hacker <[email-masked]>; Grossman, Ethan A. <[email-masked]>; Henrik Austad <[email-masked]>
Subject: New Version Notification for draft-sdt-detnet-security-01.txt

A new version of I-D, draft-sdt-detnet-security-01.txt has been successfully submitted by Ethan Grossman and posted to the IETF repository.

Name:		draft-sdt-detnet-security
Revision:	01
Title:		Deterministic Networking (DetNet) Security Considerations
Document date:	2017-07-02
Group:		Individual Submission
Pages:		35
URL:            https://www.ietf.org/internet-drafts/draft-sdt-detnet-security-01.txt
Status:         https://datatracker.ietf.org/doc/draft-sdt-detnet-security/
Htmlized:       https://tools.ietf.org/html/draft-sdt-detnet-security-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-sdt-detnet-security-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-sdt-detnet-security-01

Abstract:
   A deterministic network is one that can carry data flows for real-
   time applications with extremely low data loss rates and bounded
   latency.  Deterministic networks have been successfully deployed in
   real-time operational technology (OT) applications for some years
   (for example [ARINC664P7]).  However, such networks are typically
   isolated from external access, and thus the security threat from
   external attackers is low.  IETF Deterministic Networking (DetNet)
   specifies a set of technologies that enable creation of deterministic
   networks on IP-based networks of potentially wide area (on the scale
   of a corporate network) potentially bringing the OT network into
   contact with Information Technology (IT) traffic and security threats
   that lie outside of a tightly controlled and bounded area (such as
   the internals of an aircraft).  These DetNet technologies have not
   previously been deployed together on a wide area IP-based network,
   and thus can present security considerations that may be new to IP-
   based wide area network designers.  This draft, intended for use by
   DetNet network designers, provides insight into these security
   considerations.  In addition, this draft collects all security-
   related statements from the various DetNet drafts (Architecture, Use
   Cases, etc) into a single location Section 7.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Balázs Varga A <[email-masked]>
Date: Thu, 13 Jul 2017 13:53:15 +0000

Hi Ethan (and the sec-team),

Very good progress. Some comments/questions for clarifications:
** flow identification based on L3/L4 headers 
(noted in 3.2.2.1. DetNet Flow Modification or Spoofing section.)
The updated data plane solution draft defines two encapsulation: 
(i) PseudoWire (for MPLS based PSN) and (ii) IPv6 (for IP based PSN).
So no L4 headers are used within the DetNet domain. 

> ... If L3/L4 headers are involved, for purposes of this
> draft we assume they are encrypted and/or integrity-protected from
> external attackers.

I think this is a quite strong assumption, especially for the PW/MPLS case.
Could You reconsider this? Should we define additional DetNet specific 
security function on edge nodes? I think it may be worth to add explicit 
reference where this assumption is critical.

** R-TAG in 3.2.4.2. Replication-related Header Manipulation
> An attacker can manipulate the replication-related header fields
> (R-TAG).

Please note that "R-Tag" is an IEEE TSN specific field. Such a DetNet
field  is not defined in the data plane draft.

** Flow hijacking in 3.2.4.2. Replication-related Header Manipulation
I have found this as a quite interesting threat. We have not discussed so 
far in detail OAM tools needed for DetNet. In my view path delay related
assumptions should be made based on OAM tools (e.g., delay measurement)
and not based on seq.number. However You have pointed out right that 
the "elimination" function of PREF does not consider to incorporate such 
OAM tools. So ensuring integrity of Seq.Num is also an essential security 
function.

Thanks & Cheers
Bala'zs

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Sunday, July 02, 2017 10:01 PM
To: John Dowdell <[email-masked]>; Norman Finn <[email-masked]>; Tal Mizrahi <[email-masked]>; Kevin Stanton <[email-masked]>; Subir Das <[email-masked]>; Andrew J. Hacker <[email-masked]>; Andrew Hacker <[email-masked]>; Grossman, Ethan A. <[email-masked]>; Henrik Austad <[email-masked]>
Subject: New Version Notification for draft-sdt-detnet-security-01.txt

Abstract:

The IETF Secretariat

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