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