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

From: Watson Ladd via Datatracker <[email-masked]>
Date: Tue, 10 Mar 2020 20:22:10 -0700

Reviewer: Watson Ladd
Review result: Not Ready

This is the secdir review of draft-ietf-detnet-mpls-05. Authors should treat
these as any other Last Call comments.

Apologies for the delays in completing this review.

I am concerned that this document (and the related work) introduces some
substantial differences from existing Internet architecture, and that
inadequate attention is paid to the consequent security implications. Pointing
to a separate, in progress draft I don't think is an adequate security
consideration section. That's particularly true when we're discussing the
network providing functions like duplicate packet dropping that are potentially
quite expensive and which attackers may exploit to consume large amounts of
resources. Saying that one can mitigate DoS on the edge of a DetNet domain
isn't enough: how do you mitigate the DoS, or detect it? What if the edge is
the problem? Are there resources that can be consumed in the center the edge
doesn't know about?

With confidentiality this draft mentions the possibility of link to link
protection, ignoring the possibility of malicious nodes, and doesn't describe
the way one actually uses that integration. It's not clear to me what the
security goals are, and saying a mechanism may be used, without indicating how
doesn't make it remediation for a security problem. I can think of a few ways
to abuse the one-packet only service to rewrite flows with great ease.

The Internet is composed of smart nodes at the edge and dumb forwarders in the
middle. DetNet is a very different design, with significant complexity and
state in the network, and guarantees not maintained by end nodes. This means
that a lot that has been learned about Internet security doesn't apply, which
raises a whole host of questions: what threat model is applied? Is it
realistic? Are the properties such as bounded latency and low jitter maintained
even in the face of adversarial behavior? While this may be appropriately
handled at greater length in a separated draft, a tighter link to the
mechanisms defined in this draft would be useful.

It's very likely these have been discussed in the detnet wg at length as
evidenced by the security considerations, but I'd like to see the MPLS draft
reflect some of that conversation more directly.

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 11 Mar 2020 15:29:55 +0000

> On 11 Mar 2020, at 03:22, Watson Ladd via Datatracker <[email-masked]> wrote:
> 
> Reviewer: Watson Ladd
> Review result: Not Ready
> 
> inadequate attention is paid to the consequent security implications.

I disagree with the proposition that this is a substantial change to the existing Internet architecture.

This MPLS DetNet design is, if anything, a development of pseudowires, a widely deployed technology that for many years was the standard method of carrying IP from the customer premise to the ISP. It is a close cousin to MPLS VPN which has been a stable of provider network deployments.

MPLS is designed to be run in a tightly controlled environment. This is something that all competent MPLS operators do as a matter of course, and I do not see this being much of an additional issue. The special  problem here is the need to police ingress traffic for dynamic issues. That is quite a significant body of work, and is being tackled in a separate document.

We can add a reference to general MPLS security, and to the security of pseudowires running over MPLS, but these are well known by anyone operating an MPLS network, and the clutter will distract the reader from the unique issues that apply to this design.

> Pointing
> consideration section.

Adding all the text from that draft would imbalance this draft, and referring to it is normally a better idea, particularly as the same text applies to a number of the DetNet drafts.

> That's particularly true when we're discussing the
> resources.

The expensive process of duplicate dropping is a cost of that aspect of the service. Obviously if your forwarder is incapable of offering that service you would not offer the service. Now we know that a lot of forwarder designs cannot do this, and to do so would require a rebalance of processing between the ingress and the egress interface, but that should not stop us designing such a system. It is simply a mark of progress that we upgrade the forwarding system to add new features.

Now if you are worried about an attacker injecting such packets, I would ask you to remember that no competent MPLS operator will allow any MPLS packets in their network that they have not put there themselves, or have accepted from a highly trusted peer. There is over 20 years of experience in securing MPLS networks. As far as I am aware there has never been an MPLS injection attack brought to the attention of the MPLS WG or the PALS (ne PWE3) WGs. I am not loosing any sleep over this type of attack. If the attack was a likely prospect we would be seeing it as an issue with VPNs and PWs and we see no such issue.

> Saying that one can mitigate DoS on the edge of a DetNet domain
> isn't enough: how do you mitigate the DoS, or detect it?

