Re: [Detnet] Roman Danyliw's Discuss on draft-ietf-detnet-mpls-11: (with DISCUSS and COMMENT)

Roman Danyliw <rdd@cert.org> Tue, 08 September 2020 19:20 UTC

Return-Path: <rdd@cert.org>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994F03A0E72; Tue, 8 Sep 2020 12:20:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jp8z3htfip5; Tue, 8 Sep 2020 12:20:21 -0700 (PDT)
Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5DC33A0E71; Tue, 8 Sep 2020 12:20:20 -0700 (PDT)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 088JKHlO018638; Tue, 8 Sep 2020 15:20:17 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 088JKHlO018638
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1599592817; bh=qTJKdwtBuYW/XN6aScvPjq/v4F3gIoES+uZgNjNxGks=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=tBanA1mJU4mEuFxWmC0ryBynOBslbrS/HfFOa27nGFF7Mvb5wCECaXgoUgRWzBFgq Uv6dwcBPrHq3dnzFfpIYdY4pRaPITMbfdyc58UKW9EPGhFj85pLP48IKJhBUARArm1 pmfPz7U798T43YMZ9Wg2D+DA+AhG7nnEgKO30LzI=
Received: from MORRIS.ad.sei.cmu.edu (morris.ad.sei.cmu.edu [147.72.252.46]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 088JKGNT006492; Tue, 8 Sep 2020 15:20:16 -0400
Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MORRIS.ad.sei.cmu.edu (147.72.252.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Tue, 8 Sep 2020 15:20:15 -0400
Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Tue, 8 Sep 2020 15:20:15 -0400
From: Roman Danyliw <rdd@cert.org>
To: Stewart Bryant <stewart.bryant@gmail.com>
CC: The IESG <iesg@ietf.org>, "draft-ietf-detnet-mpls@ietf.org" <draft-ietf-detnet-mpls@ietf.org>, DetNet Chairs <detnet-chairs@ietf.org>, DetNet WG <detnet@ietf.org>, Ethan Grossman <eagros@dolby.com>
Thread-Topic: Roman Danyliw's Discuss on draft-ietf-detnet-mpls-11: (with DISCUSS and COMMENT)
Thread-Index: AQHWhgt49sgcYFtIhU2euoxIUYnbV6lfUgyA//++B7A=
Date: Tue, 08 Sep 2020 19:20:14 +0000
Message-ID: <e3e29088f22549d1b665bafe5b596bbe@cert.org>
References: <159958865571.6798.11039232880316596486@ietfa.amsl.com> <FC34617C-56FD-4E14-B1B4-7FCD81945CA7@gmail.com>
In-Reply-To: <FC34617C-56FD-4E14-B1B4-7FCD81945CA7@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.202.159]
Content-Type: multipart/alternative; boundary="_000_e3e29088f22549d1b665bafe5b596bbecertorg_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/CqCESBO_-XcsNjD64lHyDWxtAZs>
Subject: Re: [Detnet] Roman Danyliw's Discuss on draft-ietf-detnet-mpls-11: (with DISCUSS and COMMENT)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Sep 2020 19:20:23 -0000

Hi Stewart!

Thanks for clarifying, especially since I see the same language is in draft-ietf-detnet-ip-over-mpls.

Let me test my understanding using MPLS specific language.  Are you roughly saying:

OLD
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.

NEW

To prevent the DetNet packets from being delayed by the volume of traffic from external entities using the same MPLS infrastructure, PEs implementing the DetNet architecture could only allow packets to enter the LSP from appropriately authenticated and authorized devices.

Roman

From: Stewart Bryant <stewart.bryant@gmail.com>
Sent: Tuesday, September 8, 2020 2:26 PM
To: Roman Danyliw <rdd@cert.org>
Cc: Stewart Bryant <stewart.bryant@gmail.com>; The IESG <iesg@ietf.org>; draft-ietf-detnet-mpls@ietf.org; DetNet Chairs <detnet-chairs@ietf.org>; DetNet WG <detnet@ietf.org>; Ethan Grossman <eagros@dolby.com>
Subject: Re: Roman Danyliw's Discuss on draft-ietf-detnet-mpls-11: (with DISCUSS and COMMENT)




On 8 Sep 2020, at 19:10, Roman Danyliw via Datatracker <noreply@ietf.org<mailto:noreply@ietf.org>> wrote:

** (Discuss-discuss) Section 6.  Per “To prevent DetNet packets from being
delayed by an entity external to a DetNet domain, DetNet technology definition
can allow for the mitigation of MiTM attacks, for example through the use of
authentication and authorization of devices within the DetNet domain”, can this
attack scenario or the appropriate mitigation be clarified.  If packets are
coming from or going across the DetNet boundary how can any assurances be made?
What is architecture element is the “MiTM” (relay? transit? per Figure 2)?

Remember no packet gets into an MPLS LSP unless specifically put there by a PE (this is fundamental MPLS).

So the requirement on the PE is that it only allows permitted packets to enter the LSP but this is always a requirement placed on a PE.

- Stewart