Re: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-mpls-05

Stewart Bryant <stewart.bryant@gmail.com> Fri, 13 March 2020 12:41 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53AD53A1739; Fri, 13 Mar 2020 05:41:30 -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, FREEMAIL_FROM=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 (2048-bit key) header.d=gmail.com
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 9ZoYtzimtLpz; Fri, 13 Mar 2020 05:41:28 -0700 (PDT)
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D1133A1738; Fri, 13 Mar 2020 05:41:22 -0700 (PDT)
Received: by mail-wm1-x333.google.com with SMTP id 6so9761406wmi.5; Fri, 13 Mar 2020 05:41:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uaW3zio8OnAbYpY38vKuXoqUF+Orl6fkl80B5tbhoSg=; b=popldn4E/SexRagI2AzPBiyRlCL3gVCJ1wR186nErW2P/IAZh577RMGvhphmn7Yo+v 6o27eztGT6sJHpNN00aokjZpWePMCMZW7CKvibDUV+mqWMosw8CaiKGwMHURbXjdHhwh nI3ThLRgyFcfOBdr7u1Zzblsc2vGsqQdc8FsowG/191TUqQKGtOK0oMLiHaZy4WfdZh1 S+dnqhmkIOtpNHvdiACrDZG4d+KWTtUwhy8mR3G3stU8KKkTLVwjMZt/6ihvbVEojkGf 1RqvdHnIREjIoLDsOnQvUMgMIIOZAeSfAQyM+HiRNeDgj0+x9v+tSpca8cYrNnmX7Jzq BVFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uaW3zio8OnAbYpY38vKuXoqUF+Orl6fkl80B5tbhoSg=; b=QsF8pLN9kF8G+FY+I9gEL80m2WCyzx/XC8KDKar0qOHvCfTr9wCAQxKvdQl8zGnlyU 8Yc30vSsmSsCGGORvK/DIMKe43IKu/Cmkz6GuVbvg3MAnx291mYINtJIF12lRxp/urpH Hq0rSPBdI6uqZ7+0BmzcvjpO+Epp7In+KJSTgpJ2Y3RVTW3Rb4/uJuIqglHuoB6qy3QC FUJIdVLze6SGjXnyIIZp1MVWXotrKmsmM219yCqRTpmsNhuLJDJLY/IdgcuSyNnLdoi+ n+yQkKHtv37P2dIeMcBhDIKi1IN1rpmsdDCV9LL2VeQzzMObwlR7/KUy3Fg6RiRpRKa+ Bdzw==
X-Gm-Message-State: ANhLgQ2pAFGdAefhcE+yXd45C6YYPJb0MBaXamXuB77OI51QrSm8GWfJ wVGsApEfjFVDFO9Lc5Mq7R4=
X-Google-Smtp-Source: ADFU+vvFdFYyPYgZ2Lw4OzjKHcWQWRCClhjBlwfQnjTsoTriu59b8k2H1ZtsTGqV9hfZsDlzpJnmkw==
X-Received: by 2002:a05:600c:2306:: with SMTP id 6mr10619931wmo.86.1584103280685; Fri, 13 Mar 2020 05:41:20 -0700 (PDT)
Received: from appleton.fritz.box ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id r9sm9752654wma.47.2020.03.13.05.41.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Mar 2020 05:41:16 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Stewart Bryant <stewart.bryant@gmail.com>
In-Reply-To: <CACsn0cmpwPDP6YuU3F1woMQwhVRvBehCr+sCa_JaPFe6aOktWw@mail.gmail.com>
Date: Fri, 13 Mar 2020 12:41:15 +0000
Cc: Stewart Bryant <stewart.bryant@gmail.com>, Lou Berger <lberger@labn.net>, draft-ietf-detnet-mpls.all@ietf.org, DetNet WG <detnet@ietf.org>, secdir <secdir@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <7E8B0875-79F6-4FDB-AD59-29A192C723BC@gmail.com>
References: <158389693039.16158.6977515080330200081@ietfa.amsl.com> <E15E2A3F-5EAA-4B86-B39A-14521AD762D5@gmail.com> <CACsn0cnxjPf3ziSQbjdLmD+1xUJtcDF3kSbz0LiSj=b_safb2A@mail.gmail.com> <137FCA36-3B7C-46EB-B951-3FDC01560069@gmail.com> <CACsn0cmQ0pzGF9MxVWGx-gMUOR6eR7zkKhnMPDx-876xt-H3sw@mail.gmail.com> <170ce6deaf8.277b.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <CACsn0cmpwPDP6YuU3F1woMQwhVRvBehCr+sCa_JaPFe6aOktWw@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/w3rRREIRO7fl3bd6abIGxBPa1ws>
Subject: Re: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-mpls-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Mar 2020 12:41:32 -0000


> On 13 Mar 2020, at 01:35, Watson Ladd <watsonbladd@gmail.com> wrote:
> 
> On Thu, Mar 12, 2020 at 4:07 AM Lou Berger <lberger@labn.net> wrote:
>> 
>> Watson,
>> 
>> Can you provide context here? Can you be explicit on what you see needs to
>> be addressed (beyond what is in this document as well as related rfcs)?
> 
> You have to talk about how the layers interact, and can't just say the
> lower level handles anything without any guide as to what needs to be
> provided by that lower layer.
> 
> I think my concerns about the assumptions this could be fixed by
> saying. "All nodes are trusted and any of them can misbehave in ways
> that affect the network.  

That is a fundamental assumption of all routers, so there really is no need to state it.

As I said earlier, a practical solution to the byzantine routing problem was proposed by Radia about 30 years ago and there is zero interest in it because the trust assumption is fundamentally ingrained in the routing architecture, and so far it has been well founded.


> If the MPLS layer cannot provide sufficient
> determinism, then the DetNet mechanisms won't work".  

That is kind of fundamental to the point where I am also not sure it needs to be stated, and if it does need to be stated then it needs to go up the tree in one of the fundamental documents, not each of the data-plane documents (there are quite a few such documents).

> I agree we
> shoudn't require an entire massive security framework to be quoted
> again here, but there must be some details of this embedding that are
> worth noting, and yet I don't see them called out in the security
> considerations section.

Is this about showing that we have done something to prove that we take security seriously, or is it about giving practical advice to someone deploying the technology. Hopefully the later, in which case I think this is well covered by the DetNet context and the MPLS documents, all of which the reader can be assumed to be familiar with.

> 
> Are there really no specific concerns about the interaction between
> DetNet and MPLS?

There are MPLS service requirements and expectations. However I don’t think there is an interaction per se.

It is as I already said about pseudowires. If the performance of this approach is not good enough, then spend the money and buy a dedicated physical network.

- Stewart


> 
>> 
>> Thank you,
>> Lou
>> 
>> 
>> ----------
>> On March 11, 2020 10:30:27 PM Watson Ladd <watsonbladd@gmail.com> wrote:
>> 
>>> I don't see any reason why RFC 3552's guidelines shoudn't apply to this draft.
>>> 
>>> If there is a MPLS exception I'd like to see the rules that should be applied.
>>> 
>>> As is I don't see any reason why the assumptions can't be explicitly
>>> spelled out, either in the Security Considerations or elsewhere.
>>> 
>>> _______________________________________________
>>> detnet mailing list
>>> detnet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/detnet
>>> 
>> 
>> 
> 
> 
> -- 
> "Man is born free, but everywhere he is in chains".
> --Rousseau.