Again this is standard MPLS. Remember nothing gets into the network other than through a PE, and it is common for a PE to do rate detection and ensure that the attached external device does not exceed the agreed rate.  

> What if the edge is

This is no different from the MPLS traffic engineered network case with reserved bandwidth. This is widely understood in MPLS network designs. If you are concerned about faulty equipment, there are many worse things that could happen.

> the way one actually uses that integration.

If you have a malicious node, then all bets are off anyway. There are many bad things a malicious node can do, of which this is the least interesting. We have for example known how to protect the routing system against malicious nodes since Radia wrote her thesis at MIT, but the industry does not yet have an interest in moving there. 

Our assumption is that the more likely point of attack is the link rather than the node (because it is much easier and we have an existence proof of that attack being common). It is well known to operators how to encrypt the link traffic and thus we do not add much value to this document by describing it.

> It's not clear to me what the
> doesn't make it remediation for a security problem.

In this specific case it is the prevention of snooping of traffic not secured by the application (many applications are legacy) such as the snooping that the NSA became famous for. 

> I can think of a few ways

Please describe them in the contest of operation of this service and we will assess the eligibility and vulnerability. 

> middle.

This is **NOT** running over the general Internet. It is of necessity a well controlled network. This is an MPLS design and MPLS only operates in well controlled provider networks.

> DetNet is a very different design, with significant complexity and
> state in the network, and guarantees not maintained by end nodes.

Are you familiar with multi-segment pseudowires? This design is basically an MS-PW with the addition of the a very special type of multicast. In both cases there is a controlled amount of additional state. The state that we add here is well controlled.

As to guarantees, I would point you to the fundamental design philosophy of PWs, which was that we would operate as best we could, and if that was not good enough buy a (much more expensive) real wire. We designed some types of PW that were quite sensitive to loss and no one complained. It is the same here. If you need a greater guarantee than you get with this approach, spend more money and use a private physical network. However that discussion belongs  is in the scope of DetNet per se and this design inherits that scope. It should not be part of this text.

> This means
> raises a whole host of questions: what threat model is applied?

We are documenting that in other work, hence the references. However of all of the network types, MPLS is intrinsically one of the most secure.

> Is it
> even in the face of adversarial behavior?

That is why we have to police the behaviour at the edge, something that the MPLS community has a lot of existing experience with.

> While this may be appropriately

If you look at the work you will see that this would imbalance the draft and then we would have to duplicate it in the other data-plane drafts. Much better to discuss that in a single place and just call out the data-plane specific security issues in the data-plane drafts. That way the critical issues are documented in a way that the reader is less likely to lose in a sea of familiar text.

> reflect some of that conversation more directly.

I would ask you to reflect on the discussion above. If you need any help understanding MPLS and Pseudowires (which are fundamentally assumed knowledge that anyone deploying this technology would have) I can provide you with some pointers to background reading. 

Best regards

Stewart

---

From: Watson Ladd <[email-masked]>
Date: Wed, 11 Mar 2020 10:18:59 -0700

> We can add a reference to general MPLS security, and to the security of pseudowires running over MPLS, but these are well known by anyone operating an MPLS network, and the clutter will distract th…

Then this assumption that all the nodes are trusted needs to be
explicitly stated in the securities consideration section.

> Adding all the text from that draft would imbalance this draft, and referring to it is normally a better idea, particularly as the same text applies to a number of the DetNet drafts.

I don't think you need to add all the text: i think you need to
connect the specific mechanisms in this draft to those considerations.
As it is much of the security considerations section here talks about
DetNet and not MPLS or MPLS-DetNet: it makes it very hard to figure
out what the issues are, especially for someone unfamiliar with it.
It's not much text to add, but it's important text.

> The expensive process of duplicate dropping is a cost of that aspect of the service. Obviously if your forwarder is incapable of offering that service you would not offer the service. Now we know t…

There is an old prank where one introduces 3 pigs numbered 1, 2, and 4
into a place where pigs are not normally found. The deduplication
capacity isn't unlimited, and care should be taken that the state
can't grow unboundedly.

> This is no different from the MPLS traffic engineered network case with reserved bandwidth. This is widely understood in MPLS network designs. If you are concerned about faulty equipment, there are…

