Subject: Re: [Detnet] Last Call: <draft-ietf-detnet-architecture-08.txt> (Deterministic Networking Architecture) to Proposed Standard

From: "Maik Seewald (maseewal)" <[email-masked]>
Date: Mon, 24 Sep 2018 11:28:30 +0000

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)"
<[email-masked] on behalf of pthubert=[email-masked]>
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 <[email-masked]>
>> Sent: lundi 24 septembre 2018 07:56
>> To: Brian E Carpenter <[email-masked]>
>> Cc: [email-masked]; [email-masked];
>> [email-masked]
>> 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 [[email-masked]]
>> Sent: Sunday, September 23, 2018 9:56 PM
>> Cc: [email-masked]; [email-masked];
>> [email-masked]
>> 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.
>> 
>> 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.
>> 
>> > 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.
>> 
>> >    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.
>> 
>> Regards
>>    Brian Carpenter
>
>_______________________________________________
>detnet mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/detnet