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

[Lou Berger <[e-mail]>]

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

>
>
>