Subject: [mpls] Change of some substance to draft-ietf-mpls-sfc

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 7 Mar 2019 23:10:00 -0000

Hi,

The latest revision of draft-ietf-mpls-sfc (version -07) includes a new
subsection to address an interesting Discuss from Eric Rescorla.

The essence of his Discuss applies to the inband propagation of metadata
described in Section 12.2.

This is an optional process for distributing per-SFP or per-flow metadata by
sending packets that follow the path of the SFP.

Eric pointed out in his Discuss that there is a problem in relying on the
distribution of metadata using this method because the packet carrying the
metadata might get lost and there is no way to acknowledge or guarantee
delivery. And he is right that even in an MPLS network, packet loss and
packet corruption can happen.

We have added a new subsection (12.2.1 - supplied below for reference) to
describe this case. The essence is:
- we do not propose a mechanism to plug this hole
- we do not attempt to quantify the risk (i.e., how often
  a packet might get lost)
- we suggest two mitigations
- we suggest that if this risk is unacceptable to an application
   it should use some other method of propagating metadata

The authors wanted to bring this change to the document to your attention.
We have not actually changed the way the specification works, but we have
flagged up an issue that you might want to solve in some other way.

We are not seeking a Working Group consensus call on this, and are not
empowered to call consensus anyway. However, while the IESG is clearing
their Discusses and while our AD is preparing to forward the document, you
might shout if you have any concerns. 

Thanks,
Adrian (for the author team)

12.2.1.  Loss of Inband Metadata

   Note that inband exchange of metadata is vulnerable to packet loss.
   This is both a risk arising from network faults and an attack
   vulnerability.

   If packets that arrive at an SFF use an MLI that does not have an
   entry in the metadata table, an alarm can be raised and the packet
   can be discarded or processed without the metadata according to local
   configuration.  This provides some long-term mitigation, but is not
   an ideal solution.

   Further mitigation to loss of metadata packets can be achieved by
   retransmitting them at a configurable interval.  This is a relatively
   cheap, but only partial solution because there may still be a window
   during which the metadata has not been received.

   The concern of lost metadata may be particularly important when the
   metadata applicable to a specific MPI is being changed.  This could
   result in out-of-date metadata being applied to a packet.  If this is
   a concern, it is RECOMMENDED that a new MPI is used to install a new
   entry in the metadata table, and the packets in the flow should be
   marked with the equivalent new MLI.

   Finally, if an application that requires metadata is sensitive to
   this potential loss or attack, it SHOULD NOT use inband metadata
   distribution, but SHOULD rely on control plane or management plane
   mechanisms because these approaches can use a more sophisticated
   protocol that includes confirmation of delivery, and can perform
   verification or inspection of entries in the metadata table.