It's very different: bandwidth is frequently exceeded over very short
periods due to microbursts, with no real harmful effects, and it's a
resource one can pretty nicely model as a flow problem. Latency or
deduplication memory is a bit trickier: I suppose if everything is
reserved it's ok, but whatever sets up the reservations and the
routing should know about all of the resources involved. I don't think
these are the same problem as bandwidth reservations.

> In this specific case it is the prevention of snooping of traffic not secured by the application (many applications are legacy) such as the snooping that the NSA became famous for.

RFC 3552 says that this sort of statement is insufficient, and
recommends instead describing what the lower layer should do and the
properties of the combined system.

> Please describe them in the contest of operation of this service and we will assess the eligibility and vulnerability.

Insert the packet with the same number, win the race.

> As to guarantees, I would point you to the fundamental design philosophy of PWs, which was that we would operate as best we could, and if that was not good enough buy a (much more expensive) real w…

I think that's a considerable change from current MPLS!  Operators
should be aware that all of a sudden they have to worry about latency.
Does current MPLS hardware offer the guarantees required? I feel this
needs to be a bit louder: you can't just throw on DetNet on top of
MPLS without problems.

> We are documenting that in other work, hence the references. However of all of the network types, MPLS is intrinsically one of the most secure.

I looked and found it quite hard to understand exactly what I should
be looking for in this draft. That's in no small part due to my own
unfamiliarity, and writing for nonexperts is hard.

> That is why we have to police the behaviour at the edge, something that the MPLS community has a lot of existing experience with.

Would you necessarily notice if a low bandwidth flow was causing a
priority inversion at some node and thus violating latency promises on
another low bandwidth flow?
> If you look at the work you will see that this would imbalance the draft and then we would have to duplicate it in the other data-plane drafts. Much better to discuss that in a single place and jus…

Right, but then this draft should focus on the specific MPLS-DetNet
security issues and explicitly link particular mechanisms to the
problems. As it is the securities considerations section of this draft
feels pretty generic, which is not good. Deviation from RFC3552 should
be very explicitly noted.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 11 Mar 2020 18:59:03 +0000

As requested I just sent you a reading list and short tutorial on PWs and MPLS.

It is our assumption that before anyone gets to DetNet over MPLS that already became an expert on MPLS, because if they had not they would be dealing with a huge set of problems. It is therefore unreasonable to clutter the document with basis MPLS material since this would only distract from the crucial issues that are associated with DetNet.

> On 11 Mar 2020, at 17:18, Watson Ladd <[email-masked]> wrote:
> 
> On Wed, Mar 11, 2020 at 8:29 AM Stewart Bryant <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> 

That is an MPLS given. I am not sure that it needs to be stated since it is only in IETF security reviews that we meet the case of someone wanting to do a detailed review of DetNet over MPLS without first understanding MPLS and the shared assumptions.

> It's not much text to add, but it's important text.

Yes, but normally the text would not be read by someone that was not an MPLS expert.

We could add at the beginning something of the form:

"This technology must only  be deployed in a well managed MPLS network operated by those familiar with MPLS."

However that seems a bit obvious.

> capacity isn't unlimited, and care should be taken that the state

But how do the pigs get inside the pen when ALL the outer gates are guarded by a robot that kills all pigs regardless of their number?

> these are the same problem as bandwidth reservations.

We know its harder, but that is an operational problem not a security problem.

The input policer would need to understand the constraints it was policing which would not be simple bandwidth over the long term but would include shorter term bandwidth constraints. Indeed the input to the network would need to smooth the flow over time. However that is really a study in advanced QoS rather than a security issue.

> properties of the combined system.

Please provide some recommended text or a pointed to the text in an RFC that addresses this problem.

> Insert the packet with the same number, win the race.

See earlier. The packet was killed on sight by the ingress PE. Remember this is MPLS not IP.

> should be aware that all of a sudden they have to worry about latency.

Surely if they are deploying DetNet they know that. They are deploying a deterministic service.

> needs to be a bit louder: you can't just throw on DetNet on top of

Yes, as I said if you are being asked to deploy a deterministic service, and presumably underhand what that means from the DetNet architecture you would know that and not need to read it in the security section.

> unfamiliarity, and writing for nonexperts is hard.

But it was not written for non-experts!

There is so much MPLS you need to know to stand up the network I find it hard to see why we need to provide a tutorial in this document.

