Re: [Idr] recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-12
John Scudder <jgs@juniper.net> Tue, 11 June 2019 14:37 UTC
Return-Path: <jgs@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 DD10912016D; Tue, 11 Jun 2019 07:37:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.709
X-Spam-Level:
X-Spam-Status: No, score=-2.709 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_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 iHFHfOo9_sn7; Tue, 11 Jun 2019 07:37:51 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 7D0B6120180; Tue, 11 Jun 2019 07:37:40 -0700 (PDT)
Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x5BETX2C003207; Tue, 11 Jun 2019 07:37:32 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=nrsUtx6xrW8qYGI0CfKKm1DI5f/d3n9qb4hrzGaePS8=; b=su9XC/81+jrjhsWbO9lm71ua58ui8nu0dMB5JcOslvLKzW9l1zoMQ2NeNfJuB2LGh+PG v80/j9UCMiaenn5JZJqrrnqN9Hq8BPltInYdDCuCj8MTQyQH2cjo7GcGsyEWqkFl5iab sNr50zULpCM9t77dPOAb0QhblX+87x8vivwgN+c3o9gvhWAuPF3DGc6lnxZcEqBicInF LgzxonMJj3O9XU/1lTfTMXiYLig8aCh4/WPigI6L8p9o5rZDwyvOChC+bOBKKWfH3z+G nFVxsbkzZK+phS2abi+QmZtUF+QluBEdpyCuU7jeYvXG+tKhf6i05aRAiFa/MR6NQgjn 9g==
Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp2056.outbound.protection.outlook.com [104.47.36.56]) by mx0b-00273201.pphosted.com with ESMTP id 2t2a67ge1p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 11 Jun 2019 07:37:31 -0700
Received: from DM6PR05MB4714.namprd05.prod.outlook.com (20.176.109.215) by DM6PR05MB6268.namprd05.prod.outlook.com (20.178.198.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.11; Tue, 11 Jun 2019 14:37:28 +0000
Received: from DM6PR05MB4714.namprd05.prod.outlook.com ([fe80::1549:ffd0:8373:4593]) by DM6PR05MB4714.namprd05.prod.outlook.com ([fe80::1549:ffd0:8373:4593%3]) with mapi id 15.20.1987.008; Tue, 11 Jun 2019 14:37:28 +0000
From: John Scudder <jgs@juniper.net>
To: Linda Dunbar <ldunbar@futurewei.com>
CC: Keyur Patel <keyur@arrcus.com>, "draft-ietf-idr-tunnel-encaps@ietf.org" <draft-ietf-idr-tunnel-encaps@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-12
Thread-Index: AdUfzDTwk+JWx4NrTbCw24feqIEcxQADfhQAAAsC6QAAFz36gA==
Date: Tue, 11 Jun 2019 14:37:27 +0000
Message-ID: <4A52E5E6-B226-4626-94BB-8A4A5379A0C2@juniper.net>
References: <MN2PR13MB358247036D97F6620E2CB987A9130@MN2PR13MB3582.namprd13.prod.outlook.com> <234E41A5-F754-4630-B73C-8A9D52E44198@juniper.net> <MN2PR13MB3582D2ECC20AB6F5B3F1ABC8A9ED0@MN2PR13MB3582.namprd13.prod.outlook.com>
In-Reply-To: <MN2PR13MB3582D2ECC20AB6F5B3F1ABC8A9ED0@MN2PR13MB3582.namprd13.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [162.225.191.79]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: cecfdd4d-5009-46a2-21a5-08d6ee7a53eb
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:DM6PR05MB6268;
x-ms-traffictypediagnostic: DM6PR05MB6268:
x-microsoft-antispam-prvs: <DM6PR05MB626828CD2065936A35E6195FAAED0@DM6PR05MB6268.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 006546F32A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(136003)(39860400002)(366004)(376002)(189003)(199004)(26005)(102836004)(5660300002)(186003)(25786009)(53546011)(54906003)(6506007)(68736007)(76116006)(229853002)(7736002)(91956017)(76176011)(6116002)(14444005)(5024004)(71190400001)(71200400001)(83716004)(82746002)(4326008)(316002)(66066001)(256004)(3846002)(99286004)(2906002)(478600001)(236005)(6916009)(6486002)(6246003)(54896002)(6512007)(14454004)(66946007)(66476007)(33656002)(66446008)(36756003)(64756008)(73956011)(6436002)(66556008)(2616005)(446003)(11346002)(86362001)(53936002)(66574012)(81166006)(8936002)(476003)(486006)(8676002)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB6268; H:DM6PR05MB4714.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: fl0Xek6Uzm6C6s+cgBatJtpU1bNC7soK6Evy4oTdU1u5Os4KTRb6/uID6b8pHZie1kh5+z/HNacbGT8YgykkIL9WpMfP8jASB7Zp8cLza8s0i1xCHIyzKWJaKkPPllQdwePVlIlhQntscDDmjO8lbsur3a1L/f5n5nx5Ezvm7QIzZA2WAIsoaycGd5uIcIM9Mp4RblReJDPd7iO9eZtpErg9DRBndNJf5btSEhdKq6RrcoYSENzPcPn6DDP3DON57kD7Rjp1BGWNQ9Uli1dKLxmasvSL2N9Ukmx4cU8dracUz90IUqPsvsjmtJqNEGsGH1BqSSnTYY8CuHYgRoE6n2StXmp2eQV9DPtg335MxplTWgnmYhd/byoHD0tEWR5PTavKgcw4+hizZMDZVly1Wnx62D0khWIt9YtL6XVSgco=
Content-Type: multipart/alternative; boundary="_000_4A52E5E6B226462694BB8A4A5379A0C2junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: cecfdd4d-5009-46a2-21a5-08d6ee7a53eb
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2019 14:37:27.9503 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: jgs@juniper.net
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB6268
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-11_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906110096
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/9slY2x1s_EcFp7sqICCbf5DTHqY>
Subject: Re: [Idr] recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-12
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 11 Jun 2019 14:37:54 -0000
(Still as a WG contributor!) On Jun 10, 2019, at 11:41 PM, Linda Dunbar <ldunbar@futurewei.com<mailto:ldunbar@futurewei.com>> wrote: John, You raised a good point. In RFC5512, the BGP speaker indicates the originating Interface address in the NLRI. I would imagine the receiver can validate the information. But if you are concerned about a “malicious entity” why wouldn’t that entity just falsify the originating interface address in the NLRI? So how much genuine security does the validation provide? the draft-ietf-idr-tunnel-encaps-12 doesn’t have the information, is it correct? I believe so (though I would like one of the authors to confirm). —John Linda From: John Scudder <jgs@juniper.net<mailto:jgs@juniper.net>> Sent: Monday, June 10, 2019 5:17 PM To: Linda Dunbar <ldunbar@futurewei.com<mailto:ldunbar@futurewei.com>> Cc: Keyur Patel <keyur@arrcus.com<mailto:keyur@arrcus.com>>; draft-ietf-idr-tunnel-encaps@ietf.org<mailto:draft-ietf-idr-tunnel-encaps@ietf.org>; idr@ietf.org<mailto:idr@ietf.org> Subject: Re: recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-12 (As a WG contributor) Hi Linda, I have a question for you — when you say RFC5512 doesn’t allow a third party to inject routes on behalf of a legitimate router, what do you think would prevent it? You mention the endpoint address in the NLRI, but what would prevent the malicious entity you mention for falsifying it? Thanks, —John On Jun 10, 2019, at 4:47 PM, Linda Dunbar <ldunbar@futurewei.com<mailto:ldunbar@futurewei.com>> wrote: Keyur, Thank for the email. One more question: * Does the “Remote Endpoint” in draft-ietf-idr-tunnel-encaps-12 represent the BGP speaker that originates the update? Or the remote end point that the “Tunnel” is established to? * I have been told two different versions of the answers. I need confirmation from the authors. Reading through the Section 13 Security Consideration, I don’t think the following questions have been addressed: 1. In RFC5512, the BGP speaker indicates the originating Interface address in the NLRI (section 3): <image001.png> Questions: * draft-ietf-idr-tunnel-encaps-12 no longer has the BGP speaker originating the update. Is it intended? If Yes, does it mean that it allows a third party (which could be malicious entity) to inject routes on behalf of a legitimate router (but RFC5512 doesn’t)? * Why add this scenario? If it is a conscious decision, should have some text to explain why and how to mitigate the security threats introduced. * Section 13 suggests using BGP Origin Validation to obtain the additional assurances of the origin AS is valid. But being valid origin AS doesn’t mean the specific flow is supposed to go/come from there. #Keyur: Section 13 of the draft version 12 describes Security Considerations that should address your security questions. The option is to provide flexibility. Thank you, Linda Dunbar From: Keyur Patel <keyur@arrcus.com<mailto:keyur@arrcus.com>> Sent: Saturday, June 08, 2019 3:45 AM To: Linda Dunbar <ldunbar@futurewei.com<mailto:ldunbar@futurewei.com>>; draft-ietf-idr-tunnel-encaps@ietf.org<mailto:draft-ietf-idr-tunnel-encaps@ietf.org>; idr@ietf.org<mailto:idr@ietf.org> Cc: John Scudder <jgs@juniper.net<mailto:jgs@juniper.net>> Subject: Re: recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-11 Hi Linda, Apologies for the delayed response. Responses are inline. #Keyur From: Linda Dunbar <linda.dunbar@huawei.com<mailto:linda.dunbar@huawei.com>> Date: Thursday, March 28, 2019 at 6:52 AM To: idr wg <idr@ietf.org<mailto:idr@ietf.org>>, "draft-ietf-idr-tunnel-encaps@ietf.org<mailto:draft-ietf-idr-tunnel-encaps@ietf.org>" <draft-ietf-idr-tunnel-encaps@ietf.org<mailto:draft-ietf-idr-tunnel-encaps@ietf.org>> Subject: recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-11 Resent-From: <keyur@arrcus.com<mailto:keyur@arrcus.com>> Resent-To: <erosen52@gmail.com<mailto:erosen52@gmail.com>>, <keyur@arrcus.com<mailto:keyur@arrcus.com>>, <gunter.van_de_velde@nokia.com<mailto:gunter.van_de_velde@nokia.com>> Resent-Date: Thursday, March 28, 2019 at 6:52 AM Just want to reiterate my questions and issues I raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-11, to make it easier for the authors to address them in the next revision (I have sent the questions multiple times on the IDR mailing list, but no one responded): 1. When a client route can egress multiple egress ports (each with different IP addresses), does the Tunnel-Encap allow multiple “Remote-endpoint” SubTLV to be attached one UPDATE? #Keyur: Yes. Section 5 of the draft version 12 has a following text: <snip> A Tunnel Encapsulation attribute may contain several TLVs that all specify the same tunnel type. Each TLV should be considered as specifying a different tunnel. Two tunnels of the same type may have different Remote Endpoint sub-TLVs, different Encapsulation sub-TLVs, etc. Choosing between two such tunnels is a matter of local policy. </snip> 1. Section 3.1 Page 10: The last paragraph states that if “Remote-Endpoint sub-TLV contains address is valid but not reachable, and the containing TLV is NOT be malformed ..”. Why a address not reachable is considered as “Not Malformed”? #Keyur: That is because the Remote-Endpoint could become reachable at the later time. Making it malformed would mean that the Remote-Endpoint has to be dropped upon a receipt of the update message (and could never be used). 1. In RFC5512, the BGP speaker indicates the originating Interface address in the NLRI (section 3): <image001.png> draft-ietf-idr-tunnel-encaps-11 no longer has the BGP speaker originating the update. Is it intended? If Yes, does it mean that it allows a third party (which could be malicious entity) to inject routes on behalf of a legitimate router (but RFC5512 doesn’t)? Why add this scenario? How to address the security threats introduced? If it is a conscious decision, should have some text to explain why and how to mitigate the security threats introduced. #Keyur: Section 13 of the draft version 12 describes Security Considerations that should address your security questions. The option is to provide flexibility. Regards, Keyur Thanks, Linda Dunbar
- Re: [Idr] recap my questions and issues raised du… Linda Dunbar
- Re: [Idr] recap my questions and issues raised du… John Scudder
- Re: [Idr] recap my questions and issues raised du… John Scudder
- Re: [Idr] recap my questions and issues raised du… Linda Dunbar
- Re: [Idr] recap my questions and issues raised du… John Scudder
- Re: [Idr] recap my questions and issues raised du… Linda Dunbar
- Re: [Idr] recap my questions and issues raised du… John Scudder
- Re: [Idr] recap my questions and issues raised du… Linda Dunbar
- Re: [Idr] recap my questions and issues raised du… John Scudder
- Re: [Idr] recap my questions and issues raised du… Keyur Patel
- Re: [Idr] recap my questions and issues raised du… Keyur Patel
- Re: [Idr] recap my questions and issues raised du… Keyur Patel
- Re: [Idr] recap my questions and issues raised du… Robert Raszuk
- Re: [Idr] recap my questions and issues raised du… John Scudder
- Re: [Idr] recap my questions and issues raised du… Linda Dunbar
- Re: [Idr] recap my questions and issues raised du… Keyur Patel
- Re: [Idr] recap my questions and issues raised du… Robert Raszuk
- Re: [Idr] recap my questions and issues raised du… Linda Dunbar
- Re: [Idr] recap my questions and issues raised du… Keyur Patel
- Re: [Idr] recap my questions and issues raised du… Keyur Patel
- Re: [Idr] recap my questions and issues raised du… Keyur Patel
- Re: [Idr] recap my questions and issues raised du… John Scudder
- Re: [Idr] recap my questions and issues raised du… Srihari Sangli
- Re: [Idr] recap my questions and issues raised du… Keyur Patel
- Re: [Idr] recap my questions and issues raised du… Acee Lindem (acee)
- Re: [Idr] recap my questions and issues raised du… 徐小虎(义先)
- Re: [Idr] recap my questions and issues raised du… Dongjie (Jimmy)
- Re: [Idr] recap my questions and issues raised du… Keyur Patel
- Re: [Idr] recap my questions and issues raised du… Linda Dunbar
- Re: [Idr] recap my questions and issues raised du… Susan Hares
- Re: [Idr] recap my questions and issues raised du… Ali Sajassi (sajassi)
- Re: [Idr] recap my questions and issues raised du… Ali Sajassi (sajassi)
- Re: [Idr] recap my questions and issues raised du… John Scudder
- Re: [Idr] recap my questions and issues raised du… Acee Lindem (acee)