Subject: Re: [Detnet] Roman Danyliw's Discuss on draft-ietf-detnet-ip-06: (with DISCUSS and COMMENT)

From: Lou Berger <[email-masked]>
Date: Fri, 10 Jul 2020 06:43:53 -0400

Roman,

Do you have any issues that are unresolved in the update version? -- I 
see you're discuss hasn't been cleared.

Thanks,

Lou

On 6/25/2020 10:26 AM, Lou Berger wrote:
>
> Thanks Roman!
>
> On 6/25/2020 10:11 AM, Roman Danyliw wrote:
>>
>> Hi Lou!
>>
>> Thanks for the quick response with the edits and clarifications.  In 
>> that spirit and resolving blocking things before the telechat -- the 
>> proposed edits addresses my DISCUSSes; consider all of the COMMENTs 
>> but the last resolved (give me a chance to put fingers to keyboard).
>>
>> Roman
>>
>> *From:* iesg <[email-masked]> *On Behalf Of * Lou Berger
>> *Sent:* Thursday, June 25, 2020 9:27 AM
>> *To:* Roman Danyliw <[email-masked]>; The IESG <[email-masked]>
>> *Cc:* Ethan Grossman <[email-masked]>; [email-masked]; 
>> [email-masked]; [email-masked]
>> *Subject:* Re: Roman Danyliw's Discuss on draft-ietf-detnet-ip-06: 
>> (with DISCUSS and COMMENT)
>>
>> Hi,
>>
>> Thank you for the comments/discuss.  Please see responses (as 
>> co-author) in line below
>>
>> On 6/22/2020 2:51 PM, Roman Danyliw via Datatracker wrote:
>>
>>     Roman Danyliw has entered the following ballot position for
>>
>>     draft-ietf-detnet-ip-06: Discuss
>>
>>     When responding, please keep the subject line intact and reply to all
>>
>>     email addresses included in the To and CC lines. (Feel free to cut this
>>
>>     introductory paragraph, however.)
>>
>>     Please refer tohttps://www.ietf.org/iesg/statement/discuss-criteria.html
>>
>>     for more information about IESG DISCUSS and COMMENT positions.
>>
>>     The document, along with other ballot positions, can be found here:
>>
>>     https://datatracker.ietf.org/doc/draft-ietf-detnet-ip/
>>
>>     ----------------------------------------------------------------------
>>
>>     DISCUSS:
>>
>>     ----------------------------------------------------------------------
>>
>>     A few easy clarifications:
>>
>>     ** Section 7.  Per “From a data plane perspective this document does not add or
>>
>>     modify any header information”, this statement, which is also found in Section
>>
>>     9.1 of draft-ietf-detnet-security-10 does not seem consistent with Section 3
>>
>>     which states “… however modification of these fields is allowed, for example
>>
>>     changing the DSCP value, when required by the DetNet service”.
>>
>> This is actually a mistake.  DetNet does not modify standard DSCP 
>> remarking.  I just addressed this as part of addressing Murry's 
>> comments.  The text should read:
>>
>>    Non-DetNet and DetNet IP packets are identical on the wire.
>>    Generally the fields used in flow identification are forwarded
>>    unmodified.  However, standard modification of the DSCP field
>>    [RFC2474] is not precluded.
>>
>>
>>     ** Section 7.  RFC8655 reminds us that “Security considerations for DetNet are
>>
>>     constrained (compared to, for example, the open Internet) because DetNet is
>>
>>     defined to operate only within a single administrative domain”.  However, the
>>
>>     only IP-specific guidance on preventing escape from the DetNet domain is in
>>
>>     Section 4.2 (“Note that not mixing DetNet and non-DetNet traffic within a
>>
>>     single 5-tuple,  as described above, enables simpler 5-tuple filters to be used
>>
>>     (or re-used) at the edges of a DetNet network to prevent
>>
>>     non-congestion-responsive DetNet traffic from escaping the DetNet domain.”).
>>
>>     Please provide more prescriptive guidance in this section.
>>
>> How about adding the following to section 6.
>>
>> The DetNet controller plane MUST ensure that 
>> non-congestion-responsive DetNet traffic is not forwarded outside a 
>> DetNet domain.
>>
>>     ** Section 7.  The guidance from RFC8655 and draft-ietf-detnet-security needs
>>
>>     to be deconflicted relative to confidentiality.  The following assertions are
>>
>>     stated in a single paragraph:
>>
>>     (a) The primary considerations for the data plane is to maintain
>>
>>         integrity of data and delivery of the associated DetNet service
>>
>>         traversing the DetNet network.
>>
>>     (b) Application flows can be protected
>>
>>         through whatever means is provided by the underlying technology.  For
>>
>>         example, encryption may be used, such as that provided by IPSec
>>
>>         [RFC4301] for IP flows and/or by an underlying sub-net using MACSec
>>
>>         [IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows.
>>
>>     (a) appears to be a cut-and-paste (or maybe vice versa) from Section 9 of
>>
>>     draft-ietf-detnet-security-10
>>
>>     (b) appears to be a cut-and-paste from Section 5 of RFC8655.
>>
>>     The concatenation of (a) + (b) appears to be unique to this document.
>>
>>     When RFC8655 states (b), it prefaced with “[t]o maintain confidentiality of
>>
>>     data traversing the DetNet, application flows can be protected through whatever
>>
>>     means is provided by the underlying technology.”  (a) makes no references to
>>
>>     confidentiality.  It seems like it should.
>>
>> Sure, added.
>>
>>     ----------------------------------------------------------------------
>>
>>     COMMENT:
>>
>>     ----------------------------------------------------------------------
>>
>>     Thanks for responding to the SECDIR review (and thank you Tero for doing it).
>>
>>     ** Section 3.  I wasn’t able to follow how the reference architectures (Figure
>>
>>     1 and 2) in this section had bearing on the normative behavior in Section 5 and
>>
>>     6.
>>
>> Figures 1 and 2 provide overall context for the node specific 
>> behavior defined in 5 and 6.
>>
>>     ** Section 3. Editorial.  As a reader, I would have benefited from a forward
>>
>>     reference to Section 5 somewhere in this section.  As I was reading this text,
>>
>>     I kept looking for specify in exactly which fields go into the tuple and under
>>
>>     what circumstances.
>>
>> sure.
>>
>>     ** Section 3.  Per “Same can be valid for flow aggregates”, I didn’t follow
>>
>>     what this meant.  Did you mean, “The same can be true for flow aggregates”,
>>
>>     editorially? But I’m still not sure what a “flow aggregates” is in this case.
>>
>> This has been fixed per my previous mail.
>>
>>     ** Section 3.  Per “… however modification of these fields is allowed, for
>>
>>     example changing the DSCP value, when required by the DetNet service”, is the
>>
>>     DSCP the only field that is permitted to be modified?  Perhaps I missed it, but
>>
>>     I didn’t see this behavior covered in the subsequent guidance (i.e., outside of
>>
>>     this overview) -- see related DISCUSS above.
>>
>> per above, detnet does not preclude standard remarking, i.,e., it 
>> allows for it.
>>
>>     ** Section 4.  Per “This section provides informative considerations …”, is
>>
>>     that the same thing as saying this entire section is not normative?  If so, I
>>
>>     was surprised by the use of RFC2119 language in this section.
>>
>> "informative" should have been removed when the 2119 language was 
>> added.  I have removed it.
>>
>>     ** Section 4.2.  Per “Note that not mixing DetNet and non-DetNet traffic within
>>
>>     a single 5-tuple”, how does one do flow identification if such mixing is done?
>>
>> This is a requirement on the application.  It's the only one that 
>> could identify the different traffic types when such mixing occurs.
>>
>>     ** Section 4.3.1.  Is there a pointer that can be provided to explain how
>>
>>     DetNet nodes are to “ensure that the CoS service classes do not impact the
>>
>>     congestion protection and latency control mechanisms used to provide DetNet
>>
>>     QoS?”
>>
>> This is a tough one as the IETF has generally avoided defining 
>> internal behavior (unlike some other SDOs). Section 5.3 does provide 
>> some additional information.
>>
>>     ** Section 5.1.2.2.  Per “DetNet flow identification for ICMP is achieved based
>>
>>     on the protocol’s header”, I recommend being precise by explicitly saying which
>>
>>     protocol header field and which value (just as was done in for TCP, UDP and
>>
>>     IPSec.).
>>
>> In the current definition, it's just the protocol number:
>>
>> s/protocol's header/protocol number in the IP header.
>>
>>     ** Section 7.  It wasn’t clear to me which security consideration mentioned
>>
>>     here were specific to a DetNet data plane when IP is used for the forwarding
>>
>>     sub-layer.  I have no issues restating key considerations, but this write-up
>>
>>     was generic.
>>
>> I'm not sure what else to add here.  If you have suggestion, we're 
>> more than open to them.
>>
>> Changes covered here can be previewed at:
>> https://github.com/detnet-wg/data-plane-drafts/tree/working/lb/iesg-0625
>> https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?url=https://raw.githubusercontent.com/detnet-wg/data-plane-drafts/working/lb/iesg-0625/ip/draft-ietf-detnet-ip.xml
>> Thank you!
>> Lou
>>
>
> This body part will be downloaded on demand.

---

From: Roman Danyliw <[email-masked]>
Date: Fri, 10 Jul 2020 11:25:11 +0000

Hi Lou!

Thanks for the reminder and again for these changes. I didn’t notice there was updated draft that merged those changes.  I’ve cleared my ballot.

Regards,
Roman

From: iesg <[email-masked]> On Behalf Of Lou Berger
Sent: Friday, July 10, 2020 6:44 AM
To: Roman Danyliw <[email-masked]>; The IESG <[email-masked]>
Cc: Ethan Grossman <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Detnet] Roman Danyliw's Discuss on draft-ietf-detnet-ip-06: (with DISCUSS and COMMENT)