Maybe SecDir needs some MPLS expertise on staff to review MPLS texts?

> another low bandwidth flow?

What do you mean by a priority inversion in the context of MPLS?

Remember that DetNet (see the architecture) only promises a latency ceiling, not the minimum transit latency. You therefore have to assume in working out the SLA that a low bandwidth packet just get to the output pipeline stage before the deterministic packet. The most you will be delayed is by the number of bytes in the pipeline, but that is a feature of the approach. It is not a security issue.

> be very explicitly noted.

We do point to other drafts. I am sure that RFC3552 says nothing about a draft being freestanding.

In any case RFC3552 just deals with classic attacks on best effort networks and so is not a good model for a security analysis of a dynamic system overlayed on a well established technology well known for its intrinsic security properties.

We have references to other specialist material we are in the process of publishing, so I think that all that is required is a sentence saying that this technology must be deployed over a well managed MPLS network.

Best regards

Stewart.

---

From: Watson Ladd <[email-masked]>
Date: Wed, 11 Mar 2020 19:29:31 -0700

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.

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 12 Mar 2020 11:04:52 +0000

> On 12 Mar 2020, at 02:29, Watson Ladd <[email-masked]> wrote:
> 

No you mis the point.

The underlay (MPLS) is resilient to the level required by RFC3552 so that really is out of scope because we are not describing MPLS itself but what in MPLS terminology is an application running over MPLS.

As far as I can see the RFC3552 view of security was the necessary security to be applied to a best effort service.

The types of attack that very few people have experience of is dynamic attacks. The only people that have experience of them, and I am sure you know, are people doing time transfer. Now I think that this is largely an unsolved problem, particularly with fine grained timing. I have worked on systems where this has accidentally occurred (two 1588 streams with different clocks beating), but this sets a floor on the lower deterministic delay bound and as I noted earlier DN is not looking for min delay, just a delay floor.

However that is not really a security problem, it is an operational performance problem.

> spelled out, either in the Security Considerations or elsewhere.

We can certainly note that we assume that DN over MPLS will be run over a well managed MPLS network if that helps.

If you have explicit suggestions for text we will look at them.

- Stewart

---

From: Lou Berger <[email-masked]>
Date: Thu, 12 Mar 2020 07:07:55 -0400

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)?

Thank you,
Lou

----------
On March 11, 2020 10:30:27 PM Watson Ladd <[email-masked]> wrote:

> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet
>

---

From: Watson Ladd <[email-masked]>
Date: Thu, 12 Mar 2020 18:35:53 -0700

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

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 13 Mar 2020 12:41:15 +0000

> On 13 Mar 2020, at 01:35, Watson Ladd <[email-masked]> wrote:
> 
> that affect the network.  

That is a fundamental assumption of all routers, so there really is no need to state it.

As I said earlier, a practical solution to the byzantine routing problem was proposed by Radia about 30 years ago and there is zero interest in it because the trust assumption is fundamentally ingrained in the routing architecture, and so far it has been well founded.

> If the MPLS layer cannot provide sufficient
> determinism, then the DetNet mechanisms won't work".  

That is kind of fundamental to the point where I am also not sure it needs to be stated, and if it does need to be stated then it needs to go up the tree in one of the fundamental documents, not each of the data-plane documents (there are quite a few such documents).

> I agree we

Is this about showing that we have done something to prove that we take security seriously, or is it about giving practical advice to someone deploying the technology. Hopefully the later, in which case I think this is well covered by the DetNet context and the MPLS documents, all of which the reader can be assumed to be familiar with.

> Are there really no specific concerns about the interaction between

There are MPLS service requirements and expectations. However I don’t think there is an interaction per se.

It is as I already said about pseudowires. If the performance of this approach is not good enough, then spend the money and buy a dedicated physical network.

- Stewart

---

From: Uri Blumenthal <[email-masked]>
Date: Fri, 13 Mar 2020 17:00:53 +0000

I concur with Watson. Please state *explicitly* the things that he suggested.

> On Mar 13, 2020, at 08:41, Stewart Bryant <[email-masked]> wrote:
> 
> 
> 
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

---

From: Lou Berger <[email-masked]>
Date: Sun, 15 Mar 2020 17:13:58 -0400

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

