Re: [mpls] MPLS Working Group Last Call on draft-ietf-mpls-mna-requirements

[Adrian Farrel <[e-mail]>]

Sorry, this took longer than planned. 

 

Responding to Stewart’s email with Matthew’s imbedded.

 

Adrian

 

> Thank you Adrian/ We will work through these points in the process of producing a

> new draft, assuming of course we are aiming to publish a draft at all. I think an RFC

> is useful, but if we are not going to publish an RFC, why would we spend time refining

> and polishing the text? 

> 

> I agree with Matthew, however I have a few additional comments that I include in

> the snipped text below.

 

Section 5 is a bit skimpy. You might at least point back to the
requirements in the other sections that relate to security.

But, since you say, "The mechanisms required by this document introduce
new security considerations to MPLS," you might at venture to say what
those new considerations are. In particular, does the use of MNA make
any difference to the security properties of other MPLS functions?



MB> To be honest, there has been little discussion of the security implications of MNA in the working group.
As an author I have a concern about a couple of aspects of MNA: it potentially
allows solutions to embed metadata from the payload into the MPLS layer (so exposing data that a user
might assume is otherwise opaque to any transport network), and using something inserted by the ingress LER to affect forwarding
downstream when the ingress may have no idea how that is being used or whether it is used in a manner consistent with
its intended use by ingress. 

> I  rewrote the FWK security section and I think that it could use yet more work. I think the 

> right approach is to generalise the FWK text and see if there are other generalities that

> need including in the REQ text. We are in much the same position as SRv6 and N/W

> programming where introducing new capabilities in the data-plane as per the current

> fashion does expose new vulnerabilities. Indeed I wonder if IP itself would pass a modern

> security audit and thus have been killed over 40 years ago. This is of course all about

> pragmatism and we should use the requirements text to at least get people thinking in

> the right direction. 

 

[AF] I think Stewart is right that we can have a positive feedback loop between the use cases, framework, and requirements.

[AF] But this is the requirements draft, so it does not need to solve the security problems. It just needs to identify the attack risks and set out the requirements for the solutions and architecture.


== MINOR ==

It came as a surprise to me in Section 1.1 that Ancillary Data can be
write as well as read. Maybe I haven't been paying attention to the
use cases. I suppose this is OK so long as the WG noticed and agreed.

MB> This reflects discussion about use cases such as time bounded networking where a mid-point may need to update a timestamp
embedded in the packet. 

> Yes there are a number of cases where it needs to be written. There are

> certainly cases associated with modern thinking on congestion control

> particularly in the 5/6G world. There is the NFFRR case (nearly 20 years

> back we abandoned some IPFRR approaches due to the absence of this

> facility) particularly with some of the failover approaches people seem

> to be thinking about. Then there is time transfer where residence time

> accumulation is required to improve the radar part of the time transfer. 

> Time transfer is an increasing <http://increasing.ly> ly urgent aspect of national infrastructure

> security requirements as the vulnerability of space based time transfer

> becomes more apparent.

 

[AF] This is all good. Maybe just paint it red. That is, make it very clear to the reader that AD is read/write.

[AF] Are there any implications of write that need to be covered? Size change? Unpredictable stack hashes?

3.1

   6.   The design of any MNA solution SHOULD be such that an LSR is
        able to efficiently parse the label stack.

What does it mean to parse a label stack? Are you saying that an
implementation should be able to read ahead in the label stack? Is that
consistent with the MPLS architecture?

MB> Yes. Scanning the label stack is done today in the case of Entropy Label.

.. and there is an expectation within the WG that the NMA information will be deep in the stack if only to co-exist with SR.

 

[AF] Let’s not run on expectations. Let’s make sure the requirements are clear.

 

What does "efficient" mean in this context?

MB> We were trying to capture a requirement to minimise how deep in the stack such parsing is required. I agree
we should be more explicit here. 

Why is this a SHOULD? How would a solution designer decide to vary this?

MB> I agree it would be better as a MUST.

> The problem with MUST is that it is solution constraining. 

 

[AF] Of course. It is the purpose of requirements to constrain solutions! If it is necessary that the stack is parsed in order to be able to deliver the function, then it is necessary that solutions enable the stack to be parsed.

[AF] It is possible that this hinges on “efficient”. All solutions MUST enable parsing of the label stacks, but some solutions MAY sacrifice efficient parsing in exchange for some other feature.

 

> The reason for “efficient” is that this is in the fast path and so directly impacts the

> headline performance and the amount of h.w support needed to maintain that

> performance. As you know is a fundamental of all packet components that are

> processed by the forwarder in the fasts path that the process needs to be efficient.

> Unfortunately only a few modern engineers seem to have ever written forwarders

> and most need to be reminded that not thinking through this aspect of the problem

> carefully enough has significant consequences.

 

[AF] I agree that an implementation is free to be of poor quality and not be efficient. What seems to be important is that the architecture and protocol solutions allow an implementation to be efficient if the function requires the label stack to be parsed.

 

3.1

  8.   Consistent with MPLS best practise, MNA solutions MUST NOT
        increase the size of the MPLS label stack more than is
        necessary.

You and I might agree on this "best practice" but is it described
anywhere that can be referenced? And, is it necessary to mention the
best practice, or could you just write the requirement.

MB> I agree we can remove ‘consistent with MPLS best …’

And what does "more than is necessary" mean in the context of a
proposed solution?

MB> There are always going to be practical constraints on the size of the stack that can be pushed at ingress LER. This
is made worse by MNA, which may consume space that is needed for LSP labels, for example from an SR-TE label stack.
So what we were trying to say was that solution design choices, for example the way NAIs or ancillary data are encoded,  matters.

MB> We could be more specific and say that ‘solutions MUST minimize any additions to the size of the MPLS label stack”.  

> That is going to result in the ISD folks complaining that we are promoting PSD. That

> needs to be carefully worded and that is what the original text tried to do.

 

[AF] Let’s not get into what President Biden is pleased to call “teams”.

 

[AF] I think that both “not more than necessary” and “minimize” are contextual. That is, a solution to a requirement to include things on the stack has a necessity to include that material on the stack.

[AF] But I agree that the wording, in both cases, is likely to be misinterpreted.

[AF] I wonder what would be lost by striking this requirement entirely. It is not as though a solution is going to wilfully and randomly increase the stack size.

 

[AF] If there is a debate to be had about PSD and ISD then I think we should have it. What is the largest acceptable amount of ISD that we will consider? There is clearly a line between 1 bit and 10kB

 

3.4

   11.  A solution MUST be provided to verify the authenticity of
        ancillary data processed to LSRs [RFC3552].

"Authenticity" is only mentioned once in 3552. "Authentication" is
mentioned a lot, but it is mainly about user identity. I think you
may be talking about "Data Integrity"?

MB> Yes. The intent here is to say that mechanisms are required to prevent a bad actor from using MNA to alter the forwarding or other behavior of the network in an undesirable way.

> … except I cannot see how you get a satisfactory authentication method to

> work within acceptable ISD constraints.

 

[AF] I agree with Stewart that this seems to be a problem. We can (and do) perform data integrity and authentication at line speed, but doing it multiple times per packet is likely to be a challenge. Further, the SA model is a challenge for per-hop security. Furthermore, adding signatures to packets only compounds the problems of data size. 

 

[AF] But, and I think this is important, we must not allow our requirements to be influenced by the practicality of solutions. If it is necessary to secure the integrity of the AD, then that is the requirement.