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.
- [mpls] Poll to see if we have consensus to adopt … Loa Andersson
- Re: [mpls] Poll to see if we have consensus to ad… Alexander Vainshtein
- Re: [mpls] Poll to see if we have consensus to ad… Adrian Farrel
- Re: [mpls] Poll to see if we have consensus to ad… Andrew G. Malis
- Re: [mpls] Poll to see if we have consensus to ad… Stephen Farrell
- Re: [mpls] Poll to see if we have consensus to ad… Gregory Mirsky
- Re: [mpls] Poll to see if we have consensus to ad… Eric C Rosen
- Re: [mpls] Poll to see if we have consensus to ad… Stephen Farrell
- Re: [mpls] Poll to see if we have consensus to ad… Eric C Rosen
- Re: [mpls] Poll to see if we have consensus to ad… Stephen Farrell
- Re: [mpls] Poll to see if we have consensus to ad… Adrian Farrel
- Re: [mpls] Poll to see if we have consensus to ad… Eric C Rosen
- Re: [mpls] Poll to see if we have consensus to ad… Stephen Farrell
- Re: [mpls] Poll to see if we have consensus to ad… Loa Andersson