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

[Stewart Bryant <[e-mail]>]

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



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

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.

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.

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.


---

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.

---

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.

- Stewart