Re: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-mpls-05
Lou Berger <lberger@labn.net> Tue, 17 March 2020 12:40 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 029E63A1E46 for <secdir@ietfa.amsl.com>; Tue, 17 Mar 2020 05:40:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.361
X-Spam-Level:
X-Spam-Status: No, score=-3.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 Wk5a3QgZZaz9 for <secdir@ietfa.amsl.com>; Tue, 17 Mar 2020 05:39:59 -0700 (PDT)
Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) (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 88A133A1E42 for <secdir@ietf.org>; Tue, 17 Mar 2020 05:39:59 -0700 (PDT)
Received: from cmgw12.unifiedlayer.com (unknown [10.9.0.12]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id 3EAFE1E09C6 for <secdir@ietf.org>; Tue, 17 Mar 2020 06:39:59 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id EBVnjTguhN8ArEBVnjZAyi; Tue, 17 Mar 2020 06:39:59 -0600
X-Authority-Reason: nr=8
X-Authority-Analysis: v=2.3 cv=Ye2TGTZf 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=SS2py6AdgQ4A:10:nop_rcvd_month_year a=Vy_oeq2dmq0A:10:endurance_base64_authed_username_1 a=r77TgQKjGQsHNAKrUKIA:9 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:8 a=7ji3lbUPzGw7hHbqHAMA:9 a=tGLlV30DdcmNEdlS:21 a=I92aSuSJl1YgzEi_:21 a=QEXdDO2ut3YA:10:nop_charset_2 a=divCYUUttnDrMqcDkuEA:9 a=GzI9915wpOS0RxUy:21 a=2UqIaCplluZ15t8b:21 a=NxWw3CgrLwRhhbKO:21 a=_W_S_7VecoQA:10:nop_html 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-Type:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Sender:Reply-To:Content-Transfer-Encoding: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=Hw/U8R5F50QfBrMGuYIdzaKPCEsfKvpl5xREm7byi+g=; b=0/PiDhZkkQcB+sLwne3vzHrkZ8 0dY9nRon2bvyAwx7r/7cQq/1RKVD5FSdHwcw13uoKG2KxYersG8lSDkT8aTn/GYzcitCZzpi79hqN R/VCnioNEuSj0QuqtY1rDiINe;
Received: from [127.0.0.1] (port=56469 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 1jEBVm-003psZ-RF; Tue, 17 Mar 2020 06:39:59 -0600
To: Uri Blumenthal <uri@mit.edu>
Cc: secdir <secdir@ietf.org>, "rtg-ads@ietf.org" <rtg-ads@ietf.org>, Watson Ladd <watsonbladd@gmail.com>, "draft-ietf-detnet-mpls.all@ietf.org" <draft-ietf-detnet-mpls.all@ietf.org>, Stewart Bryant <stewart.bryant@gmail.com>, "<sec-ads@ietf.org>" <sec-ads@ietf.org>, DetNet WG <detnet@ietf.org>
References: <a8dfd766-7770-0baa-7ec7-bd844f769716@labn.net> <73942657-B55A-431F-AB55-444C3C587AE1@mit.edu> <d6b84f92-cf52-dfcd-3148-49cd260c2531@labn.net> <CE2A9856-0663-4576-B248-0D5FD1189815@mit.edu>
From: Lou Berger <lberger@labn.net>
Message-ID: <c0fb4878-4631-ea83-cdcf-3ccc5fcf7c4a@labn.net>
Date: Tue, 17 Mar 2020 08:39:49 -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: <CE2A9856-0663-4576-B248-0D5FD1189815@mit.edu>
Content-Type: multipart/alternative; boundary="------------B717831FBE174360A43715A0"
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: 1jEBVm-003psZ-RF
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: ([IPv6:::1]) [127.0.0.1]:56469
X-Source-Auth: lberger@labn.net
X-Email-Count: 11
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/abxtIGo2LSao9YqEMEQCbhy2DRc>
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: Tue, 17 Mar 2020 12:40:19 -0000
Hi, On 3/16/2020 3:56 PM, Uri Blumenthal wrote: > On Mar 16, 2020, at 14:29 , Lou Berger <lberger@labn.net > <mailto:lberger@labn.net>> wrote: >> >>> If indeed, as Stewart says, detnet does not add any security >>> considerations to those already described in the MPLS documents - >>> the draft should state so explicitly. Though I personally find it >>> hard to believe. >>> >>> What is an "obvious common sense" for you and Stewart, may not be so >>> obvious to other readers. >>> >>> As a note to others, it is expected that RFC authors do perform a >>> comprehensive security analysis, and document their findings in the >>> Security Considerations section. I thought that was obvious. >> >> I think either we agree or that the words "a comprehensive security >> analysis" is the source of a disconnect. My view is that the such >> analysis is a *delta* analysis for previous IETF work/RFCs. >> > Yes, it should be a *comprehensive* analysis of the possible security > impacts that the *changes* introduce. > > I.e., in general, when you add some capability, you describe > > * What your security assumptions are - what kind of access you > assume your adversary can or cannot have. > * How your added capability impacts/changes the existing security > posture (and what you assume that posture is/was) - new attack > surface(s), etc. > * What of the newly-introduced stuff may require protection, and > what kind of protection (should stay secret, no problem if > disclosed but a big deal if modified, etc). > * How you recommend protecting the above. > > > The reader should learn what new requires protection, ideally - why, > and probably, how. But (IMHO) saying “just use TLS” is not nearly good > enough - it doesn’t tell me what I’m trying to protect, and why (what > harm could come if left unprotected). explaining why a security mechanism is needed seems reasonable to me. > >> Certainly authors should reference the prior work/RFCs that are >> needed to understand the analysis, but they need not (even should >> not) rehash all the material form this existing work -- only what has >> changed. >> > Correct. BTW, by “reference” I mean stating what concepts from those > RFCs apply. > so you want to repeat all the concepts from prior work/rfcs? This makes little sense to me as it means the likely introduction of differences and errors from the original work. Pointers to the relevant work/sections seem right to me as the implementations are going to have to support the prior work in any case. >> Does this match your expectation or do you expect something >> different? If so, what do you expect? >> > I think it does, with the above caveat ;). > > We may nit-argue about what “rehashing existing work” means. > > Referring the reader to go to RFC XXXX for details on specific > concerns/issues/etc is fine. We wouldn’t be able to operate if every > RFC had to be self-contained, and included _everything_ related. very happy we agree on this key point. > But you should tell the reader why you’re referring him to an external > document, and what in particular he’s supposed to find/look for there. Sure, but it sounds like we may differ on detail level needed in the reference. > > To just say “this is MPLS-based, so to figure it’s security risks go > read MPLS RFCs” IMHO is not good enough. Mainly because I don’t agree > that no new exposures are introduced. I don't think this is a valid solution to your concern. > If the authors, however, believe this - their analysis (put in the > Security Considerations section) should show _why_ there are no new > exposures. It doesn’t have to be lengthy - but it does have to make > sense. This is a good solution -- in other words, I do think it's fair to add something on this to the section. I suspect it will be at most two sentences. Lou > > >>>> On Mar 16, 2020, at 10:22, Lou Berger<lberger@labn.net>wrote: >>>> >>>> Watson, Uri, >>>> >>>> would a reference >>>> tohttps://tools.ietf.org/html/draft-ietf-detnet-security-08#section-7help? >>>> note that Detnet operates/extends the IP and MPLS layers. It is >>>> not a service that rides on general IP or separate from the MPLS >>>> layers. >>>> >>>> Lou >>>> >>>> On 3/16/2020 10:18 AM, Watson Ladd wrote: >>>>> >>>>> >>>>> On Mon, Mar 16, 2020, 7:01 AM Stewart Bryant >>>>> <stewart.bryant@gmail.com <mailto:stewart.bryant@gmail.com>> wrote: >>>>> >>>>> The requirement is NOT for a draft to provide the security >>>>> analysis of all of all of the technologies that it calls up. >>>>> It is, I believe, to describe the deltas that apply to the new >>>>> idea. Anything else and the text would be a security analysis >>>>> with a short technology preamble. >>>>> >>>>> We are describing a technology that is overlaid on MPLS. We >>>>> should not need to describe the security model of MPLS, but >>>>> instead confine our remarks to issues that specifically apply >>>>> to the additional technology we are describing. >>>>> >>>>> >>>>> RFC 3552 requires that in a case such as this you explicitly >>>>> describe what the lower layer is providing to the top layer. RFC >>>>> 3552 section 5 also demands that attacks be enumerated and those >>>>> out of scope be called out. >>>>> >>>>> E.g "use TLS" isn't good enough and imho neither is "use MPLS". >>>>> >>>>> Again, the sentences in the security considerations as it stands >>>>> are about MPLS and Detnet, and they don't seem to come together. >>>>> Are there really no security considerations when putting the two >>>>> together? Every MPLS network will just work with Detnet on top, no >>>>> matter how rushed the deploy is? >>>>> >>>>> >>>>> Early in the document we call up RFC3031 and RFC3032, the >>>>> fundamental MPLS RFCs. They are in section 3.1 the first part >>>>> of the serious technical discussion. In my view these >>>>> establish a baseline of understand that the reader is expected >>>>> to have. >>>>> >>>>> It is important to realise, as I have said before, that >>>>> without understanding that baseline the rest of the document >>>>> is meaningless. >>>>> >>>>> Regards >>>>> >>>>> Stewart >>>>> >>>>> BTW >>>>> >>>>> It might be as well if you refrained from illustrating the >>>>> lack of professionalism that the security area applies to its >>>>> reviews by continuing with the flippancy. There is a serious >>>>> point that needs to be debated here about what assumptions are >>>>> a given and what assumptions need to be spelled out when >>>>> modifying or layering a technology. >>>>> >>>>> >>>>> > On 16 Mar 2020, at 12:22, Uri Blumenthal <uri@mit.edu >>>>> <mailto:uri@mit.edu>> wrote: >>>>> > >>>>> > IETF position (add fat as I remember) regarding RFCs has >>>>> been that RFCs should provide with everything information for >>>>> a reasonable developer to implement correctly and securely the >>>>> standard they define, and provide enough information for the >>>>> person who will deploy a compliant implementation to do that >>>>> correctly and securely. >>>>> > >>>>> > One purpose of Security Review is to ensure that a person >>>>> doesn't have to be an expert in the field to deal with the >>>>> proposed document. >>>>> > >>>>> > In a flippant way, if using your stuff is requires special >>>>> classes - perhaps it belongs to a book rather than an RFC. >>>>> > >>>>> > In a non-flippant way - what's the problem in mentioning the >>>>> issues and providing the appropriate references? A "normal" >>>>> RFC cannot be self-contained, but it's unreasonable to epect a >>>>> reader to just "know" where all the omitted things are described. >>>>> > >>>>> >> On Mar 16, 2020, at 06:33, Stewart Bryant >>>>> <stewart.bryant@gmail.com <mailto:stewart.bryant@gmail.com>> >>>>> wrote: >>>>> >> >>>>> >> Uri, >>>>> >> >>>>> >> That is a ridiculous position, and you flippancy >>>>> demonstrates that. >>>>> >> >>>>> >> This technology fundamentally rests on MPLS and it is >>>>> reasonable that the reader of this RFC will understand MPLS >>>>> and the security model it uses before they implement or deploy >>>>> it. Indeed I cannot think of any implementor or operator that >>>>> would not already have that knowledge before taking on the >>>>> task of building or running DN over MPLS. >>>>> >> >>>>> >> If SecDir reviews are to retain any credibility as expert >>>>> reviews as opposed to Genart random reader reviews they have >>>>> to be carried out with shared knowledge of both the security >>>>> area and the draft’s host area. >>>>> >> >>>>> >> I have been thinking for some time that there needs to be a >>>>> fundamental review of the security review process. >>>>> >> >>>>> >> Stewart >>>>> >> >>>>> >>> On 15 Mar 2020, at 22:44, Uri Blumenthal <uri@mit.edu >>>>> <mailto:uri@mit.edu>> wrote: >>>>> >>> >>>>> >>> I say yes - unless you expect a person who wants just one >>>>> RFC to have to read every cr^h^h stuff that came out of the >>>>> routing area. >>>>> >>> >>>>> >>> "Just do it" >>>>> >>> >>>>> >>> >>>>> >>>>> On Mar 15, 2020, at 17:39, Lou Berger <lberger@labn.net >>>>> <mailto:lberger@labn.net>> wrote: >>>>> >>>> >>>>> >>>> >>>>> >>>>> On 3/15/2020 5:22 PM, Watson Ladd wrote: >>>>> >>>>>> On Sun, Mar 15, 2020 at 2:14 PM Lou Berger >>>>> <lberger@labn.net <mailto:lberger@labn.net>> wrote: >>>>> >>>>>> 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). >>>>> >>>>> Then Stewart can put those points in the security >>>>> considerations >>>>> >>>>> section. What's the disadvantage of doing so? >>>>> >>>> >>>>> >>>> At one level, it would be easiest for the authors to just >>>>> put these in. On the other hand, this would mean that every >>>>> RFC produced in the routing area will acquire similar notes, >>>>> e.g., routing protocols are currently built with a chain of >>>>> trust model. Is this what the sec-dir really is asking the >>>>> routing area to do? >>>>> >>>> >>>>> >>>> ADs, >>>>> >>>> >>>>> >>>> any opinion on this? (for context, Stewart's response >>>>> can be found >>>>> at:https://mailarchive.ietf.org/arch/msg/detnet/-epL5Fb6bFIUltMrjH53C2316ZA/) >>>>> >>>> >>>>> >>>> Thanks, >>>>> >>>> >>>>> >>>> Lou >>>>> >>>> >>>>> >>>>>> 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 <mailto: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 <mailto: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 <mailto:detnet@ietf.org> >>>>> >>>>>>>>>https://www.ietf.org/mailman/listinfo/detnet >>>>> >>>>>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>>> >>>> _______________________________________________ >>>>> >>>> secdir mailing list >>>>> >>>>secdir@ietf.org <mailto:secdir@ietf.org> >>>>> >>>>https://www.ietf.org/mailman/listinfo/secdir >>>>> >>>> wiki:http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >>>>> >> >>>>> >>> >>> _______________________________________________ >>> detnet mailing list >>> detnet@ietf.org >>> https://www.ietf.org/mailman/listinfo/detnet > > Uri > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet
- [secdir] Secdir last call review of draft-ietf-de… Watson Ladd via Datatracker
- Re: [secdir] Secdir last call review of draft-iet… Stewart Bryant
- Re: [secdir] Secdir last call review of draft-iet… Watson Ladd
- Re: [secdir] Secdir last call review of draft-iet… Stewart Bryant
- Re: [secdir] Secdir last call review of draft-iet… Watson Ladd
- Re: [secdir] Secdir last call review of draft-iet… Stewart Bryant
- Re: [secdir] [Detnet] Secdir last call review of … Lou Berger
- Re: [secdir] [Detnet] Secdir last call review of … Watson Ladd
- Re: [secdir] [Detnet] Secdir last call review of … Stewart Bryant
- Re: [secdir] [Detnet] Secdir last call review of … Uri Blumenthal
- Re: [secdir] [Detnet] Secdir last call review of … Lou Berger
- Re: [secdir] [Detnet] Secdir last call review of … Watson Ladd
- Re: [secdir] [Detnet] Secdir last call review of … Lou Berger
- Re: [secdir] [Detnet] Secdir last call review of … Uri Blumenthal
- Re: [secdir] [Detnet] Secdir last call review of … Stewart Bryant
- Re: [secdir] [Detnet] Secdir last call review of … Lou Berger
- Re: [secdir] [Detnet] Secdir last call review of … Uri Blumenthal
- Re: [secdir] [Detnet] Secdir last call review of … Stewart Bryant
- Re: [secdir] [Detnet] Secdir last call review of … Watson Ladd
- Re: [secdir] [Detnet] Secdir last call review of … Lou Berger
- Re: [secdir] [Detnet] Secdir last call review of … Stewart Bryant
- Re: [secdir] [Detnet] Secdir last call review of … Uri Blumenthal
- Re: [secdir] [Detnet] Secdir last call review of … Lou Berger
- Re: [secdir] [Detnet] Secdir last call review of … Uri Blumenthal
- Re: [secdir] [Detnet] Secdir last call review of … Lou Berger
- Re: [secdir] [Detnet] Secdir last call review of … Black, David
- Re: [secdir] [Detnet] Secdir last call review of … Uri Blumenthal