Subject: [Detnet] WG Last Call: draft-ietf-detnet-security-09 - David Black's initial comments

From: "Black, David" <[email-masked]>
Date: Tue, 21 Apr 2020 23:05:00 +0000

Hi Lou,

> The working group last call ends on April 4.
> Please send your comments to the working group mailing list.

Surely May 4 was intended ... as a WG chair, I've been there ... and been off by much more than one month :-).

Here are some initial relatively high-level comments (I may have more to add after a detailed read):

[1-Editorial] The relationship to RFC 7384 deserves more mention.   A statement towards the end of the introduction to indicate that the threat model and the structure of at least the threat analysis are similar because of the importance of time to the security of both time protocols and DetNet would be good to add.

[2-Minor] In section 4, I suggest removing the discussion of Effects and the Effects rows in the table, as they don't appear to play much of a role in the draft.

[3-Editorial] This draft uses a lot of internal cross references to other sections, e.g., in the Related Attacks discussions in section 5.  It would be helpful to the reader to include section names and/or short description of the contents of the referenced section with each cross reference.

[4-Minor] Sections 5.1 and 5.2 should state that path replication and elimination are not available in the IP data plane

[5-Major] Section 5.8 seems incomplete.   It contains a sizeable summary table of attacks, impacts and mitigations, but doesn't provide recommendations on what to do.  Scanning the mitigations column, a good start would be to characterize control message protection and performance analytics as [MUST implement, SHOULD use] and the combination of DetNet authentication and integrity protection as [MUST implement, MAY use].   Both "MUST" requirements are my initial take that I'd be happy to discuss further.

[6-Major] Section 7.1 on the IP data plane seems rather weak - I'm not sure whether it says anything that's seriously useful.  Section 7.2 on the MPLS data plane is much better in directing the reader to relevant security considerations in other documents.

Thanks, --David

> -----Original Message-----
> From: detnet <[email-masked]> On Behalf Of Lou Berger
> Sent: Monday, April 20, 2020 11:01 AM
> To: DetNet WG
> Subject: [Detnet] WG Last Call: draft-ietf-detnet-security-09
> 
> 
> [EXTERNAL EMAIL]
> 
> All,
> 
> This starts a two-week working group last call for
> draft-ietf-detnet-security-09
> 
> The working group last call ends on April 4.
> Please send your comments to the working group mailing list.
> 
> Positive comments, e.g., "I've reviewed this document
> and believe it is ready for publication", are welcome!
> This is useful and important, even from authors.
> 
> Thank you,
> Lou (DetNet Co-Chair & doc Shepherd)
> 
> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet

---

From: Lou Berger <[email-masked]>
Date: Tue, 21 Apr 2020 19:30:28 -0400

Hi David,

----------

> off by much more than one month :-).

Correct - others pointed it out too:-)

I'll leave the rest of your comments to the authors...

Cheers
Lou

> [1-Editorial] The relationship to RFC 7384 deserves more mention.   A 
> statement towards the end of the introduction to indicate that the threat 
> model and the structure of at least the threat analysis are similar because 
> of the importance of time to the security of both time protocols and DetNet 
> would be good to add.
>
> [2-Minor] In section 4, I suggest removing the discussion of Effects and 
> the Effects rows in the table, as they don't appear to play much of a role 
> in the draft.
>
> [3-Editorial] This draft uses a lot of internal cross references to other 
> sections, e.g., in the Related Attacks discussions in section 5.  It would 
> be helpful to the reader to include section names and/or short description 
> of the contents of the referenced section with each cross reference.
>
> [4-Minor] Sections 5.1 and 5.2 should state that path replication and 
> elimination are not available in the IP data plane
>
> [5-Major] Section 5.8 seems incomplete.   It contains a sizeable summary 
> table of attacks, impacts and mitigations, but doesn't provide 
> recommendations on what to do.  Scanning the mitigations column, a good 
> start would be to characterize control message protection and performance 
> analytics as [MUST implement, SHOULD use] and the combination of DetNet 
> authentication and integrity protection as [MUST implement, MAY use].   
> Both "MUST" requirements are my initial take that I'd be happy to discuss 
> further.
>
> [6-Major] Section 7.1 on the IP data plane seems rather weak - I'm not sure 
> whether it says anything that's seriously useful.  Section 7.2 on the MPLS 
> data plane is much better in directing the reader to relevant security 
> considerations in other documents.
>
> Thanks, --David
>

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Wed, 22 Apr 2020 03:58:17 +0000

Hi David,
Thank you for your comments. 

As Editor I claim your items #1, #3 and #4 are valid, and I propose to make those minor editorial changes unless I hear any objection. 

Regarding #2, I personally agree that the "Effects" text is on the abstract side compared to the rest of the draft. Having said that, this was part of a contributed section, and the Effects portion of the section is a part of the overall organization of the section, and I have some concern that eviscerating one leg of the stool may make the whole thing unstable. FWIW, another purpose of that section is to get people thinking about these kinds of effects, and how such effects might have analogies in their implementation - not necessarily to have the examples given be particularly salient in and of themselves. My feeling about the whole section is that it might appeal to a certain audience (e.g. perhaps the more corporate crowd) but not every audience (e.g. perhaps not the deep techie crowd). Does that make any sense? Of course I'd love to have more opinions on this from the WG. 

Regarding #5, this is an informative draft - should we really be saying MUST for anything in this draft? If you think so, I would be very happy to have a brief call with you so that I can understand the specifics of your proposal and get them in there. 

Regarding #6, as an Editor of Very Little Experience (an attempt at a Winnie the Pooh homage there) I have tried very hard to get someone more knowledgeable than I about the IP security issues to contribute text for this, but so far there just have not been any takers. Again if you would be willing to sit down with me and discuss or brainstorm on this I would be more than happy to make time for that, just let me know. Failing that, I don't know what to tell you. And on behalf of Stewart I humbly accept your compliment on the MPLS section ;- ) 

