Re: [mpls] [secdir] Secdir last call review of draft-ietf-mpls-lsp-ping-lag-multipath-05

Benjamin Kaduk <kaduk@mit.edu> Sat, 16 February 2019 20:28 UTC

Return-Path: <kaduk@mit.edu>
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 59BE2130EBA; Sat, 16 Feb 2019 12:28:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu
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 fLByxz6dWhPJ; Sat, 16 Feb 2019 12:28:23 -0800 (PST)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-eopbgr810097.outbound.protection.outlook.com [40.107.81.97]) (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 79AE212F1A2; Sat, 16 Feb 2019 12:28:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=I+EPbpnhttHUaGa0RAwEfEOuyyrPZyO9OVcIEK2oulc=; b=E9mRYZqM4mwgaaKG/bwe90jIursUIBKF3vYTYGwWW4TFPd6Yfw9E9D1hu6ShBNUO9v8Gpakxmui4ModwZ9U/pIBFh361ovFqhkix6DHc3eiQAZI+xrYphQ2sQNyYOJGtfAIq1LVmVzbTlep7WuC0E2e8mqIYgahbTiywtZTuaPc=
Received: from DM5PR0101CA0001.prod.exchangelabs.com (2603:10b6:4:28::14) by CY4PR01MB3287.prod.exchangelabs.com (2603:10b6:903:e9::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16; Sat, 16 Feb 2019 20:28:21 +0000
Received: from BY2NAM03FT039.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e4a::209) by DM5PR0101CA0001.outlook.office365.com (2603:10b6:4:28::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1622.16 via Frontend Transport; Sat, 16 Feb 2019 20:28:21 +0000
Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu;
Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu;
Received: from outgoing.mit.edu (18.9.28.11) by BY2NAM03FT039.mail.protection.outlook.com (10.152.85.205) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1580.10 via Frontend Transport; Sat, 16 Feb 2019 20:28:20 +0000
Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x1GKSGPW032739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 16 Feb 2019 15:28:18 -0500
Date: Sat, 16 Feb 2019 14:28:16 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: Mach Chen <mach.chen@huawei.com>
CC: Linda Dunbar <linda.dunbar@huawei.com>, "secdir@ietf.org" <secdir@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, "draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org" <draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Message-ID: <20190216202815.GD82217@kduck.mit.edu>
References: <154455986336.13151.8483284555885294015@ietfa.amsl.com> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE2927B2883@dggeml510-mbx.china.huawei.com> <20190126211729.GJ49072@kduck.mit.edu> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE292889888@dggeml510-mbx.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE292889888@dggeml510-mbx.china.huawei.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(376002)(39860400002)(136003)(346002)(396003)(2980300002)(13464003)(199004)(51914003)(189003)(356004)(88552002)(8676002)(106466001)(246002)(26826003)(478600001)(8936002)(2906002)(54906003)(53416004)(104016004)(106002)(36906005)(58126008)(16586007)(75432002)(86362001)(786003)(46406003)(50466002)(316002)(97756001)(33656002)(6916009)(26005)(53546011)(14444005)(1076003)(47776003)(5660300002)(76176011)(7696005)(55016002)(305945005)(23726003)(4326008)(446003)(426003)(93886005)(336012)(126002)(486006)(476003)(6246003)(956004)(229853002)(11346002)(186003)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR01MB3287; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1;
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: b1c14253-d078-4302-a92f-08d6944d4aeb
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(4608103)(4709054)(2017052603328)(7153060); SRVR:CY4PR01MB3287;
X-MS-TrafficTypeDiagnostic: CY4PR01MB3287:
X-Microsoft-Exchange-Diagnostics: 1; CY4PR01MB3287; 20:+2VnjcvkH67Tx0Sm+biV/6KradzTFjE7zggikFI/N1ODnIMiJx3ueH4EUf6FtcqgkIp/JBLpXzoU4foGJELxG1Qkoclwx//0AgRXbeElDLBaQv5ehNQJY5/6CddJvsSIgAUpgrQAylJUf5mqrXrY0twK6I5lfqh1TBr5Y+V6nvsv6370aELC+Y++ekOS2Zpw8jjqGpbmms9O3LVau5ix+dG1Rh/BSdd5CbbBoe5rmApLWUmQxLnOugRhrVepDgGC95RoHRpZA5tUDnQKVGSNmPEJBgC7irBodR9i2Wn1QFcmroHDMdRmU5Iss/RT8QVBZ6GkkMCDsE/H/E/Z/udOBdAAx6VD/ElgNjW819IH21x+3VAd/C2olUqtDnBQBci/Vi5li0Loe7X77uMmAQEIpm5j5uqpqVcaG5r8OX7gVdPkbhh9hMBHv4IlwxiMpjE8RATomMOmbYpiLtJAl8D8ZSIhtUvxioPpY9rCoOMzWfE9977TOpNQgS+gv+hw87VgmtUaiedh/tJabBS7IwazBFX8zwWLP+OVH4lqY//XzT4Sd+XTc+ZcU2EbAoAB4QMvQhkkBSdGslXRgnUnCvt/xl9W4HkVAIlZZSeCWl7buoU=
X-Microsoft-Antispam-PRVS: <CY4PR01MB3287069E9B8ACF9B07A5BB2FA0610@CY4PR01MB3287.prod.exchangelabs.com>
X-Forefront-PRVS: 0950706AC1
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY4PR01MB3287; 23:QnQzhMrBSbRtj96yz7pvan1g9x2PFxZtv17kFUsYD?= =?us-ascii?Q?02fUeLa4P1cWL88Eqdd0lM9+P7JfoP2Cowvw7sWtsw9xTWGNc/Yxm+3uOQQJ?= =?us-ascii?Q?gWGdYx++f+TnMDnB2vbmzLl7720Scmv6wfTWAm9fynRmYvBxN5GHJJJUozyV?= =?us-ascii?Q?jgeffd7qtjzgD4Lo/Jb8Cg/9KhqI2wm9Gw/ts65kIUTZj+yhQGsTL4eJz5Dw?= =?us-ascii?Q?71mPivqaTXDbUGNk1GmzOfnjcF9SrvV6hPDfu9LpTm/WLE8WERjD+LMFprEF?= =?us-ascii?Q?G7shiDHn6XWMIe/ktFpqZ9BSl9c7GYfAXRRviN6q5uuAyh4sxy9kqf9FYZ7w?= =?us-ascii?Q?3JPb0k/GdTr0sMfLjSexUzgSwNwCWxgA5s/ZPV0pybL8sIekMvDGOwmCFKPn?= =?us-ascii?Q?gUkrYTaFMcWBP+q6/4qA30kjiN8xVBWo9xb/mklA3+oP0hr/iCnU21qYERXB?= =?us-ascii?Q?xarawwAwJZuKqHU1p/9NAKr+RNLu1kRMbO4VTyTJKNegEsRqeEosrNuMhlMy?= =?us-ascii?Q?WPhMJ5eZ1gTvdgfNRh36sirPCOahUedKJp+1xUvFE7zrpz+kbvpQp+jF8SMq?= =?us-ascii?Q?KDrbLr4JyxXRLhu1jvKPxfJO5g0pQP84d48kRpvonzKZA010JlBLQj+qCpMd?= =?us-ascii?Q?qAwTXudV0rxXCjmVfTdjmRVVMRGBG05VW2yv0iEDjweTjYJASBU71PYTD6la?= =?us-ascii?Q?mUaDKkGNW8xtjR2kF8SOCUKtN6FIEbUm+/M+lpezg7sUcG/CShkIswdEokk7?= =?us-ascii?Q?q5f6y5K0Lqbu1CG/jFuMn3J/tEcrza+HuePqdMj3mtn8VNU3gWavB/FLdUlh?= =?us-ascii?Q?YrdrNFTOmJGE/Gz5elH7JoDjxlkdH5dAlVv4shAdu484ZMBqBPqMGdMH1xVC?= =?us-ascii?Q?WenQwEQ8wHWN6tOCx3JapEgEz72fNQistCmjKI62Ipm+LjZWpfXocoGU89gm?= =?us-ascii?Q?DoByMALwZ5nwA91PesrKpvbmlKZQ4gWl3JtrgmcIv0xtZt0TZv5jUnz5BfrB?= =?us-ascii?Q?OqVOglrBf5p+LsPPEU38pqcfTu4R2et48A6coY1S/Yjlha7EE4lIGL6tWOQT?= =?us-ascii?Q?u9vKEU4gVxDjh4H4O1XuYvjNyCo86DcnHRMuoG4JixdPm9w5O9LWbDPa2OR1?= =?us-ascii?Q?1voaMfG2wfUkjXOlEx+BGw9Y4daI+5Q9jx1amIIOTaLnzChDEsu3OjFmTcXU?= =?us-ascii?Q?jdhtKdwlnFXTcFkN3txoFaAu5HmdjLuVzh/XHtrVDk1aOfiU5i1FRV68SjZw?= =?us-ascii?Q?OodiNHX7Sp0oK4XKHLdWOYNZvW8cxePYdYAoOMEEpoI/DfXkTOFKPA8jhdp8?= =?us-ascii?Q?BPrjTqoUtyFcRlbbMi/d6I=3D?=
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Message-Info: TFfZj69soQ3eX0ccf8qMO2ZGHhbdzvYC5gQsJFOd45icJK6883Rj5SveiEMSwVz8aSvuNXsZNnWXi9Pgc2P16jLNG0wBHJlOTJWTBpucKpxJfrU38b3JaNxrERHpwJfivifjvRt5/7szg6UoxFlp37y1NwCr80Kk+ydSbJdUWcU1k5khA1nR4hMzrOOSs6i0a87Y/WSNkLNEURF0ljif1QM8/WmDq0sWDT7y9/l5P4r2gnL68dseGZVSBzrCF4VLuMqwdoEoLIaw1djtuk49rRWGcTFL3pimVSWsNsQ+1iu4tiP4RwAzkgk0Vxs+s6f0tglSXWiFV8toBW/PJJw3Jn2Jbdk3LMnZivilPUNLCBo2RW3tBsrNty6w4JtaQjVOdVSXwtZEoMBfucpyZhRqnMjFhNH1dYlOtWLf3UJyAgc=
X-OriginatorOrg: mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Feb 2019 20:28:20.5701 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b1c14253-d078-4302-a92f-08d6944d4aeb
X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR01MB3287
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/UIAV4L3LYGHHUqJEsaF4_gm0D0g>
Subject: Re: [mpls] [secdir] Secdir last call review of draft-ietf-mpls-lsp-ping-lag-multipath-05
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: Sat, 16 Feb 2019 20:28:26 -0000

Hi Mach,

My apologies as well for the delay.

On Thu, Feb 14, 2019 at 03:02:07AM +0000, Mach Chen wrote:
> Hi Benjamin,
> 
> Sorry for the delayed response!
> 
> Please see my response inline...
> 
> > -----Original Message-----
> > From: Benjamin Kaduk [mailto:kaduk@mit.edu]
> > Sent: Sunday, January 27, 2019 5:17 AM
> > To: Mach Chen <mach.chen@huawei.com>;
> > Cc: Linda Dunbar <linda.dunbar@huawei.com>;; secdir@ietf.org;
> > mpls@ietf.org; draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org;
> > ietf@ietf.org
> > Subject: Re: [secdir] Secdir last call review of draft-ietf-mpls-lsp-ping-lag-
> > multipath-05
> > 
> > On Fri, Dec 14, 2018 at 02:11:21AM +0000, Mach Chen wrote:
> > > Hi Linda,
> > >
> > > Thanks for the review!
> > >
> > > Some responses inline...
> > >
> > > > -----Original Message-----
> > > > From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Linda Dunbar
> > > > Sent: Wednesday, December 12, 2018 4:24 AM
> > > > To: secdir@ietf.org
> > > > Cc: mpls@ietf.org;
> > > > draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org;
> > > > ietf@ietf.org
> > > > Subject: Secdir last call review of
> > > > draft-ietf-mpls-lsp-ping-lag-multipath-05
> > > >
> > > > Reviewer: Linda Dunbar
> > > > Review result: Ready
> > > >
> > > > I have reviewed this document as part of the security directorate's
> > > > ongoing effort to review all IETF documents being processed by the
> > > > IESG.  These comments were written primarily for the benefit of the
> > > > security area directors.  Document editors and WG chairs should
> > > > treat these comments just like any other last call comments.
> > > >
> > > > The summary of the review is Ready with comment
> > > >
> > > > The described mechanism for LSP Multipath Ping is very clear. The
> > > > Security Consideration re-uses the description of RFC8029, which is
> > > > very comprehensive.
> > > > It would be better if the draft describes how to prevent
> > > > intermediate LSRs in between the Initiating LSR and Responding LSR
> > > > from mis-using the detailed link information (e.g. forwarding to
> > somewhere else).
> > >
> > > The Echo Request and Reply messages are directly exchanged between the
> > Initiating LSR and the Responding LSR, those intermediate LSRs just forward
> > the messages as normal packets, they will not see the detailed link
> > information unless if they inspect and do DPI on every packet forwarded by
> > them.
> > >
> > > The detailed link information is supplied to the Initiating LSR for using, the
> > intermediate LSRs will not try to use it even if they received the information,
> > because there is no corresponding Echo Request to the received Echo Reply.
> > 
> > The intermediate LSRs still will have access to the plaintext information, even
> > if in normal operation they do not need to act upon that information.
> > Generally in this sort of situation we will either explicitly state that the
> > intermediate nodes must be trusted to not abuse the information in
> > question, or provide some mechanism for end-to-end confidentiality
> > protection.
> 
> "Intermediate nodes must be trusted to not abuse the information" is normally assumed. For the intermediate nodes, there is no different between the Echo Reply messages and any other data traffic, control messages. They just forward the Echo Reply messages as normal packets.  I am not sure it needs to explicitly state this.  Do you suggest to add such a statement in the security consideration section?

The concern is not about the normal operation, but rather about abnormal
operation, e.g., if an intermediate node gets compromised by an attacker.
We need to document the new abilities an attacker gets, when comparing the
original case of "an attacker compromises an intermediate node that is
using MPLS without this mechanism" to the new case of "an attacker
compromises an intermediate node that is using MPLS with this mechanism".
So, while I do suggest adding a statement to the security considerations
section, the statement I want does not relate to the normal operation case
(when intermediate nodes ignore the contents of the message).

> > 
> > Also (noting that I only skimmed the document so this may not make sense),
> > the security considerations seem to suggest using an IP ACL for determining
> > which messages are trusted; IP ACLs are generally not recommended in favor
> > of cryptographic mechanisms at this point.
> 
> IP ACLs was introduced in RFC 8029 and is reused in this document, it's

I did not find a clear and explicit declaration in RFC 8029 of the concept
of an IP ACL; I assume you are referring to:

   To protect against unauthorized sources using MPLS echo request
   messages to obtain network information, it is RECOMMENDED that
   implementations provide a means of checking the source addresses of
   MPLS echo request messages against an access list before accepting
   the message.

I do not think anyone is going to say "do not filter based on IP source
address", but there would be general skepticism about relying upon it as a
sole security mechanism.

> just one of the security mechanisms. This document is an extension to

(Could you remind me of the other mechanisms?  I don't think I have a good
handle on them.)

> RFC 8029, as stated in this document, all security considerations defined
> in RFC 8029 apply to this document. Do you have any specific suggestion
> to the current security consideration?

I am mostly just lamenting the state of affairs; this is a sufficiently
incremental change that it is inappropriate to require dramatic changes in
the security mechanisms.

-Ben