Re: [Detnet] Rtgdir last call review of draft-ietf-detnet-security-10 and AD comments

["Grossman, Ethan A." <[e-mail]>]

You got it, thank you!
Ethan.

-----Original Message-----
From: BRUNGARD, DEBORAH A <[e-mail]> 
Sent: Friday, August 14, 2020 2:54 PM
To: Grossman, Ethan A. <[e-mail]>; Stewart Bryant <[e-mail]>
Cc: [e-mail]; DetNet Chairs <[e-mail]>; [e-mail]
Subject: RE: [Detnet] Rtgdir last call review of draft-ietf-detnet-security-10 and AD comments

Hi Ethan,

Suggest breaking it into two paragraphs and I prefer the original introduction sentence and a swap of implies/s/requires as "implies" is a bit weak. Suggested a few other tweaks.

A DetNet (deterministic network) provides
        specific performance guarantees to its data flows, such as extremely low data loss rates and
        bounded latency. As a result, securing a DetNet requires that in addition to the best
        practice security measures taken for any mission-critical network, additional security
        measures may be needed to secure the intended operation of these novel service properties.

        This document addresses DetNet-specific security considerations from the perspectives of
        both the DetNet system-level designer and component designer. System considerations include
        a threat model, taxonomy of relevant attacks, and associations of threats versus use cases
        and service properties. Component-level considerations include ingress filtering and packet
        arrival time violation detection. This document also addresses DetNet security
        considerations specific to the IP and MPLS data plane technologies thereby complementing the
        Security Considerations sections of the various DetNet Data Plane (and other) DetNet
        documents.

Thanks!
Deborah

-----Original Message-----
From: Grossman, Ethan A. <[e-mail]>
Sent: Friday, August 14, 2020 5:30 PM
To: BRUNGARD, DEBORAH A <[e-mail]>; Stewart Bryant <[e-mail]>
Cc: [e-mail]; DetNet Chairs <[e-mail]>; [e-mail]
Subject: RE: [Detnet] Rtgdir last call review of draft-ietf-detnet-security-10 and AD comments

Hi Deborah,
Funny you should say that (as Adrian also said). I just rewrote it like this: 

A DetNet (as described in RFC8557, Deterministic Networking Problem Statement) provides
        specific performance guarantees to its data flows, such as extremely low data loss rates and
        bounded latency. As a result, securing a DetNet implies that in addition to the best
        practice security measures taken for any mission-critical network, additional security
        measures may be needed to secure the intended operation of these novel service properties.
        This document addresses DetNet-specific security considerations from the perspectives of
        both the DetNet system-level designer and component designer. System considerations include
        a threat model, taxonomy of relevant attacks, and associations of threats versus use cases
        and service properties. Component-level include topics such as ingress filtering and packet
        arrival time violation detection. This document also addresses DetNet security
        considerations specific to the IP and MPLS data plane technologies thereby complementing the
        Security Considerations sections of the various DetNet Data Plane (and other) DetNet
        documents.

OK? 
Ethan.
-----Original Message-----
From: BRUNGARD, DEBORAH A <[e-mail]>
Sent: Friday, August 14, 2020 2:27 PM
To: Grossman, Ethan A. <[e-mail]>; Stewart Bryant <[e-mail]>
Cc: [e-mail]; DetNet Chairs <[e-mail]>
Subject: RE: [Detnet] Rtgdir last call review of draft-ietf-detnet-security-10 and AD comments

Hi,

I forgot to add one more comment - you need to shorten the abstract - it needs to be an abstract😊

Good weekends!
Deborah


-----Original Message-----
From: Grossman, Ethan A. <[e-mail]>
Sent: Friday, August 14, 2020 1:52 PM
To: Stewart Bryant <[e-mail]>
Cc: BRUNGARD, DEBORAH A <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: RE: [Detnet] Rtgdir last call review of draft-ietf-detnet-security-10 and AD comments

Thanks for the offer Stewart, yes, let's do that. I suppose I can make a pass through them all today, then enumerate the open ones, then we can divvy them out in a concise way. 
Ethan.

-----Original Message-----
From: Stewart Bryant <[e-mail]>
Sent: Friday, August 14, 2020 10:19 AM
To: Grossman, Ethan A. <[e-mail]>
Cc: Stewart Bryant <[e-mail]>; BRUNGARD, DEBORAH A <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Detnet] Rtgdir last call review of draft-ietf-detnet-security-10 and AD comments

Ethan

Why not ask the “usual suspects" to a call and we will go though the issues one by one and parcel out text assignments?

Stewart



