Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04
John E Drake <jdrake@juniper.net> Thu, 25 May 2017 18:10 UTC
Return-Path: <jdrake@juniper.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5251B1294A3; Thu, 25 May 2017 11:10:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net
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 ScnspsyphnoA; Thu, 25 May 2017 11:10:13 -0700 (PDT)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0121.outbound.protection.outlook.com [104.47.34.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB7D8127B73; Thu, 25 May 2017 11:10:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=64a+0SyKWK6ggMuXeZSSV0pbkaN3aMxOaKVbUL4xtxU=; b=QsIhErRCk+EEeQMo1EmP3nQRBDiLOs2/fY1vUHG+eyeVpolic9aegcb0I7boVU7+B5qKjlQmxKIU+Ltu7IWOXqDC6xRopqdw8Bp0Dyy5auwVvvyYCV72FjtRXJIotS/HnFj5TRpn7JlIjcYUFPnGwRK0u2tblELMdTpzwncnX9g=
Received: from CO2PR05MB618.namprd05.prod.outlook.com (10.141.198.146) by CO2PR05MB2503.namprd05.prod.outlook.com (10.166.95.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1124.5; Thu, 25 May 2017 18:10:12 +0000
Received: from CO2PR05MB618.namprd05.prod.outlook.com ([10.141.198.146]) by CO2PR05MB618.namprd05.prod.outlook.com ([10.141.198.146]) with mapi id 15.01.1124.007; Thu, 25 May 2017 18:10:11 +0000
From: John E Drake <jdrake@juniper.net>
To: Eric Rosen <erosen@juniper.net>, Lou Berger <lberger@labn.net>, John Scudder <jgs@juniper.net>
CC: "idr@ietf.org" <idr@ietf.org>, "draft-ietf-idr-tunnel-encaps@ietf.org" <draft-ietf-idr-tunnel-encaps@ietf.org>
Thread-Topic: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04
Thread-Index: AQHS0aHtgmiwFo/ZwE+Npslhnc8W56H/NfeAgAE8coCAAW8jgIAAJvWAgAASgACAA0GEAIAAAiaA
Date: Thu, 25 May 2017 18:10:11 +0000
Message-ID: <CO2PR05MB618B4D4BC607325D25D29C0C7FF0@CO2PR05MB618.namprd05.prod.outlook.com>
References: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> <213015a0-eb5f-3f17-f5f0-3aa864304a6d@labn.net> <c735e3fe-1b0e-23a6-78bf-7e773e605a52@juniper.net> <9a3866bf-a561-df26-38e9-aff3cc4f2eeb@labn.net> <5ec5e327-5872-2754-4543-19e3b3465a1c@juniper.net> <17d44a51-b48b-1541-afb4-9b3878436b47@labn.net> <4466bd05-0362-b4be-ecf8-5881e228722d@juniper.net>
In-Reply-To: <4466bd05-0362-b4be-ecf8-5881e228722d@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CO2PR05MB2503; 7:gMtJ0Fk7q+76R8RgP6BOP/TfHxVFlphBu8drspqzSwDfcn7CV5yAJ2+ZI/3BXIE7VfZvPABnaOsjc4/ZEqp+bYuB7bVAOz0fAyF9+HIxgcxK8YtW2rb3uuJQ05Pl1PMMFDy/szPzVYFu8py5z/mHnj8KL6bjNvtOfULQ26u2Ys7guRDTZWneX8mWVY03+nc4Y/sEZj0bcYZkF+t9zaLRprUsG1hOasNLZGZZQXr+EyQaAfx+JTty5s2sASa4SwGDEzOeJmNX7UcwOcb6W3sm92KIhhCl8Q+XJaNBxfjFpXWqT5kF5jH6seRqf2NHKsI7zEvpRSNPpYZlRobI7T2lDg==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39860400002)(39850400002)(39400400002)(39450400003)(39840400002)(377454003)(24454002)(93886004)(7736002)(38730400002)(54906002)(55016002)(50986999)(99286003)(54356999)(790700001)(76176999)(54896002)(102836003)(6306002)(3846002)(86362001)(2950100002)(74316002)(6246003)(77096006)(6636002)(6506006)(9686003)(53936002)(230783001)(5660300001)(66066001)(3660700001)(81166006)(8676002)(7696004)(3280700002)(33656002)(53546009)(25786009)(2906002)(189998001)(8936002)(4326008)(9326002)(2900100001)(478600001)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2503; H:CO2PR05MB618.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
x-ms-traffictypediagnostic: CO2PR05MB2503:
x-ms-office365-filtering-correlation-id: a5d47467-c1c6-4e48-39f3-08d4a39948e6
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:CO2PR05MB2503;
x-microsoft-antispam-prvs: <CO2PR05MB250366FB01154A0474D504F7C7FF0@CO2PR05MB2503.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(192374486261705)(138986009662008)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(6072148); SRVR:CO2PR05MB2503; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB2503;
x-forefront-prvs: 0318501FAE
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CO2PR05MB618B4D4BC607325D25D29C0C7FF0CO2PR05MB618namprd_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 May 2017 18:10:11.2891 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2503
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/jAhRFjDaOURT6SNuNNJjOuqnR8k>
Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 May 2017 18:10:16 -0000
Hi, Is it really the responsibility of a RFC which obsoletes a another RFC to explain how every RFC referencing the obsoleted RFC is to be updated? I think it's a much better idea to update each of these RFCs individually. So, as Eric suggests, I think an update to RFC 5566 is in order. Yours Irrespectively, John From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Eric C Rosen Sent: Thursday, May 25, 2017 1:54 PM To: Lou Berger <lberger@labn.net>; John Scudder <jgs@juniper.net> Cc: idr@ietf.org; draft-ietf-idr-tunnel-encaps@ietf.org Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04 On 5/23/2017 12:10 PM, Lou Berger wrote: RFC 5566 assumes that the IPsec tunnel info and the authenticator sub-TLV is conveyed on an update of the encapsulation SAFI. I'm not convinced that there are no addtional security issues to be considered if this information is carried on updates of other address families. I think the assumption is that the sub-TLVs are conveyed with the attribute. I don't see how changing the SAFI impacts this. I'm not saying that it does or does not, just that I'm not sure, and I'm not prepared now to defend a claim that the security aspects are not altered by this change. So I'd rather see that addressed in a different document. Also, note that in RFC 5512, the tunnels only extend to the BGP next hop, while in the tunnel-encaps draft the tunnel endpoints are not necessarily the BGP next hop. This might also change some of the security properties. I think this would have to be thought out fairly thoroughly, and I don't think that work's been done yet. So leaving 5566 as is introduces this issue already (due to the introduction of the remote endpoint sub-tlv). If the we deprecate 5566 with this document, this can be trivially addressed by saying that the endpoint Authenticator sub-tlv applies to the endpoint identified in the Remote Endpoint Sub-TLV. I'm also not prepared to defend a claim that this is has no signficant impact to the security characteristics. Since the existing contents of the document do not depend upon anything in RFC 5566, I think obsoleting and replacing RFC 5566 is better done in a separate document . I don't see how it could be correct for an implementation to always include an Encapsulation EC. Sometimes you need to specify more than the tunnel type in order to construct the encapsulation properly. It doesn't "hurt" to include it always and there is an implementation that does this, so why not allow it? It seems to me that it does hurt to include it. If the intended tunnel endpoint is not the BGP next hop, or if the tunnel will not work unless the encapulation is prepared as specified within the attribute, then including an encapsulation EC for the same tunnel type provides false information. The use of multiple tunnels between a pair of endpoints seems to make sense, especially if the tunnels have different characteristics, and if color can be used to map particular traffic flows to particular tunnels. This is something that has not changed from RFC 5512. Note also that even the Encapsulation EC allows multiple tunnels to be specifiied (if they are of different types), since an EC attribute can contain multiple instances of the same extended community. I'm not arguing it that it's not a real use case, but rather that it can be solved using other existing, albeit more verbose, mechanisms. Allowing a choice of tunnels between a pair of endpoints should not require the origination of multiple routes with different NLRIs, or (even worse) the use of add-paths. I don't really see the merit of this suggestion. If you receive two routes, and want to aggregate them so that you only need to propagate one upstream, and the two routes have different tunnel-encaps attributes, you need some policy to decide what to do. But that's true even if the tunnel-encaps attribute only specifies one tunnel. Sure, and the policy may be to merge the tlv lists. This is the kind of information I'm suggesting should be added. I think such policies will be very application-specific, and thus are out of scope of this document. A draft proposing the use of the tunnel encaps attribute for a particular purpose might well have to deal with these policy issues.
- [Idr] Working group last call for draft-ietf-idr-… John G. Scudder
- Re: [Idr] Working group last call for draft-ietf-… Job Snijders
- Re: [Idr] Working group last call for draft-ietf-… John G. Scudder
- Re: [Idr] Working group last call for draft-ietf-… Lou Berger
- Re: [Idr] Working group last call for draft-ietf-… Eric C Rosen
- Re: [Idr] Working group last call for draft-ietf-… Eric C Rosen
- Re: [Idr] Working group last call for draft-ietf-… Keyur Patel
- Re: [Idr] Working group last call for draft-ietf-… guntervandeveldecc
- Re: [Idr] Working group last call for draft-ietf-… Lou Berger
- Re: [Idr] Working group last call for draft-ietf-… Eric C Rosen
- Re: [Idr] Working group last call for draft-ietf-… Lou Berger
- [Idr] 答复: Working group last call for draft-ietf-… Xuxiaohu
- Re: [Idr] Working group last call for draft-ietf-… Job Snijders
- Re: [Idr] Working group last call for draft-ietf-… Eric C Rosen
- Re: [Idr] Working group last call for draft-ietf-… John E Drake
- Re: [Idr] Working group last call for draft-ietf-… Lou Berger
- Re: [Idr] Working group last call for draft-ietf-… Lou Berger
- Re: [Idr] Working group last call for draft-ietf-… Randy Bush
- Re: [Idr] Working group last call for draft-ietf-… Acee Lindem (acee)
- Re: [Idr] Working group last call for draft-ietf-… Eric C Rosen
- Re: [Idr] Working group last call for draft-ietf-… Job Snijders
- Re: [Idr] Working group last call for draft-ietf-… Acee Lindem (acee)
- Re: [Idr] Working group last call for draft-ietf-… Eric C Rosen
- Re: [Idr] Working group last call for draft-ietf-… Lou Berger
- Re: [Idr] 答复: Working group last call for draft-i… Eric C Rosen
- Re: [Idr] Working group last call for draft-ietf-… John E Drake
- Re: [Idr] Working group last call for draft-ietf-… Stefano Previdi (sprevidi)
- Re: [Idr] Working group last call for draft-ietf-… John G. Scudder
- Re: [Idr] Working group last call for draft-ietf-… Acee Lindem (acee)
- Re: [Idr] Working group last call for draft-ietf-… John Scudder
- Re: [Idr] Working group last call for draft-ietf-… John G. Scudder
- Re: [Idr] Working group last call for draft-ietf-… Eric C Rosen
- Re: [Idr] Working group last call for draft-ietf-… John G. Scudder
- Re: [Idr] Working group last call for draft-ietf-… Acee Lindem (acee)
- Re: [Idr] Working group last call for draft-ietf-… bruno.decraene
- Re: [Idr] Working group last call for draft-ietf-… bruno.decraene
- Re: [Idr] Working group last call for draft-ietf-… Eric C Rosen
- Re: [Idr] Working group last call for draft-ietf-… bruno.decraene
- Re: [Idr] Working group last call for draft-ietf-… bruno.decraene
- Re: [Idr] Working group last call for draft-ietf-… Eric C Rosen