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

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.

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> 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> 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> 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> 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> 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> 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> 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
>>>>>>>>> https://www.ietf.org/mailman/listinfo/detnet
>>>>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> secdir mailing list
>>>> secdir@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/secdir
>>>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>> 