> On 14 Aug 2020, at 17:36, Grossman, Ethan A. <[e-mail]> wrote:
> 
> Hi Adrian, Deborah, WG,
> Today (as editor of the Security draft) I am attempting to address Adrian's review comments. Reading through them, several of them are basically out of my depth, and I'm not sure how I would fill in the requested details, for example questions along the line of "you can't just say "the appropriate [measures]" you have to tell them what to do".
> 
> Is there any chance anyone on this thread who has more domain knowledge than I do could spend a little time with me to give me some concrete clues as to what could be said to address some of these items? I can do the wordsmithing, and even some background reading, but it would be extremely helpful to get a well-informed shove in the right direction. 
> 
> My strategy today is to first address the nits and other straightforward items, and then as I attempt the others I will send out emails to the WG proposing as much text as I can conjure up, and it would be great if I got any responses. But if anyone has time for an impromptu webconf session to review the items en masse that would be appreciated; I can set that up on the spot. 
> 
> Thanks,
> Your faithful servant,
> Ethan.
> 
> -----Original Message-----
> From: BRUNGARD, DEBORAH A <[e-mail]>
> Sent: Thursday, August 13, 2020 4:21 PM
> To: [e-mail]; 'Stewart Bryant' <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]
> Subject: RE: [Detnet] Rtgdir last call review of
> draft-ietf-detnet-security-10 and AD comments
> 
> Hi,
> 
> Much thanks Adrian for your review!
> 
> Without getting into the debate on the term itself, I don't think MITM is concise enough. In RFC3552, MITM is just one of multiple active attack possibilities. Same for Injector, it also is an active attack. It's not simply MITM vs. injector. Stewart is correct - on-path can be an observer (passive). I think we need to define per RFC3552, not the Network Time Protocol threat model.  It would be better to align with the security terms and use on-path /off-path vs. internal/external. I think this is part of the confusion as the definition of internal in the document is mixing with the definition of MITM in RFC3552.
> 
> The checked items in Figure 1 are not MITM (they could be done by a MITM), they are basically message modification (RFC3552). So I'm actually not sure the value of this breakdown of MITM vs. Injector? These terms are only used in 5.1 and Figure 1, they are not used in the rest of the document. Suggest it would be more accurate to simply say "active" (document already has the term in 5.1) and remove these terms/breakdown in Figure 1. Same for internal/external, they are not used in the rest of the document.
> 
> Section 5.1 has the terms "active" and "passive" but doesn't define them. Need to define.
> 
> The document is very comprehensive - congrats to the authors and the 
> working group! With the couple of fixes to sort out the definitions in 
> Section 5, it will be ready for the super scrutiny during Last 
> Call/Sec ADs😊
> 
> Thanks,
> Deborah
> (recovering after a week without power)
> 
> -----Original Message-----
> From: Adrian Farrel <[e-mail]>
> Sent: Friday, August 7, 2020 1:10 PM
> To: 'Stewart Bryant' <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]
> Subject: RE: [Detnet] Rtgdir last call review of
> draft-ietf-detnet-security-10
> 
> I can't decide whether to get into this or not 😊
> 
> My review said, "It would be nice to avoid," not, "You must avoid."
> The review is principally for the AD, and they will tell you whether you need to action this.
> I made a constructive suggestion of an alternative phrase, but you are allowed to choose others.
> 
> The thing about the term "man-in-the-middle" is not that it is directly making a specific man appear evil, it is that it associates the word "man" with the concept "evil" and therefore subtly changes the long-term perception of "man". There is, in fact, nothing about this type of attack that is specific to a man, and not all attackers are men, nor are all men attackers.
> 
> This is a minor issue for me, and (to some extent) I wanted to experiment with draft-knodel-terminology to see what reaction it would get if the changes it suggests were made as a request rather than as an order.
> 
> Cheers,
> Adrian
> 
> -----Original Message-----
> From: Stewart Bryant <[e-mail]>
> Sent: 06 August 2020 13:52
> To: Adrian Farrel <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: [Detnet] Rtgdir last call review of
> draft-ietf-detnet-security-10
> 
> 
>> ---
>> 
>> It would be nice to avoid the term "man-in-the-middle" (and 
>> coresponding
>> "MITM") in favour of the term "on-path attacker". It is less 
>> problematic as a term, and no less accurate.
>> 
>> Although "man-in-the-middle" is well established, I think you could 
>> easily avoid it and if you feel necessary you could use "An on-path 
>> attacker (formerly known as a man-in-the-middle) ..."
> 
> I sort of understand why you want to change MITM, although given that the man you have in mind is evil I am not sure whether it is that objectionable in this context. However I am not sure on-path is the right term. MITM normally implies an entity that can modify traffic in flight, whereas an on path attacker may simply be an observer.
> 
> Maybe AITM (attacker ....) would be a better gender neutral term.
> 
> Stewart
> 
>