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

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

Hi Daniel,

Thank you very much again for your review!

The draft had multiple updates since v08 you reviewed. The latest 
revision is v 11: 
https://mailarchive.ietf.org/arch/msg/detnet/SP63CCzi4C2Biy9mk0Qxrehoa_0

The updates address review comments, and comments and discussions on the 
DetNet WG list.

Please let us know if you have further comments.

Regards,
Janos


On 10/17/2018 10:28 AM, János Farkas wrote:
> 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.