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

[Uri Blumenthal <[e-mail]>]

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