[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [62.128.193.156]) (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 [10.12.10.121]) 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 [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 16B082203B; Thu, 7 Mar 2019 23:10:02 +0000 (GMT)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs1.iomartmail.com (Postfix) with ESMTPS id 00CCC2203A; Thu, 7 Mar 2019 23:10:02 +0000 (GMT)
Received: from LAPTOPK7AS653V ([87.112.237.8]) (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-Originating-IP: 87.112.237.8
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24476.003
X-TM-AS-Result: No--13.644-10.0-31-10
X-imss-scan-details: No--13.644-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24476.003
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
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.
- [mpls] Change of some substance to draft-ietf-mpl… Adrian Farrel