Lou

---

From: Watson Ladd <[email-masked]>
Date: Sun, 15 Mar 2020 14:22:16 -0700

> pretty much as old as IP).

Then Stewart can put those points in the security considerations
section. What's the disadvantage of doing so?

---

From: Lou Berger <[email-masked]>
Date: Sun, 15 Mar 2020 17:39:08 -0400

> 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

---

From: Uri Blumenthal <[email-masked]>
Date: Sun, 15 Mar 2020 22:44:58 +0000

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 <[email-masked]> wrote:
> 
> 
> 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
>>>

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 16 Mar 2020 10:33:36 +0000

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 <[email-masked]> wrote:
>

---

From: Lou Berger <[email-masked]>
Date: Mon, 16 Mar 2020 07:29:46 -0400

Stewart,

I think a number of your responses are actually more general than mpls and 
have to do with how routers and routing protocols are built. these concepts 
that are now generally taught in classes, not rfcs...

Lou

----------
On March 16, 2020 6:34:54 AM Stewart Bryant <[email-masked]> wrote:

> 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 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"
>> 
>> 
>>> 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:

---

From: Uri Blumenthal <[email-masked]>
Date: Mon, 16 Mar 2020 12:22:35 +0000

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 <[email-masked]> wrote:
> 
> Uri,
>

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 16 Mar 2020 14:00:40 +0000

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 <[email-masked]> wrote:
>

---

From: Watson Ladd <[email-masked]>
Date: Mon, 16 Mar 2020 07:18:44 -0700

On Mon, Mar 16, 2020, 7:01 AM Stewart Bryant <[email-masked]>
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.
>
>
> > 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.
> >
> >> 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
> >>> 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"
> >>>
> >>>
> >>>> 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

---

From: Lou Berger <[email-masked]>
Date: Mon, 16 Mar 2020 10:22:48 -0400

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 <[email-masked] 
> <mailto:[email-masked]>> 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.
>
> 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.
>
>     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 <[email-masked]
>     <mailto:[email-masked]>> 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
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     >>
>     >> Uri,
>     >>
>     >> 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 <[email-masked]
>     <mailto:[email-masked]>> 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 <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >>>>
>     >>>> 
>     >>>>>> On Sun, Mar 15, 2020 at 2:14 PM Lou Berger
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     >>>>>> Hi Watson,
>     >>>>>>
>     >>>> 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,
>     >>>>
>     >>>>>>> On Thu, Mar 12, 2020 at 4:07 AM Lou Berger
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     >>>>>>>> Watson,
>     >>>>>>>>
>     >>>>>>>> On March 11, 2020 10:30:27 PM Watson Ladd
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     >>>>>>>>
>     >>>>>>>>> [email-masked] <mailto:[email-masked]>
>     >>>> [email-masked] <mailto:[email-masked]>

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 16 Mar 2020 14:37:08 +0000

> On 16 Mar 2020, at 14:22, Lou Berger <[email-masked]> wrote:
> 
>> Are there really no security considerations when putting the two together?

Obviously I cannot think of anything that is not already in the text, or I would have included it. So if you can be more specific about what this interactions might be, I am more than happy to discuss them with you and if needed  to address them either directly or by reference.

>> Every MPLS network will just work with Detnet on top, no matter how rushed the deploy is?

DN will certainly not damage MPLS no.

A poor MPLS deployment will break many things besides DN. However whist I can see potential for a performance impact, I cannot see how a security impact would occur.

Stewart

---

From: Uri Blumenthal <[email-masked]>
Date: Mon, 16 Mar 2020 16:17:06 +0000

Lou,

Yes, adding that reference would help (IMHO).

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.

> On Mar 16, 2020, at 10:22, Lou Berger <[email-masked]> 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 Mon, Mar 16, 2020, 7:01 AM Stewart Bryant <[email-masked]> wrote:
>> 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.
>> 
>> 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?
>> 
>>>

---

From: Lou Berger <[email-masked]>
Date: Mon, 16 Mar 2020 14:29:29 -0400

Uri,

> Yes, adding that reference would help (IMHO).
This seems reasonable to me (as a contributor)

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

Does this match your expectation or do you expect something different?  
If so, what do you expect?

Lou

