Hi Brian,

Thank you very much for your review!

Please find below more in-line on how we will update the draft to 
resolve your comments.

Best regards,
Janos


On 9/24/2018 1:28 PM, Maik Seewald (maseewal) wrote:
> Given the criticality of the use cases (IACS), authentication and
> authorisation of the packet source appears to be imperative.
> IMHO, applying security controls to the infrastructure elements only
> crates a secure architecture for potential hostile traffic.
> Application security might/will exist on-top, providing a multi-layer
> approach.
>
> BR, Maik
>
>
> On 24.09.18, 08:27, "detnet on behalf of Pascal Thubert (pthubert)"
> <detnet-bounces@ietf.org on behalf of pthubert=40cisco.com@dmarc.ietf.org>
> wrote:
>
>>>>     Security must cover:
>>>>
>>>>     o  the protection of the signaling protocol
>>>>
>>>>     o  the authentication and authorization of the controlling systems
>>>>
>>>>     o  the identification and shaping of the DetNet flows
>>> What about the identification and authorization of the nodes allowed to
>>> generate DetNet flows within a domain, and of the border nodes at the
>>> edges
>>> of the domain?
>>>
>>> <NWF> I'll let others comment on that one.  I'm not clear about the
>>> boundaries and the amount of overlap between network security and
>>> application security, in this case.
>> I agree with Brian; the source of the flow must be authenticated. I
>> believe that a secure identification of the flow involves that, but it
>> could make sense to emphasize this.
>> What about:
>>
>>>>     o  the identification and shaping of the DetNet flows, including
>>> authorization of the packet source
>> Note: we have imposed that a flow has a single source and one or mane end
>> points. There are MP2MP use cases in industrial. Unsure how to fully
>> characterize them but the most basic methods are source A or source B,
>> and source A and source B. The latter can be reserved as 2 independent
>> DetNet flows, but the former needs methods that we do not have.
>>
>> Cheers;
>>
>> Pascal
>>
>>> -----Original Message-----
>>> From: Norman Finn <norman.finn@mail01.huawei.com>
>>> Sent: lundi 24 septembre 2018 07:56
>>> To: Brian E Carpenter <brian.e.carpenter@gmail.com>
>>> Cc: draft-ietf-detnet-architecture.all@ietf.org; detnet@ietf.org;
>>> db3546@att.com
>>> Subject: RE: Last Call: <draft-ietf-detnet-architecture-08.txt>
>>> (Deterministic
>>> Networking Architecture) to Proposed Standard
>>>
>>> Thanks for the comments, Brian.  I'll try to respond; others will have
>>> opinions,
>>> I'm sure.  See <NWF> ________________________________________
>>> From: Brian E Carpenter [brian.e.carpenter@gmail.com]
>>> Sent: Sunday, September 23, 2018 9:56 PM
>>> Cc: draft-ietf-detnet-architecture.all@ietf.org; detnet@ietf.org;
>>> db3546@att.com
>>> Subject: Re: Last Call: <draft-ietf-detnet-architecture-08.txt>
>>> (Deterministic
>>> Networking Architecture) to Proposed Standard
>>>
>>> Hi,
>>>
>>> The term "Flow-ID" is used frequently but is not defined or explained.
>>> Section 4.7 "Flow identification at technology borders" doesn't really
>>> help on
>>> this.
>>>
>>> In fact, it isn't entirely clear what the word "flow" itself means.
>>> You might think it's obvious, but when designing the rules for the
>>> IPv6 Flow Label we stumbled until we got to this:
>>>
>>>     From the viewpoint of the network layer, a flow is a sequence of
>>>     packets sent from a particular source to a particular unicast,
>>>     anycast, or multicast destination that a node desires to label as a
>>>     flow.
>>>
>>> In other words, a flow is whatever set of packets the source chooses to
>>> assert
>>> is a flow. Is that the DetNet definition too?
>>>
>>> <NWF>  In 2.1 we have, "A DetNet flow is a sequence of packets to
>>> which the
>>> DetNet service is to be provided."  This could be expanded to, "A
>>> DetNet flow
>>> is a sequence of packets from one source to one or more destinations,
>>> which
>>> conform uniquely to a flow identifier, and to which the DetNet service
>>> is to be
>>> provided."  The idea is that the process of creating a reservation for
>>> a DetNet
>>> flow always provides a means for unambiguously identifying to which
>>> DetNet
>>> flow, if any, a packet belongs.
The definition will be updated as suggested by Norm.


