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

[Watson Ladd <[e-mail]>]

On Mon, Mar 16, 2020, 7:01 AM Stewart Bryant <[e-mail]>
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 <[e-mail]> 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 <[e-mail]>
> 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 <[e-mail]> 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 <[e-mail]> wrote:
> >>>>
> >>>> 
> >>>>> On 3/15/2020 5:22 PM, Watson Ladd wrote:
> >>>>>> On Sun, Mar 15, 2020 at 2:14 PM Lou Berger <[e-mail]>
> 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 <[e-mail]>
> 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 <[e-mail]>
> 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
> >>>>>>>>> [e-mail]
> >>>>>>>>> https://www.ietf.org/mailman/listinfo/detnet
> >>>>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> secdir mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/secdir
> >>>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
> >>
>
>