Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt

From: "Black, David" <[email-masked]>
Date: Tue, 6 Nov 2018 07:52:46 +0000

Wearing my 4th/5th blue dots (WG chair role) at this meeting, I would suggest a dual-pronged approach:
- For a general high-level draft, e.g., the use cases draft, referring to a general security draft seems fine.
- For a specific protocol draft, e.g., the two solutions drafts, referring to a general security draft is a
	good start, but ought to be complemented by a discussion of security considerations specific
	to the protocols involved and how they're used.

Thanks, --David

> -----Original Message-----
> From: detnet [mailto:[email-masked]] On Behalf Of Grossman, Ethan
> A.
> Sent: Wednesday, October 17, 2018 7:03 PM
> To: Loa Andersson; Lou Berger; Deborah Brungard
> Cc: [email-masked]; Daniel Harkins
> Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt
> 
> 
> [EXTERNAL EMAIL]
> Please report any suspicious attachments, links, or requests for sensitive
> information.
> 
> 
> Or maybe the answer will be implicit in Daniel Harkins' response to Janos' plan to
> update the architecture draft to refer to the Security draft. If he accepts that,
> then I think that pretty much constitutes acceptance of that strategy? But even
> if so, would that hold for every draft, or are there some types of draft for which
> that wouldn't be acceptable?
> Ethan.
> 
> -----Original Message-----
> From: Grossman, Ethan A.
> Sent: Wednesday, October 17, 2018 10:19 AM
> To: 'Loa Andersson' <[email-masked]>; Lou Berger <[email-masked]>; Deborah
> Brungard <[email-masked]>
> Cc: [email-masked]
> Subject: RE: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt
> 
> Thanks Loa (adding Lou and Deborah).
> 
> So far, the reviewers of the last Use Cases draft have said "Hey where's the
> Security section?" and Lou and I added a Security section that points them at the
> Security draft, and they seemed to be OK with that. I don't know if that would be
> the case for our other drafts.
> 
> I would very much like to have this conversation with the Security AD's and
> Directorate; at present, I personally don't know the most appropriate individuals
> to engage with on this topic - if one of y'all would like to provide me some kind
> of introduction, I'm happy to try to drive some resolution on our strategy here,
> either on the list or in Bangkok.
> 
> Ethan.
> 
> -----Original Message-----
> From: Loa Andersson <[email-masked]>
> Sent: Wednesday, October 17, 2018 2:57 AM
> To: Grossman, Ethan A. <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt
> 
> Ethan, Working Group,
> 
> I don't think there is a one size fits all approach possible for the Security
> Considerations in all DetNet documents. My understanding is that the Security
> Directorate and Security ADs require that each document have an independent
> treatment of the specific threats and concerns for a particular document.
> 
> Whatever strategy we decide on, please make sure that it is agreed on by the
> Security ADs and Directorate.
> 
> /Loa
> 
> On 2018-10-17 15:54, Grossman, Ethan A. wrote:
> > Hi Loa,
> > Various strategies are possible. One possibility is that the other drafts (i.e. not
> the Security draft) could just point at the Security draft such that there would be
> a "single clearing house" for DetNet-specific security info.  That's what the Use
> Cases draft does, however there is also some security-related text in the various
> use cases.
> >
> > At one point I (as Security draft editor) attempted to bring together
> > all of the security-related text from the various other drafts by
> > copying it all into an appendix of the Security draft, since it is
> > sort of handy to have it all in one place. But as Lou pointed out to
> > me, we don't want to make the drafts dependent on each other if we can
> > avoid it, and if such text got edited then it would have to be fixed
> > in two places, so it isn't a perfect scheme. I would say that if a
> > draft author wants to write their own security-related text in their
> > own draft more power to them, but perhaps even more power if they
> > bring it to the Security draft :- )
> >
> > Sorry long answer to a short question. And I'm sure there are other
> strategies... If you have any thoughts on the matter I'd love to hear them, either
> on the list or at IETF 103.
> > Ethan.
> >
> > -----Original Message-----
> > From: Loa Andersson <[email-masked]>
> > Sent: Wednesday, October 17, 2018 12:10 AM
> > To: Grossman, Ethan A. <[email-masked]>
> > Cc: [email-masked]
> > Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt
> >
> > Ethan,
> >
> > I have just had a quick look, but what I see looks good, and certainly gives a
> good overview of the detnet security issues.
> >
> > One question, is it the intention that this document should be used as a general
> reference when writing security considerations for detnet documents?
> >
> > /Loa
> >
> > On 2018-10-17 12:05, Grossman, Ethan A. wrote:
> >> Hi All,
> >> This note is the status update for the DetNet Security Considerations draft in
> advance of IETF 103, in lieu of a presentation slot for it at IETF 103.
> >>
> >> A new version has been posted which includes the discussion on OAM traffic
> and incorporates the "Bounded Jitter" Use Case Common Theme.
> >>
> >> These are minor changes; no substantial work has been done since the last
> DetNet session, so we do not plan to have a slot for this draft at the IETF 103
> DetNet session (though Tal will be presenting on it at the DetNet-TSN meeting
> on the following Sunday).
> >>
> >> I expect that we will convene as many of the authors (and any other
> interested parties) as we have available at IETF 103 to discuss DetNet-data-
> plane-technology-specific security considerations and how to incorporate them
> into the draft as our next steps. If you would like to participate in (be notified
> about) this conversation, please let me know.
> >>
> >> Best,
> >> Ethan (as DetNet Security Considerations draft editor)
> >>
> >> -----Original Message-----
> >> From: detnet <[email-masked]> On Behalf Of
> >> [email-masked]
> >> Sent: Tuesday, October 16, 2018 8:51 PM
> >> To: [email-masked]
> >> Cc: [email-masked]
> >> Subject: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt
> >>
> >>
> >> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> >> This draft is a work item of the Deterministic Networking WG of the IETF.
> >>
> >>           Title           : Deterministic Networking (DetNet) Security Considerations
> >>           Authors         : Tal Mizrahi
> >>                             Ethan Grossman
> >>                             Andrew J. Hacker
> >>                             Subir Das
> >>                             John Dowdell
> >>                             Henrik Austad
> >>                             Kevin Stanton
> >>                             Norman Finn
> >> 	Filename        : draft-ietf-detnet-security-03.txt
> >> 	Pages           : 40
> >> 	Date            : 2018-10-16
> >>
> >> 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.
> >>
> >>
> >> The IETF datatracker status page for this draft is:
> >> https://datatracker.ietf.org/doc/draft-ietf-detnet-security/
> >>
> >> There are also htmlized versions available at:
> >> https://tools.ietf.org/html/draft-ietf-detnet-security-03
> >> https://datatracker.ietf.org/doc/html/draft-ietf-detnet-security-03
> >>
> >> A diff from the previous version is available at:
> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-security-03
> >>
> >>
> >> 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.
> >>
> >> Internet-Drafts are also available by anonymous FTP at:
> >> ftp://ftp.ietf.org/internet-drafts/
> >>
> >> _______________________________________________
> >> detnet mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/detnet
> >>
> >> _______________________________________________
> >> detnet mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/detnet
> >>
> >
> 
> --
> 
> 
> Loa Andersson                        email: [email-masked]
> Senior MPLS Expert
> Bronze Dragon Consulting             phone: +46 739 81 21 64
> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet

