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

Benjamin Kaduk <kaduk@mit.edu> Mon, 18 February 2019 14:51 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 2DD7C1293B1; Mon, 18 Feb 2019 06:51:54 -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 Cz5U-ZOLzokx; Mon, 18 Feb 2019 06:51:51 -0800 (PST)
Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-eopbgr720097.outbound.protection.outlook.com [40.107.72.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 7FA1A128B01; Mon, 18 Feb 2019 06:51:51 -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=lVYPbnYPkpm/bwDCOEPn0B1t8qnyLYO4Y6dxuGmnqS0=; b=aEP/0P+4/bAV94OakfTNRvahNI4bG4Y7LzHKEbO4aUgE96bAm5FbC+IsDIgBKLzwLNtxzKAbnmCcp4RTgAkmRg51nxh+rFKadFzST4gxjq06Zd2jUZlyQmPraX9pV+c94lhw8VSlmrbt2eX20eaP/JpM9TtXFqWo1Gjcx6wqCbI=
Received: from CY4PR01CA0024.prod.exchangelabs.com (2603:10b6:903:1f::34) by SN6PR01MB4863.prod.exchangelabs.com (2603:10b6:805:d8::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.18; Mon, 18 Feb 2019 14:51:49 +0000
Received: from CO1NAM03FT023.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::201) by CY4PR01CA0024.outlook.office365.com (2603:10b6:903:1f::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16 via Frontend Transport; Mon, 18 Feb 2019 14:51:49 +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 CO1NAM03FT023.mail.protection.outlook.com (10.152.80.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.13 via Frontend Transport; Mon, 18 Feb 2019 14:51:48 +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 x1IEpiIl031107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Feb 2019 09:51:46 -0500
Date: Mon, 18 Feb 2019 08:51:44 -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: <20190218145144.GG24387@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> <20190216202815.GD82217@kduck.mit.edu> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE29288DC3E@dggeml510-mbx.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE29288DC3E@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)(346002)(39860400002)(136003)(396003)(376002)(2980300002)(13464003)(189003)(199004)(55016002)(8936002)(305945005)(8676002)(229853002)(7696005)(14444005)(76176011)(93886005)(53416004)(47776003)(50466002)(88552002)(5660300002)(356004)(1076003)(97756001)(246002)(2906002)(478600001)(26826003)(106466001)(956004)(446003)(6916009)(86362001)(6246003)(36906005)(46406003)(336012)(486006)(126002)(426003)(4326008)(476003)(11346002)(186003)(23726003)(26005)(53546011)(104016004)(58126008)(54906003)(16586007)(75432002)(106002)(786003)(316002)(33656002)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR01MB4863; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1;
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: be2d71d8-ad48-4ebb-e147-08d695b09c53
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:SN6PR01MB4863;
X-MS-TrafficTypeDiagnostic: SN6PR01MB4863:
X-Microsoft-Exchange-Diagnostics: 1; SN6PR01MB4863; 20:ym0GVIZcxbl/bnNQVTKyq9Qkuf91nUNkTgV2HhhgSFHbtxZC5ceiMpHCkoWV8lxYPwtEdDGUPphqdKu+gYJk/rl5Sc4xqEJwb/zLA45c7A2o0mZ/iae+4J+D7TiMsYfTw/3HYQUAT2O9ceDH6yPywTZMcd2Od5/esPjTjUMBkeOKofaKC+vjgjwik13IwpvY4Tghp6fvU/C3UN8VZSThEhLvLzw7D45TBFep0xt2J3655KAr3IFU+IkYgXZ2zmEljvzDuSEdnmf0QU4Rv3QT0pbe6DaT4t/0vVFS/7OR4ZnpDpGeDgzUtKsKIYx86KAhwvtmJw0rYMnGDUkW3nzqZv2ZA1I75YrW/lVrMCK42eMHyT0jwrilLaztS0SMh9inymgz2Z1eLJPTw4Sp/28ETqg/jb1PiUhq+A2UN02KWXSqwqTzJ7IIu+fxZ9k0tr7epQr+UGaQ7hdPPpZDmo26FqgxtJ0iSUUsTzqtzY2/RXDUwQDHLqbbcjbf52q0cl3CRi7LXPaBBJ7mMRwM5K8V+/DsJgotE8leZnohIUArm+TULHg5mixpIn8s0TM8uAz3VANWtiKSs7dXBkEGKa0sWmS8jEHsnXMgPLkzD3tqMnk=
X-Microsoft-Antispam-PRVS: <SN6PR01MB486342680B313C0162BDC542A0630@SN6PR01MB4863.prod.exchangelabs.com>
X-Forefront-PRVS: 09525C61DB
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN6PR01MB4863; 23:RlpfaBZzEPRXK8P9ARlMbNAqMLnUBDd5GSD4ol+T+?= =?us-ascii?Q?Zp58+rzdsfnWJ2ELub1Gm47E2kEbTRPriWs44thxxDplN/FKUgIEcUSjYHLU?= =?us-ascii?Q?bsPnyVOOEulZo3BGMTnuSq2c8cPNttOn64zdR8PsXjvwvyf8+NBQUKZx16Vh?= =?us-ascii?Q?b3a6ItuK3LABwvlyT3wwhN17ucXHWf7UOsfYPoEertFKUagmwNfn+MgUuFUB?= =?us-ascii?Q?0k00A5Ts2+BRYhJrUzm/SGmd2z/hvU/y0ZUbS015s444QDBaHaPWHJJITVK8?= =?us-ascii?Q?USSYixoo8AwBpuNrEBbc7kKqeW5BsusQbT+mlTOwB+2v0qEiZCB3SDdOl6+M?= =?us-ascii?Q?d8uKxZLt9ViFWWW0QkjxSnjgeNFHy37TgHP+cQuxsfu+71mVelNt607805ol?= =?us-ascii?Q?gcMyxzmqeHelwFexRT7JIqcEmYq8sXlN64dnnk7KtRQMWM6Mu5JAmk0ZtFrg?= =?us-ascii?Q?y3nFuSwfS34nUt2Hp5PgMLRNyNSujCWFoFqxVHPNvDjbYX+9zqKWlh9NMQY6?= =?us-ascii?Q?yTKT4zlCTv6uUPGIBwn9bKjJiDPvd1hGRRTTOs+mk4LMWTGCE/X6ihg93DL8?= =?us-ascii?Q?Yu0m5hwEF4+aoH1q3kKJhbTyWHlUEghzvjiyvN1kKaX2Oc36kL2Zwb0ykWgM?= =?us-ascii?Q?D5p3WGC0upuL1I0+cNAQ4/jbVe2NO0oY3jKPATJX9tj28ol8T5dkFLtJkML2?= =?us-ascii?Q?czH4W8KweIhSfWX3UWtslk2uf1QAwuSLVOawfYqVod/FL9ANtpyQFxJcE+NO?= =?us-ascii?Q?5L7lZU83CBZXE+udtqfnIWDM2xO25WM08N1gc6hiT4gMmldRvLZBoLJ2ZZFv?= =?us-ascii?Q?mwacEQwmc1P5Rdk5DnluMNHl6JCRdUW9siL3F9JhF/UpvI57HnZSwdf1/zCZ?= =?us-ascii?Q?DUUMOaqq5xqboUk3V5mQaC7PF8UDH8uq8slHRWvTQo7iDdj0gCHo2DQbiAU8?= =?us-ascii?Q?ng3tj/fLdBYBZSaYIbW7CQC1zGXeXCpwgOL91KCl8nsQCI0wR/nnxzE9SRof?= =?us-ascii?Q?YjwLMsNRqqTVbCeOY+VRCG5GgsPXLSm1UapIVvEq3N89LBbIuf5Ry0bqjKS6?= =?us-ascii?Q?WZKl7X3D4TOI3x51R7jGm6kCKhPsyLzsrbO/0pl/FSgs7sW3sdIcCtERe8VZ?= =?us-ascii?Q?eM3cc/Ytk2hojNd9QvW/JJzO3+ex36C7KQgVIH7y+vWH9sThHMLjAJ+tdjJp?= =?us-ascii?Q?6W7yxzsYMDI7sZ5FlUps+kvpcoVSI4kChQVE4Upy5tpeNFiFMpioJLCkfeUm?= =?us-ascii?Q?rDjblOa5P8MM3OEzx/wOZ19NOPm4He7i8gtCskHzoQlJEUIotHooLbzC1gJh?= =?us-ascii?B?Zz09?=
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Message-Info: WGuFwtGUsdiMOeUxAOx5S9pwVIQYyR5QusLdVhqekwUtynGHckmKTG0YIE3BWyW34dWTzUpJr1rGuMnzGQP7nTtZFyTIH7K8jwUOlZepDtXRJ7S+nmiBqD+ytUfWxVbvIZgw5hpkfQtGJq8NwZD98JdS7ASzmGyFxAnzuHJwtBis18kkrLhfsT90jdOtGlOqHyI5Zegdgu5ckQs7dz6f16ll++2k5mcEoHjpe/ggvTipdYgAMgVgRYPy1ybUSFGa2YyAlHruGbZ3wbvsbEEwEQPIO0kG58NRGv1Hd9oASntmhjyu/5m8hInwhp/cRPq8fEqKHOuYickAcsOUtfSBqq0YYA5Z+G19sEbphFHkGl87feqJ1cGnfMgez6btjj/8HPtB5fVSvjUmfdF4+C94y4EMGAk9gb8oLROEB22LhZc=
X-OriginatorOrg: mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Feb 2019 14:51:48.4495 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: be2d71d8-ad48-4ebb-e147-08d695b09c53
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: SN6PR01MB4863
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/S8Bkn9fOUBiTRQ9JhWjkaV8hm1A>
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: Mon, 18 Feb 2019 14:51:54 -0000

On Mon, Feb 18, 2019 at 10:11:24AM +0000, Mach Chen wrote:
> Hi Benjamin,
> 
> > -----Original Message-----
> > From: Benjamin Kaduk [mailto:kaduk@mit.edu]
> > Sent: Sunday, February 17, 2019 4:28 AM
> > To: Mach Chen <mach.chen@huawei.com>
> > Cc: Linda Dunbar <linda.dunbar@huawei.com>om>; 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
> > 
> > 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!
> > >
> > >
> > > "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).
> 
> OK, will add such a statement in the security considerations section. 

Thanks!

> > 
> > > >
> > > > 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.
> 
> Yes, this is that I am referring to.
> 
> > 
> > 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.)
> 
> You are right, for protecting against unauthorized sources, IP ACL is the only way proposed in RFC 8029 and this document. 
> 
> > 
> > > 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.
> 
> I agree with you. Does it mean that you are OK with the current security considerations, given that a statement regarding the intermediate node's process will be added.

Given what I've seen so far, yes.  (I only skimmed the document as part of
this thread, and will do a full review as it comes up on an IESG telechat.)

-Benjamin