Roman,

Do you have any issues that are unresolved in the update version? -- I see you're discuss hasn't been cleared.

Thanks,

Lou

Thanks Roman!

Thanks for the quick response with the edits and clarifications.  In that spirit and resolving blocking things before the telechat -- the proposed edits addresses my DISCUSSes; consider all of the COMMENTs but the last resolved (give me a chance to put fingers to keyboard).

Roman

From: iesg <[email-masked]><mailto:[email-masked]> On Behalf Of Lou Berger
Sent: Thursday, June 25, 2020 9:27 AM
To: Roman Danyliw <[email-masked]><mailto:[email-masked]>; The IESG <[email-masked]><mailto:[email-masked]>
Cc: Ethan Grossman <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Roman Danyliw's Discuss on draft-ietf-detnet-ip-06: (with DISCUSS and COMMENT)

Hi,

Thank you for the comments/discuss.  Please see responses (as co-author) in line below

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html

DISCUSS:

changing the DSCP value, when required by the DetNet service”.
This is actually a mistake.  DetNet does not modify standard DSCP remarking.  I just addressed this as part of addressing Murry's comments.  The text should read:

The DetNet controller plane MUST ensure that non-congestion-responsive DetNet traffic is not forwarded outside a DetNet domain.

COMMENT:

6.
Figures 1 and 2 provide overall context for the node specific behavior defined in 5 and 6.

what circumstances.
sure.

per above, detnet does not preclude standard remarking, i.,e., it allows for it.

was surprised by the use of RFC2119 language in this section.
"informative" should have been removed when the 2119 language was added.  I have removed it.

This is a requirement on the application.  It's the only one that could identify the different traffic types when such mixing occurs.

QoS?”

This is a tough one as the IETF has generally avoided defining internal behavior (unlike some other SDOs).  Section 5.3 does provide some additional information.

IPSec.).

was generic.

I'm not sure what else to add here.  If you have suggestion, we're more than open to them.

Thank you!

Lou