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

[Lou Berger <[e-mail]>]

Watson, Uri,

would a reference to 
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 <[e-mail] 
> <mailto:[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]
>     <mailto:[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] <mailto:[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]
>     <mailto:[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]
>     <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[e-mail]>
>     >>>>>>>>> https://www.ietf.org/mailman/listinfo/detnet
>     >>>>>>>>>
>     >>>>>
>     >>>>>
>     >>>>
>     >>>> _______________________________________________
>     >>>> secdir mailing list
>     >>>> [e-mail] <mailto:[e-mail]>
>     >>>> https://www.ietf.org/mailman/listinfo/secdir
>     >>>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>     >>
>