>> 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 Mon, Mar 16, 2020, 7:01 AM Stewart Bryant 
>>>     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.
>>>
>>> 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?
>>>
>>>
>>>     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.
>>>
>>>
>>>     cannot be self-contained, but it's unreasonable to epect a
>>>     reader to just "know" where all the omitted things are described.
>>>     >
>>>     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 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"
>>>     >>>
>>>     >>>
>>>     >>>> 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
>>>     model.  Is this what the sec-dir really is asking the routing
>>>     area to do?
>>>     >>>>
>>>     >>>> ADs,
>>>     >>>>

---

From: Uri Blumenthal <[email-masked]>
Date: Mon, 16 Mar 2020 19:56:30 +0000

On Mar 16, 2020, at 14:29 , Lou Berger <[email-masked]> wrote:
> 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). 

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

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

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

>>> On Mar 16, 2020, at 10:22, Lou Berger <[email-masked]> <mailto:[email-masked]> wrote:
>>> Watson, Uri,
>>> 
>>> would a reference to https://tools.ietf.org/html/draft-ietf-detnet-security-08#section-7 <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 Mon, Mar 16, 2020, 7:01 AM Stewart Bryant <[email-masked] <mailto:[email-masked]>> wrote:
>>>> > On 16 Mar 2020, at 12:22, Uri Blumenthal <[email-masked] <mailto:[email-masked]>> wrote:
>>>> > 
>>>> >> On Mar 16, 2020, at 06:33, Stewart Bryant <[email-masked] <mailto:[email-masked]>> wrote:
>>>> >> 
>>>> >> Uri,
>>>> >> 
>>>> >>> On 15 Mar 2020, at 22:44, Uri Blumenthal <[email-masked] <mailto:[email-masked]>> wrote:
>>>> >>> 
>>>> >>>>> On Mar 15, 2020, at 17:39, Lou Berger <[email-masked] <mailto:[email-masked]>> wrote:
>>>> >>>> 
>>>> >>>> 
>>>> >>>>>> On Sun, Mar 15, 2020 at 2:14 PM Lou Berger <[email-masked] <mailto:[email-masked]>> wrote:
>>>> >>>>>> Hi Watson,
>>>> >>>>>> 
>>>> >>>>  any opinion on this?     (for context, Stewart's response can be found at: https://mailarchive.ietf.org/arch/msg/detnet/-epL5Fb6bFIUltMrjH53C2316ZA/ <https://mailarchive.ietf.org/arch/msg/detnet/-epL5Fb6bFIUltMrjH53C2316ZA/>)
>>>> >>>> 
>>>> >>>> Thanks,
>>>> >>>> 
>>>> >>>> Lou
>>>> >>>> 
>>>> >>>>>> Lou
>>>> >>>>>> 
>>>> >>>>>>> On Thu, Mar 12, 2020 at 4:07 AM Lou Berger <[email-masked] <mailto:[email-masked]>> wrote:
>>>> >>>>>>>> Watson,
>>>> >>>>>>>> 
>>>> >>>>>>>> On March 11, 2020 10:30:27 PM Watson Ladd <[email-masked] <mailto:[email-masked]>> wrote:
>>>> >>>>>>>> 
>>>> >>>>>>>>> https://www.ietf.org/mailman/listinfo/detnet <https://www.ietf.org/mailman/listinfo/detnet>
>>>> >>>>>>>>> 
>>>> >>>>> 
>>>> >>>>> 
>>>> >>>> 
>>>> >>>> https://www.ietf.org/mailman/listinfo/secdir <https://www.ietf.org/mailman/listinfo/secdir>
>>>> >>>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview <http://tools.ietf.org/area/sec/trac/wiki/SecDirReview>
>>>> >> 
>>>> 
>> 
>> 
>> https://www.ietf.org/mailman/listinfo/detnet <https://www.ietf.org/mailman/listinfo/detnet>

Uri

---

From: Lou Berger <[email-masked]>
Date: Tue, 17 Mar 2020 08:39:49 -0400

Hi,

On 3/16/2020 3:56 PM, Uri Blumenthal wrote:
> On Mar 16, 2020, at 14:29 , Lou Berger <[email-masked] 
>>> considerations to those already described in the MPLS documents - 
>>> the draft should state so explicitly. Though I personally find it 
>>> hard to believe.
>>>
>> analysis is a *delta* analysis for previous IETF work/RFCs.
>>
>   * 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.
>>
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.

> 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<[email-masked]>wrote:
>>>>
>>>> Watson, Uri,
>>>>
>>>> would a reference 
>>>> tohttps://tools.ietf.org/html/draft-ietf-detnet-security-08#section-7help? 
>>>> note that Detnet operates/extends the IP and MPLS layers.  It is 
>>>>>     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
>>>>>     instead confine our remarks to issues that specifically apply
>>>>>     to the additional technology we are describing.
>>>>>
>>>>>
>>>>> 3552 section 5 also demands that attacks be enumerated and those 
>>>>> out of scope be called out.
>>>>>
>>>>> 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 
>>>>>     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.
>>>>>
>>>>>
>>>>>     > 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
>>>>>     issues and providing the appropriate references? A "normal"
>>>>>     RFC cannot be self-contained, but it's unreasonable to epect a
>>>>>     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.
>>>>>     >>
>>>>>     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.
>>>>>     >>
>>>>>     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
>>>>>     >>>>>>
>>>>>     >>>> wiki:http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>>>>>     >>
>>>>>
>>>

---

From: "Black, David" <[email-masked]>
Date: Tue, 17 Mar 2020 14:26:05 +0000

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 <[email-masked]> On Behalf Of Lou Berger
Sent: Tuesday, March 17, 2020 8:40 AM
To: Uri Blumenthal
Cc: secdir; [email-masked]; Watson Ladd; [email-masked]; Stewart Bryant; <[email-masked]>; 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 <[email-masked]<mailto:[email-masked]>> wrote:

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

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

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 <[email-masked]><mailto:[email-masked]> 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 <[email-masked]<mailto:[email-masked]>> 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.

Regards

Stewart

BTW

> On 16 Mar 2020, at 12:22, Uri Blumenthal <[email-masked]<mailto:[email-masked]>> wrote:
>
>> On Mar 16, 2020, at 06:33, Stewart Bryant <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> Uri,
>>
>>> On 15 Mar 2020, at 22:44, Uri Blumenthal <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>>>> On Mar 15, 2020, at 17:39, Lou Berger <[email-masked]<mailto:[email-masked]>> wrote:
>>>>
>>>> 
>>>>>> On Sun, Mar 15, 2020 at 2:14 PM Lou Berger <[email-masked]<mailto:[email-masked]>> wrote:
>>>>>> Hi Watson,
>>>>>>
>>>>>>> On Thu, Mar 12, 2020 at 4:07 AM Lou Berger <[email-masked]<mailto:[email-masked]>> wrote:
>>>>>>>> Watson,
>>>>>>>>
>>>>>>>> On March 11, 2020 10:30:27 PM Watson Ladd <[email-masked]<mailto:[email-masked]>> wrote:
>>>>>>>>
>>>>>>>>> [email-masked]<mailto:[email-masked]>
>>>> [email-masked]<mailto:[email-masked]>

detnet mailing list

[email-masked]<mailto:[email-masked]>

Uri

detnet mailing list

[email-masked]<mailto:[email-masked]>

---

From: Uri Blumenthal <[email-masked]>
Date: Tue, 17 Mar 2020 15:07:16 +0000

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

Thank you! And please see below.
 
> 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…

This is the kind of analysis/guidance that belongs to the Draft!

> 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 g…

I do not know if that hunch is correct, but it should be added regardless.

> explaining why a security mechanism is needed seems reasonable to me.

Thanks!
> so you want to repeat all the concepts from prior work/rfcs? 
> 
Not “repeat”, i.e., not copy text from what the other RFCs says). Refer to - i.e., “for general MPLS security consideration see section X of RFC Y."
>  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.
> 
That’s exactly what I’m suggesting.

> very happy we agree on this key point.
:-)

> Sure, but it sounds like we may differ on detail level needed in the reference.
My main point is that you tell the reader why you refer him to a given section of a given RFC, and what he should expect to find there. E.g., “see section X of RFC Y for details of the generic MPLS Threat Model”.

> 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. 
I don’t know how many sentences it should take. All I want is that it is clear and useful (and if it also manages to stay brief - that’s an extra bonus ;).

=================
Uri