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

["Black, David" <[e-mail]>]

Hi Lou,

Weighing in late in the discussion ... trying to make a positive contribution ...

>> 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.

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.

Thanks, --David

From: detnet <[e-mail]> On Behalf Of Lou Berger
Sent: Tuesday, March 17, 2020 8:40 AM
To: Uri Blumenthal
Cc: secdir; [e-mail]; Watson Ladd; [e-mail]; Stewart Bryant; <[e-mail]>; DetNet WG
Subject: Re: [Detnet] [secdir] Secdir last call review of draft-ietf-detnet-mpls-05


[EXTERNAL EMAIL]

Hi,
On 3/16/2020 3:56 PM, Uri Blumenthal wrote:
On Mar 16, 2020, at 14:29 , Lou Berger <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]><mailto:[e-mail]> wrote:
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
>>



_______________________________________________

detnet mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/detnet

Uri




_______________________________________________

detnet mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/detnet