Re: [mpls] Poll to see if we have consensus to adopt draft-farrelll-mpls-opportunistic-encrypt as an MPLS wg document

Eric C Rosen <erosen@juniper.net> Wed, 01 July 2015 15:54 UTC

Return-Path: <erosen@juniper.net>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 181251A90A4 for <mpls@ietfa.amsl.com>; Wed, 1 Jul 2015 08:54:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.892
X-Spam-Level:
X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_TVD_FUZZY_SECURITIES=0.01] autolearn=ham
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 YQjnYZMVfmmm for <mpls@ietfa.amsl.com>; Wed, 1 Jul 2015 08:54:05 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0135.outbound.protection.outlook.com [65.55.169.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1D421A90D1 for <mpls@ietf.org>; Wed, 1 Jul 2015 08:54:04 -0700 (PDT)
Authentication-Results: tools.ietf.org; dkim=none (message not signed) header.d=none;
Received: from [172.29.32.51] (66.129.241.14) by BY1PR0501MB1096.namprd05.prod.outlook.com (10.160.103.142) with Microsoft SMTP Server (TLS) id 15.1.201.16; Wed, 1 Jul 2015 15:54:02 +0000
Message-ID: <55940D15.7000102@juniper.net>
Date: Wed, 01 Jul 2015 11:53:57 -0400
From: Eric C Rosen <erosen@juniper.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Loa Andersson <loa@pi.nu>, "mpls@ietf.org" <mpls@ietf.org>, "draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org" <draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org>
References: <55828B69.3070603@pi.nu> <55880C91.507@juniper.net> <559129C8.7000407@cs.tcd.ie> <559196F1.90006@juniper.net> <5591BE65.3080409@cs.tcd.ie>
In-Reply-To: <5591BE65.3080409@cs.tcd.ie>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [66.129.241.14]
X-ClientProxiedBy: BLUPR0401CA0030.namprd04.prod.outlook.com (25.162.114.168) To BY1PR0501MB1096.namprd05.prod.outlook.com (25.160.103.142)
X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1096; 2:8gpamSNrCZgZQs7y9gVvHIseUUd4AKb2it9OKep3tSF2grrGBZ1LWJkubqvTz+6J; 3:Skh4Tg7bQyY4Etwo/ZzSpAQOmjkafBP0/aBwTzxVajWwCYThUFQRUM6KmbBRJ7UfqWaHjR5/k2Ns3NXzn/bAqMeNyiD3pEIY8RYd6RTL9SvvobCBwALhoq2JkDMMuWohuNkuP133Qtb50eInGh0WBw==; 25:E2V7u9egWw0oh9mBwewwnISBXJkIaelhSRfjhNDLgjV97YAJC6dhxn9bFkK+i00xR3LZRzJ1kxOKkbcvHCylJPLU7osM7H0OPYlmbpWIYRzynzpfP7L8kqMF5y6uMZD4T1MavRl9+JyMQqYGF0wiKix4/z1+8JOfgXE1VDmrDY+tqxh0x4juE8dE6kUJk1fq39KOTD8fJ4qG+Iov1bXYFsNN/yKycRz5Mo2ndUEC29oL5UlkOdIxdoJJP3fAEG28e1Urxw4wde3Lr1eCVIs3Vw==
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1096;
X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1096; 20:d1YF6W8YCu8y6p8kAMbIguxPeTE3MUzcCDFaNQFo7bRiflnvel6JY/KGY+K61aVmBKtCqUp67g9mEVIPzJGZQZSzVs9vRLY4oRBMOXZpa+QKtWjkYLjOhH6hIA/7P9VM0bajuIeS9/+hMyCL2VXYYXSjcF6lz5mY0gz0kIXcb9nyA+QQdLkUd8UhsglQnRA1ocJx0BQ/XsSDTa4ZODbczrVP7jICiH5Lh15tMQ8xbbgD+M5sT+9FPRt31RZ7Xp3RjE0wm5pqtzzjOLguwYvzWwiNCoJrfC9gxUfmsoHP+FYpWEMng2VMc085tLTqBTr++JqIXlrcgTGEykYGVWhltt1+qUmCvjXBJrJRT7lrzkHVBUs1JQQkImHgFD3fNC1ve5QMIrFKf+B1+J/5zNHY2UHZp/vUxJ9yUkx64Rb5UA54aI0iTir0qVbuvHKp6zHOMfxHfxPT8FGmwQBdrhWNlMT/WjJxHPjP0J6m5tVgddOL6n6ba3113NpPwxVEGf0X; 4:qMxpU/JKRnDTBVpjOrbgWKVSsxw/Iy/kVwp+4KJhkXB2Tghl+GAVuvIwMERKbqW/g1B3jD1MkcARFMc1BNAlGaMFamRF2gvfDFWbMlEgBp+kC2A9kdNMonhODHVL5TfXtUwAPue0E9PxMeJNH6PcngtAJrY2/c/2PrltlhlVNR+/Gd7umBxHNnaVMEA9YM+iXE9om1E5XteRQg6ymPIqZWt45/0tW9lqhBSlD934PrkYuwPmV7nZNCqHZ7FatzRnuGMuX/mACvWD3HJRFvkuRM4mb+PTQXSYLbOv67M1MF4=
X-Microsoft-Antispam-PRVS: <BY1PR0501MB10966C8799F23BB6DF760F0DD4A80@BY1PR0501MB1096.namprd05.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BY1PR0501MB1096; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1096;
X-Forefront-PRVS: 0624A2429E
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(24454002)(377454003)(479174004)(50986999)(76176999)(65806001)(4001350100001)(65956001)(5001920100001)(47776003)(92566002)(64126003)(86362001)(42186005)(2201001)(93886004)(54356999)(65816999)(50466002)(23676002)(36756003)(99136001)(2950100001)(87266999)(83506001)(66066001)(40100003)(62966003)(33656002)(77096005)(77156002)(46102003)(5001960100002)(122386002)(189998001)(5001770100001)(230783001)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1096; H:[172.29.32.51]; FPR:; SPF:None; MLV:sfv; LANG:en;
X-Microsoft-Exchange-Diagnostics: 1;BY1PR0501MB1096;23:tT7g9LRCa+56kdnMHmHHya/EI33j0JKQQLbUvJeD9V+y4BjruhqqMagQAcgOnhkkxdyxm9BPoIev8fOWvZ50TTZdNzY6cEUk5odPEvF7OtJsOC6tw0qpBOCQF6VG2cI3EBso4s4YW4+7BndUHfIR7fb8ue6Ewct5TCC1FLwBfuKxvMMOA3nXXlD6d1j3ytE0nm6rbQgrw7CYgpOsJrZbtYjVzSmhYSTy+OMt4SylpFjDGyIh1naMzjeuXAzKetIVq9DspvBhP1qYagupHcjIQGyuZhKbZoUW/uYES0xmMc2k3ShB1Avt6Fu3u/9E+FJSK2ipJo8ujNTWYoiBCkbIcs/9N1/ZF4e6djuDJUn/lsH8uFdd5Nv6Fhd3vsDn3a/A5eLI9WxHh8Y8KHCDZVgO1ZnhBLIQvqbgidP6xq4zTnMn6tUE+8gNVY6wKJcbrsGUOl2hMNIMK50MEl/DHVJT3d99XE8HyzYDuEmyFXMrBwjk/hhg4F1XqfUlYJzX4jZlmyDAXyI3qdCoFsvWX9MmEwktkQPhUBgAUgYKGdHqwCfAiy39mIFML5YNZhNVH9fFn+z3OULhOWQMlXo0dSaXNnR/MMTXJkSQe/nYyMHBLXmpcS5dhHNn0PMuRKSTB7KTUnfgFHC7zLeRbkhIxfZfYd+QwZV3dMz7xpYsvWIaRD5258CgkRvW3Asc0fmhM+nI0SwTWYGpqSo0Bg6Jo7ARlHIXKvGBqw5gV1EUyTgNqCEsg1PGP1bhUAY+v0UcUN0juaqrLJK5Qa1XmpfoBvDfvd13Wao5ja1h5akLK7NpCJNNRcxOottdNAX8XJKDctWeBjQW5xCCkL8ofzLH7hXiyqwz1F1CHw5DnYfI7iDZ2aj7QyY2rSFhYg9P13zCJEduJUtQVhnF2nn2bU1bO2urkOvn1Qb/e7F/TdC1pDhu4KvUEwVMuLJ8CMjA/0GlyYSvJaXJ/ux4KEmiGOg4yMxO1jusgoJCE3F3rPqYrqqeg9nfLAbube2sNQAm8CXDYB05Yif/XGgaU8tiUwrkF4H+4lkuW4oFqVLolNWMqTz53e4=
X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1096; 5:oFs4/B9TRsUZgBLciV/VxCMyj2APWeOKYf0AKP5kr8YUD1JTKtDMV8ybK18zMdonHs5emreB1+zOyzIhfxZANVzcJlVz/p6P2LNuzv0kCTNc8b3fxGEOCKUL+sXlAGjY50ZAt+r523pfm9ZKINgrnA==; 24:/fHH99n4ii7TbS3X6RF/wAvpRqxoQIggQm8eA6PI4da+/fpb9IdJU3RPjWNxv20Z7Qnmab3uQcg+FxJaaHHKiDVT+38C1/xTuquxBemUfk0=; 20:KRbsaQh70jR4Ufzo+9NDTX5T9/bXJGR2sjFZIXqwrTloVTdWWOUtNzaHw65Nke9LG6jLhwtVbdISu8Uf3TNrnQ==
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jul 2015 15:54:02.4775 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1096
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/RlReF0juXJS5d7jBsD3IHqXIv_w>
Cc: "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>
Subject: Re: [mpls] Poll to see if we have consensus to adopt draft-farrelll-mpls-opportunistic-encrypt as an MPLS wg document
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 01 Jul 2015 15:54:07 -0000

On 6/29/2015 5:53 PM, Stephen Farrell wrote:

> [Stephen] I'm not clear how one could avoid some state per LSP ...
> without getting into multiparty key management.

I think Adrian answered that question quite well -- a key known to only
two PEs could cover all the LSPs running between those two PEs.  I 
understand that there's a certain elegance about having a key per LSP 
and a nonce per LSP, but IMHO the practicality is questionable.

However, if Adrian is right about the use case:

> [Adrian] the desired applicability is for virtual links that span
> multiple hops in an MPLS network ..., and that OS would be enabled in
> a somewhat ad hoc manner on key LSPs but not all of them.

If the use case is to just protect a few key P2P LSPs, per-LSP state 
might not be that big a problem.  If that's the use case, the draft 
should really make it clear that the proposed procedures do not apply to 
MPLS generally and do not scale to large numbers of LSPs.

> [Stephen] state per LSP (is that the same as per-label?)

A label is the representation in the forwarding plane of an LSP, and 
generally each distinct label represents a distinct LSP.  One can think 
of an LSP as a sequence of routers leading from ingress to egress, with 
a label representing that LSP at each router as each router other than 
the ingress.  It's possible to omit the label at the egress 
("penultimate hop popping"), but  presumably this would be prohibited 
when OS is applied.

> [Stephen] Bear in mind that we are not saying that
> there's anything wrong with layer 2 security here, but claiming
> that it's that much simpler isn't convincing.

Here is why I think layer 2 security is simpler:

- If you use layer 2 security, no changes to MPLS are required at all. 
That seems much simpler than using a scheme that does require changes.

- One security relationship between a pair of neighboring routers covers 
all data sent between those routers; this is much less state than is 
required for per-LSP security.  It also provides much more complete 
coverage, not limited to MPLS.  Less state, more coverage, seems simpler 
to me.

So I don't see why link layer encryption would not be preferable to MPLS 
hop-by-hop encryption in all cases.

Coming back to the issue of whether the WG should adopt the draft, I 
don't see any advantage in doing so.  This really seems to be a research 
topic, and it's not clear that this is really the right direction.  If 
it is adopted, we'll start to hear things from the IESG like "the MPLS 
WG has a consensus that this is the right approach", which will be 
followed quickly by a demand from the Security ADs that this become 
"mandatory to implement".  (This last remark is based on my experience 
with several generations of Security AD, and is not aimed at any 
particular person.)

BTW, failure to adopt the document doesn't mean that we don't think 
security is important.

It would certainly be interesting to hear from operators whether they 
think there really is a need for "opportunistic" security as opposed to 
PKI-based security, especially given the way that some of the evolving 
BGP security schemes seem to be relying on PKI-based techniques.  It 
would also be interesting to hear whether scalability is unimportant, 
because the solution only needs to be applied to small number of LSPs.