---

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

Thanks David, it seems we are now pretty much converged on this strategy. 

My intent for the meeting tomorrow is to establish a list of security aspects related to use of IP and MPLS (as used by DetNet data plane) which are unique to a deterministic network, and thus wouldn't already be covered elsewhere. 

Eventually the writeups on these would be added to the security draft as appropriate, and to (other) individual drafts as appropriate. 
Ethan.

-----Original Message-----
From: Black, David <[email-masked]> 
Sent: Tuesday, November 06, 2018 2:53 PM
To: Grossman, Ethan A. <[email-masked]>; Loa Andersson <[email-masked]>; Lou Berger <[email-masked]>; Deborah Brungard <[email-masked]>
Cc: [email-masked]; Daniel Harkins <[email-masked]>; Black, David <[email-masked]>
Subject: RE: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt

Thanks, --David

> From: detnet [mailto:[email-masked]] On Behalf Of Grossman, 
> Ethan A.
> Please report any suspicious attachments, links, or requests for 
> sensitive information.
> 
> 
> Or maybe the answer will be implicit in Daniel Harkins' response to 
> Janos' plan to update the architecture draft to refer to the Security 
> draft. If he accepts that, then I think that pretty much constitutes 
> acceptance of that strategy? But even if so, would that hold for every 
> draft, or are there some types of draft for which that wouldn't be acceptable?
> Ethan.
> 
> To: 'Loa Andersson' <[email-masked]>; Lou Berger <[email-masked]>; 
> Deborah Brungard <[email-masked]>
> Cc: [email-masked]
> So far, the reviewers of the last Use Cases draft have said "Hey 
> where's the Security section?" and Lou and I added a Security section 
> that points them at the Security draft, and they seemed to be OK with 
> that. I don't know if that would be the case for our other drafts.
> 
> I would very much like to have this conversation with the Security 
> AD's and Directorate; at present, I personally don't know the most 
> appropriate individuals to engage with on this topic - if one of y'all 
> would like to provide me some kind of introduction, I'm happy to try 
> to drive some resolution on our strategy here, either on the list or in Bangkok.
> 
> Ethan.
> 
> I don't think there is a one size fits all approach possible for the 
> Security Considerations in all DetNet documents. My understanding is 
> that the Security Directorate and Security ADs require that each 
> document have an independent treatment of the specific threats and concerns for a particular document.
> 
> Whatever strategy we decide on, please make sure that it is agreed on 
> by the Security ADs and Directorate.
> 
> /Loa
> 
> the Security draft) could just point at the Security draft such that 
> there would be a "single clearing house" for DetNet-specific security 
> info.  That's what the Use Cases draft does, however there is also 
> some security-related text in the various use cases.
> >
> > At one point I (as Security draft editor) attempted to bring 
> > together all of the security-related text from the various other 
> > drafts by copying it all into an appendix of the Security draft, 
> > since it is sort of handy to have it all in one place. But as Lou 
> > pointed out to me, we don't want to make the drafts dependent on 
> > each other if we can avoid it, and if such text got edited then it 
> > would have to be fixed in two places, so it isn't a perfect scheme. 
> > I would say that if a draft author wants to write their own 
> > security-related text in their own draft more power to them, but 
> > perhaps even more power if they bring it to the Security draft :- )
> >
> strategies... If you have any thoughts on the matter I'd love to hear 
> them, either on the list or at IETF 103.
> > Ethan.
> >
> DetNet session, so we do not plan to have a slot for this draft at the 
> IETF 103 DetNet session (though Tal will be presenting on it at the 
> DetNet-TSN meeting on the following Sunday).
> >>
> interested parties) as we have available at IETF 103 to discuss 
> DetNet-data- plane-technology-specific security considerations and how 
> to incorporate them into the draft as our next steps. If you would 
> like to participate in (be notified