IETF Logo Mail Archive

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

Lou Berger <lberger@labn.net> Sun, 15 March 2020 21:14 UTC

Return-Path: <lberger@labn.net>
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 9E85B3A1C68 for <secdir@ietfa.amsl.com>; Sun, 15 Mar 2020 14:14:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.362
X-Spam-Level:
X-Spam-Status: No, score=-3.362 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-1.463, 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 (768-bit key) header.d=labn.net
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 gYdbHkpvx7Ul for <secdir@ietfa.amsl.com>; Sun, 15 Mar 2020 14:14:00 -0700 (PDT)
Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) (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 25A053A1C66 for <secdir@ietf.org>; Sun, 15 Mar 2020 14:14:00 -0700 (PDT)
Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id C491E3E0F231A for <secdir@ietf.org>; Sun, 15 Mar 2020 15:13:59 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id Daa7jkjpdVKjoDaa7jJF85; Sun, 15 Mar 2020 15:13:59 -0600
X-Authority-Reason: nr=8
X-Authority-Analysis: v=2.3 cv=dJyIZtRb c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=xqWC_Br6kY4A:10:nop_ipv6 a=IkcTkHD0fZMA:10:nop_charset_1 a=SS2py6AdgQ4A:10:nop_rcvd_month_year a=Vy_oeq2dmq0A:10:endurance_base64_authed_username_1 a=wU2YTnxGAAAA:8 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=giGUBfhqyIHcbX5fTZUA:9 a=QEXdDO2ut3YA:10:nop_charset_2 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=C7x7eFCcOafwhEQpiZAKfu31JVJhRFOiq3fjpT5sWDM=; b=jza5ijtz6QQjkDWupcHVn6GWhb 36ELwcyBaZoI82NhzKeQSiUhWVDh2C5GfXxPA9YxhhdNOs+q6EAZnq2jF0dmxqa/rhgdWRHq0fll9 6pBlylAlKMxZro3ABIcCNC43w;
Received: from [127.0.0.1] (port=55373 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <lberger@labn.net>) id 1jDaa7-001fBu-I1; Sun, 15 Mar 2020 15:13:59 -0600
To: Watson Ladd <watsonbladd@gmail.com>
Cc: Stewart Bryant <stewart.bryant@gmail.com>, draft-ietf-detnet-mpls.all@ietf.org, DetNet WG <detnet@ietf.org>, secdir <secdir@ietf.org>
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>
From: Lou Berger <lberger@labn.net>
Message-ID: <4db5034d-4c48-031b-8604-b9d1ad4d9c68@labn.net>
Date: Sun, 15 Mar 2020 17:13:58 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
MIME-Version: 1.0
In-Reply-To: <CACsn0cmpwPDP6YuU3F1woMQwhVRvBehCr+sCa_JaPFe6aOktWw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 127.0.0.1
X-Source-L: Yes
X-Exim-ID: 1jDaa7-001fBu-I1
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: ([IPv6:::1]) [127.0.0.1]:55373
X-Source-Auth: lberger@labn.net
X-Email-Count: 14
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/8XPk4eRgoBFomdGkI6C2Oce3QXs>
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: Sun, 15 Mar 2020 21:14:02 -0000

Hi Watson,

     I think Stewart's response really covers the main points. DetNet is 
really just MPLS (and IP) with some specific forwarding behaviors and 
queuing.  The only thing I'd add, is I see DetNet in general as a 
specific form of policy based routing. (The general form of which is 
pretty much as old as IP).

Lou

On 3/12/2020 9:35 PM, Watson Ladd 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.  If the MPLS layer cannot provide sufficient
> determinism, then the DetNet mechanisms won't work".  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.
>
> Are there really no specific concerns about the interaction between
> DetNet and MPLS?
>
>> 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
>>>
>>
>

v2.23.0 | Report a Bug | By Email