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

[Watson Ladd <[e-mail]>]

On Wed, Mar 11, 2020 at 8:29 AM Stewart Bryant <[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.

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

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

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

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

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

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

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

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

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