Re: [Tsv-art] [Last-Call] Tsvart last call review of draft-ietf-detnet-ip-05

Benjamin Kaduk <> Wed, 24 June 2020 16:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BCFB23A100F; Wed, 24 Jun 2020 09:37:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NvCYwRzOZXGk; Wed, 24 Jun 2020 09:37:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0D31E3A100D; Wed, 24 Jun 2020 09:37:41 -0700 (PDT)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 05OGatTN018497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 Jun 2020 12:36:57 -0400
Date: Wed, 24 Jun 2020 09:36:55 -0700
From: Benjamin Kaduk <>
To: Bob Briscoe <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <>
Subject: Re: [Tsv-art] [Last-Call] Tsvart last call review of draft-ietf-detnet-ip-05
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Jun 2020 16:37:44 -0000

Hi Bob,

Thanks for the great review comments; I repeated or referred to several of
them in my own review.  One note on the security considerations:

On Sun, Mar 15, 2020 at 03:57:31PM -0700, Bob Briscoe via Datatracker wrote:
>    "To prevent DetNet packets
>    from being delayed by an entity external to a DetNet domain, DetNet
>    technology definition can allow for the mitigation of Man-In-The-
>    Middle attacks, for example through use of authentication and
>    authorization of devices within the DetNet domain."
>    Eh? What does mitigation of MITM attacks mean? Either they're prevented or
>    they're not. Mitigated implies just slightly prevented. How does mitigation
>    of MITM attacks prevent delay? Seems a rather big jump.

I believe this language is mostly copied from RFC 8655, and was added there
at my suggestion.  My understanding is that MITM attacks from non-DetNet
entities are prevented, but if there is a malicious device that has
credentials authorized to participate in the DetNet domain (e.g., a
compromised router), MITM attacks by that device are not prevented.

This is perhaps also in the context of the DetNet threat model being
intrinsically different from the normal BCP 72 one, since a BCP 72 attacker
can just drop all traffic and induce failure of the DetNet goals.  So in
order to have anything meaningful to say we are forced to consider a
weaker attacker that is, e.g., only on some parts of the network or does
not have full control over all devices not explicitly trusted.