IETF Logo Mail Archive

[Idr] Preventing BGP Route leak (Hijack) for Management Channel BGP session

Linda Dunbar <linda.dunbar@huawei.com> Mon, 13 August 2018 19:27 UTC

Return-Path: <linda.dunbar@huawei.com>
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 0670B130FB5; Mon, 13 Aug 2018 12:27:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 WYwGoqm4eWOr; Mon, 13 Aug 2018 12:27:06 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 718D0130E31; Mon, 13 Aug 2018 12:27:06 -0700 (PDT)
Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 24746B2A2FB5D; Mon, 13 Aug 2018 20:27:01 +0100 (IST)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.399.0; Mon, 13 Aug 2018 20:27:02 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.107]) by SJCEML701-CHM.china.huawei.com ([169.254.3.34]) with mapi id 14.03.0399.000; Mon, 13 Aug 2018 12:26:57 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: "shares@ndzh.com" <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>, Jeff Tantsura <jefftant.ietf@gmail.com>, RTGWG <rtgwg@ietf.org>
Thread-Topic: Preventing BGP Route leak (Hijack) for Management Channel BGP session
Thread-Index: AdQzO4r0PzSwhpZvSCmMNMmO/EiBoA==
Date: Mon, 13 Aug 2018 19:26:56 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66B0DAE87@sjceml521-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.192.11.118]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F66B0DAE87sjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/iuvFnHjS1JK0FjK6r70Bvzfe7mM>
Subject: [Idr] Preventing BGP Route leak (Hijack) for Management Channel BGP session
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.27
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: Mon, 13 Aug 2018 19:27:08 -0000

One of the comments to https://datatracker.ietf.org/doc/draft-dm-net2cloud-gap-analysis/ the In RTGwg session of IETF102 is that using BGP session to pass configuration keys for IPsec can be risky even if the path between RR & node is secure (say via TLS) due to BGP route leak (Hijack).

But the BGP session to carry IPsec configurations is via BGP management session, which is completely isolated form the dataplane BGP sessions.

Does it still post a risk?

Linda Dunbar

v2.23.0 | Report a Bug | By Email