>>>
>>> Also:
>>>> The Flow-ID must be unique inside a given domain.
>>> It isn't clear from the discussion of Flow-ID mapping whether this
>>> implies that
>>> the value of the upper layer (the deepest
>>> encapsulated) Flow-ID is is intended to be preserved end-to-end.
>>> It appears so from the examples in Figure 10 and Figure 11, but based
>>> on the
>>> experience that this has been a contentious point for the IPv6 Flow
>>> Label, I
>>> recommend that this should be clearly defined in the architecture.
>>>
>>> <NWF> A better way to phrase the uniqueness requirement is that any
>>> given
>>> relay node must be able to unambiguously assign to a packet the
>>> resources
>>> reserved for that packet's DetNet flow.  That's easiest if the
>>> identifiers are
>>> unique over domain, of course.  I'd like to hear from others, on this.
The sentence will be updated to make it clearer:

OLD:
    The Flow-ID must be unique inside a given domain.  Note that the
    Flow-ID added to the App-flow is still present in the packet, but
    transport nodes may lack the function to recognize it; that's why the
    additional Flow-ID is added.

NEW:
"The Flow-ID must be unique inside a given domain. Note that the
Flow-ID added to the App-flow by higher layer(s) is preserved in the
packet, but transport nodes may lack the function to recognize it;
that’s why the additional Flow-ID is added."



>>>
>>>> 3.2.1.1.  "Eliminate congestion loss"
>>> Shouldn't there be some discussion here about buffer bloat, which
>>> serves to
>>> reduce congestion loss but does terrible things to latency? The
>>> discussion at
>>> the beginning of Section 4.5 "Queuing, Shaping, Scheduling, and
>>> Preemption"
>>> doesn't make it clear how buffer bloat is avoided at large scale, where
>>> many
>>> DetNet flows are going through the same choke point. Having reserved
>>> buffers
>>> per flow doesn't prevent the total buffer space creeping up, and clever
>>> queueing algorithms can't completely save you when that happens.
>>>
>>> <NWF> As we are trying to make more clear in the bounded-latency draft,
>>> one
>>> of the characteristics of any queuing strategy that is useful for
>>> DetNet is that
>>> one can compute no later than flow reservation time how much buffer
>>> space
>>> is required to guarantee zero congestion loss.  If you can't, then the
>>> queuing
>>> strategy is unsuitable.  Different strategies make different trade-offs
>>> regarding
>>> buffer space, latency, data plane and control plane complexity, etc.
>>> Generally
>>> speaking, buffer space will grow with the number of flows visible to a
>>> given
>>> relay node.  Flow aggregation is helpful, here, but one can expect a
>>> DetNet
>>> relay node to require more buffer space than a non-DetNet node.  And,
>>> if you
>>> calculate that you haven't enough buffers to ensure zero congestion
>>> loss, you
>>> refuse the reservation.
  The next paragraph in 3.2.1.1 explains that regulation is needed and 
applied, which actually avoids buffer bloat.

"Ensuring adequate buffering requires, in turn, that the source, and
every DetNet node along the path to the destination (or nearly every
node, see Section 4.3.3) be careful to regulate its output to not
exceed the data rate for any DetNet flow, except for brief periods
when making up for interfering traffic. Any packet sent ahead of its
time potentially adds to the number of buffers required by the next
hop DetNet node and may thus exceed the resources allocated for a
particular DetNet flow.
"

A sentence will be added to the end of the paragraph to make it clearer:

"Ensuring adequate buffering requires, in turn, that the source, and
every DetNet node along the path to the destination (or nearly every
node, see Section 4.3.3) be careful to regulate its output to not
exceed the data rate for any DetNet flow, except for brief periods
when making up for interfering traffic. Any packet sent ahead of its
time potentially adds to the number of buffers required by the next
hop DetNet node and may thus exceed the resources allocated for a
particular DetNet flow. The regulation ensures adequate use of the
buffer space.
"

>>>
>>>>     Security must cover:
>>>>
>>>>     o  the protection of the signaling protocol
>>>>
>>>>     o  the authentication and authorization of the controlling systems
>>>>
>>>>     o  the identification and shaping of the DetNet flows
>>> What about the identification and authorization of the nodes allowed to
>>> generate DetNet flows within a domain, and of the border nodes at the
>>> edges
>>> of the domain?
>>>
>>> <NWF> I'll let others comment on that one.  I'm not clear about the
>>> boundaries and the amount of overlap between network security and
>>> application security, in this case.

Security issues and considerations are addressed by the DetNet Security 
draft: https://datatracker.ietf.org/doc/draft-ietf-detnet-security.
Reference will be added to the DetNet security document.


>>>
>>> Regards
>>>     Brian Carpenter
>> _______________________________________________
>> detnet mailing list
>> detnet@ietf.org
>> https://www.ietf.org/mailman/listinfo/detnet