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

[Stewart Bryant <[e-mail]>]

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 <[e-mail]> wrote:
> 
> On Wed, Mar 11, 2020 at 8:29 AM Stewart Bryant <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 
>> 
>>> On 11 Mar 2020, at 03:22, Watson Ladd via Datatracker <[e-mail]> wrote:
>>> 
>>> 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.
>> 
>> 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.
> 
> Then this assumption that all the nodes are trusted needs to be
> explicitly stated in the securities consideration section.

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.

> 
>> 
>>> Pointing
>>> to a separate, in progress draft I don't think is an adequate security
>>> 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.

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.

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

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?

> 
>> 
>> 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
>>> the problem? Are there resources that can be consumed in the center the edge
>>> doesn't know about?
>> 
>> 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.
> 
> 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.

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.

> 
>> 
>>> 
>>> 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.
>> 
>> 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
>>> security goals are, and saying a mechanism may be used, without indicating how
>>> 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.
> 
> 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 provide some recommended text or a pointed to the text in an RFC that addresses this problem.

> 
>> 
>>> I can think of a few ways
>>> to abuse the one-packet only service to rewrite flows with great ease.
>> 
>> 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.

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

> 
>> 
>>> 
>>> The Internet is composed of smart nodes at the edge and dumb forwarders in the
>>> 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.
> 
> 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.

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

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

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.


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

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?

> 
>> 
>> 
>>> Is it
>>> realistic? Are the properties such as bounded latency and low jitter maintained
>>> 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.
> 
> 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?

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.


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

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.

> 
>> 
>>> 
>>> 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.
>> 
>> 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
>> 
>>> 
>>> 
>> 
> 
> 
> -- 
> "Man is born free, but everywhere he is in chains".
> --Rousseau.