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

"Adrian Farrel" <adrian@olddog.co.uk> Thu, 07 March 2019 23:10 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9C794131476 for <mpls@ietfa.amsl.com>; Thu, 7 Mar 2019 15:10:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id DSBjwG5MZn8t for <mpls@ietfa.amsl.com>; Thu, 7 Mar 2019 15:10:10 -0800 (PST)
Received: from mta6.iomartmail.com (mta6.iomartmail.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CBE1131408 for <mpls@ietf.org>; Thu, 7 Mar 2019 15:10:06 -0800 (PST)
Received: from vs1.iomartmail.com (vs1.iomartmail.com []) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id x27NA2c3005013; Thu, 7 Mar 2019 23:10:02 GMT
Received: from vs1.iomartmail.com (unknown []) by IMSVA (Postfix) with ESMTP id 16B082203B; Thu, 7 Mar 2019 23:10:02 +0000 (GMT)
Received: from asmtp3.iomartmail.com (unknown []) by vs1.iomartmail.com (Postfix) with ESMTPS id 00CCC2203A; Thu, 7 Mar 2019 23:10:02 +0000 (GMT)
Received: from LAPTOPK7AS653V ([]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id x27NA0wL014981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 Mar 2019 23:10:01 GMT
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: mpls@ietf.org
Date: Thu, 07 Mar 2019 23:10:00 -0000
Organization: Old Dog Consulting
Message-ID: <026401d4d53a$e3e23820$aba6a860$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AdTVNc1ixxx1a+I5TC6NhcaF59rcgA==
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--13.644-10.0-31-10
X-imss-scan-details: No--13.644-10.0-31-10
X-TMASE-Result: 10--13.644100-10.000000
X-TMASE-MatchedRID: 8gy9DfjknR7yD+EqUBix4biMC5wdwKqdk9atiES99p0QH8CxzihpgYjM Udtb8z35MSeq2sKeo9Y2bQz4x5+GPojH1M7lRGyeKNDiix19qYGWesyrtKuK7T9QzIS5KoGBgna slZ/rTdmwNKmrJljjNONaru5SD9HYD7rWxk93B9F/TWpwlAOFXqKRkGOW2z9y+Cckfm+bb6ByzE UsduoE4hJZHXXpafFmTa4Cf0D6Ap3Ncm2bW2t5nMOriXY+VMfQlavqJJda2A+7+NPPxj+R6pKQl syF4c0BRsl+7fC2d3bTMj+5r/4Bdlzo1wB5HFP3081phgl5F/kS12tj9Zvd85ps2hiiMFB2RCmR CsRFFA35PtOeXawPGTdIy3gNLQNBxMH2MOMU8Vsp/8fGeWUPKKuvxGMwcZCYGZ2zNQwkHw3N6oa SBNupLy9oi4Z4GUtI7Pf7V6wkGEBo/jLJ/UOlaHT7rnt3EYkYvnvglABdz6Gynk7TnYzMuo0xgX l4ajAL4vM1YF6AJbZcLc3sLtjOt9CpCFLDTHZU3QfwsVk0UbtuRXh7bFKB7pvabgEc58yH34yyP QGMc3LURn+/kV6A58RTgOwVLJz/WClYJu9r4yY=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/gXEOqVRZnkV8riCHW8iCyAFv26E>
Subject: [mpls] Change of some substance to draft-ietf-mpls-sfc
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Mar 2019 23:10:16 -0000


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. 

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

   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.