Re: [secdir] secdir review of draft-ietf-detnet-architecture-08

[János Farkas <[e-mail]>]

Hi Daniel,

Thank you very much for your review!

Please find below how we plan to update the draft to address your comments.

Best regards,
Janos


On 9/25/2018 2:58 AM, Daniel Harkins wrote:
>
>   Hello,
>    I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
>
>    The summary of the review is ready with issues.
>
>    This draft describes an architecture for deterministic networking
> that provides for delivery of packet flows with low packet loss and
> with a maximum amount of latency.
>
>    A nit first. The terminology seems a bit overblown. We have DetNet
> Intermediate nodes that could be relay nodes or transit nodes; and a
> DetNet system that is a DetNet aware system or transit node or
> relay node; and DetNet edge nodes that are relay nodes; and DetNet
> relay nodes that can be bridges, firewalls, or anything else that
> participates in DetNet. Finally, to translate between 802.1 TSN and
> DetNet we have a "relay system" that is an 802.1 term for a DetNet
> intermediate node which, as we have seen, is a DetNet relay node. This
> can be simplified considerably.
The definition of DetNet relay node will be updated.
"A DetNet relay node can be a bridge, a router, a firewall, or any other 
system" will be delated.

OLD:
A DetNet node including a service layer function that
interconnects different DetNet transport layer paths to
provide service protection. A DetNet relay node can be a
bridge, a router, a firewall, or any other system that
participates in the DetNet service layer. It typically
incorporates DetNet transport layer functions as well, in
which case it is collocated with a transit node.

NEW:
A DetNet node including a service layer function that
interconnects different DetNet transport layer paths to
provide service protection. A DetNet relay node operates
at the service layer. It typically incorporates DetNet
transport layer functions as well, in which case it is
collocated with a DetNet transit node.



>    The Security Considerations is thin, especially for an architecture
> draft that is going to be referred to by subsequent drafts which will
> just say something along the lines of, "as an instance of the DetNet
> FooBar, these Security Considerations are those from [ARCH]", where
> ARCH is the RFC that comes out of this I-D. I think there needs to be
> a description of the various points in the architecture that an attacker
> could exploit, and if a point is not exploitable it should say so. For
> instance:
>
>    - is it possible for an attacker to launch a DoS attack by manipulating
>      member flows of a DetNet flow in order to force DetNet nodes to
>      consume buffers they allocated to deal with the DetNet flow?
>
>    - If an end system is not DetNet aware there needs to be a DetNet edge
>      node to handle the encaps of the flow into the DetNet system. Can an
>      attacker in that case introduce packets that shouldn't be part of the
>      DetNet flow into the flow by getting the edge node to encaps them as
>      such?
>
> If there are any assumptions being made-- e.g. "insider attacks are not
> being considered"-- they should be mentioned.
>
>    regards,
>
>    Dan.
>
>
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.