Re: Preventing BGP Route leak (Hijack) for Management Channel BGP session
Robert Raszuk <robert@raszuk.net> Fri, 17 August 2018 09:20 UTC
Return-Path: <robert@raszuk.net>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B500129385 for <rtgwg@ietfa.amsl.com>; Fri, 17 Aug 2018 02:20:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.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 wrAjycYyMPMc for <rtgwg@ietfa.amsl.com>; Fri, 17 Aug 2018 02:20:08 -0700 (PDT)
Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F13DD130E3D for <rtgwg@ietf.org>; Fri, 17 Aug 2018 02:20:07 -0700 (PDT)
Received: by mail-qt0-x232.google.com with SMTP id r21-v6so8030524qtm.2 for <rtgwg@ietf.org>; Fri, 17 Aug 2018 02:20:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MS1FvaIJsccB8YujLein1uEBANCWD6PvPf78C4EZpfA=; b=aV4NTouL6Nc8ezAC18M7LeOR9ooTqhuUfc3qQecdeMsB8d8KYVMrszF9uRvtWM4CdN nncZFK05au1G05Yhr5qlxvicc/oYC1ZyLZVjgXvKnhbo1mwUsdygkEfkty2C03jGItxL Fsntu3nL22AfZqd3tseLLYt9B4cNmJGOVy5kAw2jxaKNdTOPYrUUgreee732n8XrfV4l 3DnplvjBIveoybhmIcZUrOXmI0aQU5h8N91cLuBGNmlLaK9zDGaG/nKX9lOtta9slnLV 4hZWFbktkW4c7BC+jrZEMnwKVTH4Tu5Npin1C7qGGqXFgGUnrsSWvHv2xIH0i/Q65h6u NX4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MS1FvaIJsccB8YujLein1uEBANCWD6PvPf78C4EZpfA=; b=NhRP3UoL59FFTQN5VlFJ0p87dM1Z08doL1kPrTT4m2q/wEEsLphlivojEqNbTU3GHq V+4tkRcm1T7Ua5O3J/Fc7lox3mXGBn/OLex+yQ4MH+M9ySzbwCxQJNyE6b0g1/h8eM01 qY6sWFgQZc1kjmKZ71gryZrDyxMZUyIWLIghOSyX5NIAzKAGIRbRiPmtDFp7m+jcvEIS BXwPT9MnZJSpMU7WL7Hl3xGh5KSyVTCS16EObKJP2vSoyRNFy10jfh4fUaIhuIFGNuTJ ut7M/b9r+ZTPznyQDzRQKxiL8RxW8rBkQcwD//+KDBKQ5XYPeWUAXxCoJ/OF4zdfxzfJ Z60Q==
X-Gm-Message-State: AOUpUlEiOM8vMXwmXKmyZNaZCUbJkPwqIfxyMs12rB9rUUn9KvYSf111 r06Ykbj8ggw7rpMfwfjxFf9fPOpOjFVDccZi4rH5G4XktDE=
X-Google-Smtp-Source: AA+uWPz1vmKBbkD6u/y6Oo63R0mUg5E30uNPYeKDqo5HiCMam241FIdJLA9TfYSy4M7stHMd6CKK+5S4V0fm1+dR2JY=
X-Received: by 2002:a0c:95ad:: with SMTP id s42-v6mr30191174qvs.18.1534497607067; Fri, 17 Aug 2018 02:20:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a0c:afd4:0:0:0:0:0 with HTTP; Fri, 17 Aug 2018 02:20:06 -0700 (PDT)
X-Originating-IP: [83.28.116.46]
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F66B0DC48F@sjceml521-mbx.china.huawei.com>
References: <4A95BA014132FF49AE685FAB4B9F17F66B0DAE87@sjceml521-mbx.china.huawei.com> <d6d522ea-f555-9344-0dee-732bb9983ef9@juniper.net> <4A95BA014132FF49AE685FAB4B9F17F66B0DC48F@sjceml521-mbx.china.huawei.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 17 Aug 2018 11:20:06 +0200
Message-ID: <CAOj+MMH-LmcnB60qWftf1fPjLXpFt1MdVRJKw4CLg6qyBef9Zg@mail.gmail.com>
Subject: Re: Preventing BGP Route leak (Hijack) for Management Channel BGP session
To: Linda Dunbar <linda.dunbar@huawei.com>
Cc: Eric C Rosen <erosen@juniper.net>, "idr@ietf.org" <idr@ietf.org>, RTGWG <rtgwg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c740bc05739e1015"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/r_MyEjVK29FAhcVCN6e_IOlUqXs>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Aug 2018 09:20:12 -0000
Hi Linda, > requiring Data Plan BGP session to be completely separate from the Management Plane BGP session, is it Okay? As I mentioned offline there is no distinction in BGP for data plane BGP session vs Mgmt Plane BGP session. BGP session is a BGP session - pure TCP stream of packets which is pretty trivial to intercept, decode, hijack, etc .... Moreover BGP messages are designed to be flooded everywhere in a p2mp fashion. Even if you add "NO-ADVERTISE" BGP community to it - communities can get stripped automatically on any BGP speaker. Hence you clean your sole safety protection. The question I would like to state and understood - why are you trying so hard to use BGP for IPSec secret key distribution ? Is this only due to the fact that you have it there ? Wasn't IKE and now improved IKEv2 specifically designed to do just that ? Any reason you don't want to use it ? Thx, R. On Fri, Aug 17, 2018 at 12:59 AM, Linda Dunbar <linda.dunbar@huawei.com> wrote: > Eric, > > > > Thank you very much for the detailed explanation. > > > > I meant to ask about using BGP UPDATEs of a unique AFI/SAFI to distribute > the “Public Keys” and individual “Nonce” to all the CPEs. Just like IKE > (where peers exchange public key over internet), now the Public keys are > exchanged between peers via RR (Controller). With this approach, the CPEs > can offload the Peer Authentication job to Controller. > > > > IPsec’s Diffie-Hellman algorithm use “Public Key” and CPE’s Private Key > to compute the actual Security Association. > > > > In your draft-rosen-bess-secure-l3vpn-01, you have BLACK BGP session and > RED BGP session, and emphasized on how BLACK BGP not leaking routes to RED > BGP. I want to know if we can do the same for Management BGP session, i.e. > requiring Data Plan BGP session to be completely separate from the > Management Plane BGP session, is it Okay? > > > > Thanks, Linda Dunbar > > > > > > > > *From:* Eric C Rosen [mailto:erosen@juniper.net] > *Sent:* Thursday, August 16, 2018 2:59 PM > *To:* Linda Dunbar <linda.dunbar@huawei.com>; shares@ndzh.com; > idr@ietf.org; Jeff Tantsura <jefftant.ietf@gmail.com>; RTGWG < > rtgwg@ietf.org> > *Subject:* Re: Preventing BGP Route leak (Hijack) for Management Channel > BGP session > > > > On 8/13/2018 3:26 PM, Linda Dunbar wrote: > > One of the comments to https://datatracker.ietf.org/ > doc/draft-dm-net2cloud-gap-analysis/ > <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Ddm-2Dnet2cloud-2Dgap-2Danalysis_&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=RToh0UhV7F8cp3q2ud1LmU6GZtypPTJdboL4dgpRzr0&s=9xbKYj5fP6Jv93coe5g-lfzpp0L0bK0GyrlB91Ry3Sw&e=> > 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.. > > > I'm not sure I have the whole context, but the question seems to be > whether it could ever be safe to use BGP to distribute secret keys. > > Presumably: > > - The keys would be carried in an attribute that can only be attached by > UPDATEs of a specified AFI/SAFI, where the specified AFI/SAFI is only used > to carry management/configuration information. > > - UPDATEs of that AFI/SAFI would only be sent on BGP sessions that are > adequately secured so as to provide privacy, integrity and authentication. > > - The UPDATEs would carry the NO_ADVERTISE community (to make sure they > are not propagated further). > > - None of the BGP systems involved would allow any sort of "BGP > monitoring" that might expose the unencrypted contents of the UPDATEs. > > In this scenario, I don't think it matters whether the secure BGP session > also carries other AFI/SAFIs. > > The privacy properties of this scenario are pretty good, in theory, but I > don't think they are really good enough for distributing secret keys. > > - Once you're using BGP to distribute information, it is inevitable that > someone will decide to remove the "NO_ADVERTISE" and allow the information > to be propagated through intermediate nodes (RRs or ASBRs) to the actual > target node. After all, one of the main values of using BGP to distribute > stuff is that you get a big distribution system. Even if all the > intermediate nodes are trusted and all the intermediate BGP sessions have > adequate privacy/integrity/authentication, you still wouldn't want to > expose the secret keys to those nodes. You might trust those nodes to see > all the routing information, and even to see most of the management > information, but you probably don't want them to see all the secret keys. > And you probably don't want the secret keys stored in the clear on those > intermediate nodes. > > - I would worry about BGP monitoring procedures creating a backdoor > through which the secret keys would be exposed. > > - No matter how careful you are, when you use BGP you can be pretty sure > that your UPDATEs will end up somewhere they're not supposed to go. It's > just too easy to make mistakes. > So I don't think I'd try to do dynamic keying by attaching the actual keys > to BGP UPDATEs. At most I'd use BGP to distribute parameters that could > then be used by something like IKEv2 to actually fetch the secret keys. > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > >
- Preventing BGP Route leak (Hijack) for Management… Linda Dunbar
- Re: Preventing BGP Route leak (Hijack) for Manage… Eric C Rosen
- Re: Preventing BGP Route leak (Hijack) for Manage… Jeff Tantsura
- RE: Preventing BGP Route leak (Hijack) for Manage… Linda Dunbar
- Re: Preventing BGP Route leak (Hijack) for Manage… Robert Raszuk
- RE: Preventing BGP Route leak (Hijack) for Manage… Linda Dunbar
- Re: Preventing BGP Route leak (Hijack) for Manage… Jeff Tantsura