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

[Lou Berger <[e-mail]>]

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 <[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 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
>