Re: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-mpls-05
Uri Blumenthal <uri@mit.edu> Tue, 17 March 2020 15:10 UTC
Return-Path: <uri@mit.edu>
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 273293A03EB; Tue, 17 Mar 2020 08:10:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 vPjUrHWTnJzC; Tue, 17 Mar 2020 08:10:28 -0700 (PDT)
Received: from outgoing-exchange-5.mit.edu (outgoing-exchange-5.mit.edu [18.9.28.59]) (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 6D7B13A0402; Tue, 17 Mar 2020 08:10:22 -0700 (PDT)
Received: from w92exedge3.exchange.mit.edu (W92EXEDGE3.EXCHANGE.MIT.EDU [18.7.73.15]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id 02HF7Pqe014630; Tue, 17 Mar 2020 11:07:38 -0400
Received: from w92expo31.exchange.mit.edu (18.7.74.43) by w92exedge3.exchange.mit.edu (18.7.73.15) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 17 Mar 2020 11:07:07 -0400
Received: from oc11expo31.exchange.mit.edu (18.9.4.104) by w92expo31.exchange.mit.edu (18.7.74.43) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 17 Mar 2020 11:07:16 -0400
Received: from oc11expo31.exchange.mit.edu ([18.9.4.104]) by oc11expo31.exchange.mit.edu ([18.9.4.104]) with mapi id 15.00.1365.000; Tue, 17 Mar 2020 11:07:16 -0400
From: Uri Blumenthal <uri@mit.edu>
To: "Black, David" <David.Black@dell.com>
CC: Lou Berger <lberger@labn.net>, 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>
Thread-Topic: [Detnet] [secdir] Secdir last call review of draft-ietf-detnet-mpls-05
Thread-Index: AQHV+8DZP29H4cjJ90qNnu6vrG/xK6hL5XQAgAEYY4CAAB2xgIAAC3EA
Date: Tue, 17 Mar 2020 15:07:16 +0000
Message-ID: <DE75BDF7-0A5D-45E2-A0C0-F7E18BF466F8@mit.edu>
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> <c0fb4878-4631-ea83-cdcf-3ccc5fcf7c4a@labn.net> <MN2PR19MB404529C87F0765CDA8D202D583F60@MN2PR19MB4045.namprd19.prod.outlook.com>
In-Reply-To: <MN2PR19MB404529C87F0765CDA8D202D583F60@MN2PR19MB4045.namprd19.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [24.62.106.45]
Content-Type: multipart/signed; boundary="Apple-Mail=_91212AB3-239E-4D11-8BB2-805D4CFF7CBC"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/LN3T2afzuxgw-fVXE8PTwcn7TCk>
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 15:10:48 -0000
On Mar 17, 2020, at 10:26 , Black, David <David.Black@dell.com> wrote: > > Hi Lou, > > Weighing in late in the discussion ... trying to make a positive contribution ... Thank you! And please see below. > >> 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. > > Two important differences between DetNet and MPLS are that DetNet uses a fraction of the resources of the MPLS data plane and DetNet has rather tight timing requirements. By comparison to ordinary MPLS, that combination reduces the effort requires to overwhelm the DetNet forwarding resources and increases the ability to do serious damage (to DetNet service, not MPLS overall) at relatively low levels of overload. This is the kind of analysis/guidance that belongs to the Draft! > My initial hunch is that Stewart is correct that MPLS’s existing resistance to denial of service attacks suffices for DetNet without additional measures, but a brief explanation of why would be a good thing to add to this draft. I do not know if that hunch is correct, but it should be added regardless. > [EXTERNAL EMAIL] > > Hi, > > 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. > Thanks! > 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? > Not “repeat”, i.e., not copy text from what the other RFCs says). Refer to - i.e., “for general MPLS security consideration see section X of RFC Y." > 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. > That’s exactly what I’m suggesting. > 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. > My main point is that you tell the reader why you refer him to a given section of a given RFC, and what he should expect to find there. E.g., “see section X of RFC Y for details of the generic MPLS Threat Model”. > 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. > I don’t know how many sentences it should take. All I want is that it is clear and useful (and if it also manages to stay brief - that’s an extra bonus ;). ================= > > On Mar 16, 2020, at 10:22, Lou Berger <lberger@labn.net> <mailto:lberger@labn.net> wrote: > Watson, Uri, > would a reference to https://tools.ietf.org/html/draft-ietf-detnet-security-08#section-7 <https://tools.ietf.org/html/draft-ietf-detnet-security-08#section-7> help? 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/ <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 <https://www.ietf.org/mailman/listinfo/detnet> > >>>>>>>>> > >>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> secdir mailing list > >>>> secdir@ietf.org <mailto:secdir@ietf.org> > >>>> https://www.ietf.org/mailman/listinfo/secdir <https://www.ietf.org/mailman/listinfo/secdir> > >>>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview <http://tools.ietf.org/area/sec/trac/wiki/SecDirReview> > >> > > > > _______________________________________________ > detnet mailing list > detnet@ietf.org <mailto:detnet@ietf.org> > https://www.ietf.org/mailman/listinfo/detnet <https://www.ietf.org/mailman/listinfo/detnet> > > Uri > > > > _______________________________________________ > detnet mailing list > detnet@ietf.org <mailto:detnet@ietf.org> > https://www.ietf.org/mailman/listinfo/detnet <https://www.ietf.org/mailman/listinfo/detnet> Uri
- [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