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

[Roman Danyliw <[e-mail]>]

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 <[e-mail]> On Behalf Of Lou Berger
Sent: Thursday, June 25, 2020 9:27 AM
To: Roman Danyliw <[e-mail]>; The IESG <[e-mail]>
Cc: Ethan Grossman <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
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 to https://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