Best,
Ethan (as DetNet Security Draft editor/co-author). 

-----Original Message-----
From: detnet <[email-masked]> On Behalf Of Black, David
Sent: Tuesday, April 21, 2020 4:05 PM
To: Lou Berger <[email-masked]>; DetNet WG <[email-masked]>
Cc: Black, David <[email-masked]>
Subject: [Detnet] WG Last Call: draft-ietf-detnet-security-09 - David Black's initial comments

Hi Lou,

Thanks, --David

> Positive comments, e.g., "I've reviewed this document and believe it 
> is ready for publication", are welcome!

---

From: "Black, David" <[email-masked]>
Date: Wed, 22 Apr 2020 14:48:27 +0000

Hi Ethan,

-- #2 [Minor] -- (Remove Effects text from section 4)

> Regarding #2, I personally agree that the "Effects" text is on the abstract side
> compared to the rest of the draft.

That captures my impression of the text.  If others feel that it's useful and want to keep it, I'd like to better understand why, but can live with it remaining.

-- #5 [Major] -- (absence of implementation recommendations in 5.8)

> Regarding #5, this is an informative draft - should we really be saying MUST for
> anything in this draft? If you think so, I would be very happy to have a brief call
> with you so that I can understand the specifics of your proposal and get them in
> there.

This may be an informative draft, but other DetNet drafts are effectively outsourcing their security considerations  and requirements to this draft (or at least trying to).  For that reason, independent of whether IETF 2119/8174 key words (e.g., MUST, SHOULD, MAY) are used in this draft, the draft does need to provide concise recommendations to implementers on what to do.

-- #6 [Major] -- (weak IP data plane security considerations)

> Regarding #6, as an Editor of Very Little Experience (an attempt at a Winnie
> the Pooh homage there) I have tried very hard to get someone more
> knowledgeable than I about the IP security issues to contribute text for this, but
> so far there just have not been any takers.
[... snip ...]
> And on behalf of Stewart I humbly accept your compliment on the MPLS section ;- )

There's a WG call on the progressing data plane drafts coming up almost immediately - I will surface this concern in that call.  I believe that the security draft has to progress in order to progress the data plane drafts, hence the WG as a whole needs to find Stewart's IP-security-knowledgeable counterpart.  Perhaps the WG chairs or Deb (Routing AD for DetNet) could talk to the Security ADs about convincing someone from the Security Directorate to help out?

Thanks, --David

> From: detnet <[email-masked]> On Behalf Of Grossman, Ethan A.
> Sent: Tuesday, April 21, 2020 11:58 PM
> To: Black, David; Lou Berger; DetNet WG
> Subject: Re: [Detnet] WG Last Call: draft-ietf-detnet-security-09 - David Black's
> initial comments
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi David,
> As Editor I claim your items #1, #3 and #4 are valid, and I propose to make
> those minor editorial changes unless I hear any objection.
> 
> Regarding #2, I personally agree that the "Effects" text is on the abstract side
> compared to the rest of the draft. Having said that, this was part of a
> contributed section, and the Effects portion of the section is a part of the
> overall organization of the section, and I have some concern that eviscerating
> one leg of the stool may make the whole thing unstable. FWIW, another
> purpose of that section is to get people thinking about these kinds of effects,
> and how such effects might have analogies in their implementation - not
> necessarily to have the examples given be particularly salient in and of
> themselves. My feeling about the whole section is that it might appeal to a
> certain audience (e.g. perhaps the more corporate crowd) but not every
> audience (e.g. perhaps not the deep techie crowd). Does that make any sense?
> Of course I'd love to have more opinions on this from the WG.
> 
> Regarding #5, this is an informative draft - should we really be saying MUST for
> anything in this draft? If you think so, I would be very happy to have a brief call
> with you so that I can understand the specifics of your proposal and get them in
> there.
> 
> Regarding #6, as an Editor of Very Little Experience (an attempt at a Winnie
> the Pooh homage there) I have tried very hard to get someone more
> knowledgeable than I about the IP security issues to contribute text for this, but
> so far there just have not been any takers. Again if you would be willing to sit
> down with me and discuss or brainstorm on this I would be more than happy to
> make time for that, just let me know. Failing that, I don't know what to tell you.
> And on behalf of Stewart I humbly accept your compliment on the MPLS section
> ;- )
> 
> Best,
> statement towards the end of the introduction to indicate that the threat model
> and the structure of at least the threat analysis are similar because of the
> importance of time to the security of both time protocols and DetNet would be
> good to add.
> 
> [2-Minor] In section 4, I suggest removing the discussion of Effects and the
> Effects rows in the table, as they don't appear to play much of a role in the
> draft.
> 
> [3-Editorial] This draft uses a lot of internal cross references to other sections,
> e.g., in the Related Attacks discussions in section 5.  It would be helpful to the
> reader to include section names and/or short description of the contents of the
> referenced section with each cross reference.
> 
> [5-Major] Section 5.8 seems incomplete.   It contains a sizeable summary table
> of attacks, impacts and mitigations, but doesn't provide recommendations on
> what to do.  Scanning the mitigations column, a good start would be to
> characterize control message protection and performance analytics as [MUST
> implement, SHOULD use] and the combination of DetNet authentication and
> integrity protection as [MUST implement, MAY use].   Both "MUST"
> requirements are my initial take that I'd be happy to discuss further.
> 
> whether it says anything that's seriously useful.  Section 7.2 on the MPLS data
> plane is much better in directing the reader to relevant security considerations
> in other documents.
> 
> Thanks, --David
>