Re: [Dlt-networking] updated draft-mcbride-rtgwg-bgp-blockchain

Jordi Paillissé Vilanova <jordi.paillisse@upc.edu> Thu, 17 November 2022 16:14 UTC

Return-Path: <jordi.paillisse@upc.edu>
X-Original-To: dlt-networking@ietfa.amsl.com
Delivered-To: dlt-networking@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0162C14CF13 for <dlt-networking@ietfa.amsl.com>; Thu, 17 Nov 2022 08:14:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.797
X-Spam-Level:
X-Spam-Status: No, score=-6.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=upc-edu.20210112.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnaiEei9Bc-x for <dlt-networking@ietfa.amsl.com>; Thu, 17 Nov 2022 08:14:19 -0800 (PST)
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB633C14F5E1 for <dlt-networking@ietf.org>; Thu, 17 Nov 2022 08:14:19 -0800 (PST)
Received: by mail-wr1-x42f.google.com with SMTP id d9so4620668wrm.13 for <dlt-networking@ietf.org>; Thu, 17 Nov 2022 08:14:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=upc-edu.20210112.gappssmtp.com; s=20210112; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=rCrd0sLhT+opU46MuY+uuGpAuvMDW2vhHi9MdcssSR0=; b=E8Q0sDsDFhzGMKBogE3PMSbk3gi69vt8EDR6iXhq0l0ixY1AEHFzKg/cwXpC8ac0yO ZuF0EncF+LvSieTNHSI+fDn8c0RdlkeEPx4kKNjeHaM2Nfcy6Lf3vGkVU2yapUjPF/dM KPHtC/cakZmH829JjDydssMz0p5DJLntF0rrjAaXGFWrNrWgNf9ELFJuunWoIGsULw4q V5gkJSRHe9r2aXw1es4OpxhyARFp6MxIKagP4P5+Il/mgec5a+N8i+dZu7081fws7/fa 4gVxig6R/XCIhdrCPDApoDNIrjFahgY07vvoqgL7nSZxPfFgm798mcDocOfNQ1je43J4 n6zQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=rCrd0sLhT+opU46MuY+uuGpAuvMDW2vhHi9MdcssSR0=; b=Hc1cSGmOtKyIJkZ80kupspu6E1/dZZ4Bx3mPf3nMkR+yppI4pnuWzn52632uDF3+tE DY2k/IkVYuTQip0CbjZBtag4+hAa+3122to3e14VtLmjus46QI7Qggvtf2NVAlyFpUMW ZmuNrazQKELQZveSa5RvtrrtJ37I+g3HR5uyooUJWgZ5t7414/c2jOWKtUULQyinM6zu rBHInTYDduyMFyCN45kcrF6FgxB6HYoKksccKpiF2MMlsWN0yCTKVJqeifBttdghz1GR oX94U0THPls0d2R9iCrckALoanJbbYa0eMBAM82x4pl9d8FT+7rm8O8KWKYa4iyo/zgY 11AA==
X-Gm-Message-State: ANoB5pl7P7bCejx8KN84xHQ/u3j+NzHfX9MtzplLGB9ow7P1EdfXhT1W 6ZmOjYALq4L2fXVpVUIE7CBXzDWBlcJSSw==
X-Google-Smtp-Source: AA0mqf4xpiO1OVM93W92txEhCtIuahDwkf6bP8wawOLMA+aw7KRkwus0vcsOQ29bY/mFcBDa7XxxEw==
X-Received: by 2002:adf:e50f:0:b0:22c:cc75:5aab with SMTP id j15-20020adfe50f000000b0022ccc755aabmr1888476wrm.143.1668701657817; Thu, 17 Nov 2022 08:14:17 -0800 (PST)
Received: from [84.88.154.183] (namac1.udg.edu. [84.88.154.183]) by smtp.gmail.com with ESMTPSA id l24-20020a05600c1d1800b003cf878c4468sm7019530wms.5.2022.11.17.08.14.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Nov 2022 08:14:17 -0800 (PST)
Content-Type: multipart/alternative; boundary="------------rM6gKMG11Z2q7F1eih3Fx4DN"
Message-ID: <4374e626-8eec-4a2c-b3ea-dadcadfa2be1@upc.edu>
Date: Thu, 17 Nov 2022 17:14:16 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2
Content-Language: en-US
To: Michael McBride <michael.mcbride@futurewei.com>, Dirk Trossen <dirk.trossen@huawei.com>, Thomas Martin <T.Martin@mmu.ac.uk>, "dlt-networking@ietf.org" <dlt-networking@ietf.org>
Cc: "rtgwg@ietf.org" <rtgwg@ietf.org>
References: <BYAPR13MB2582A778C609AE79B203B972F4BD9@BYAPR13MB2582.namprd13.prod.outlook.com> <DB9PR01MB9566BE9C585622CAE4D6AAB5C4079@DB9PR01MB9566.eurprd01.prod.exchangelabs.com> <a8b21371b835403fbca314b27c6d8de4@huawei.com> <BYAPR13MB2582C7C2937E280BDF86D930F4069@BYAPR13MB2582.namprd13.prod.outlook.com>
From: Jordi Paillissé Vilanova <jordi.paillisse@upc.edu>
In-Reply-To: <BYAPR13MB2582C7C2937E280BDF86D930F4069@BYAPR13MB2582.namprd13.prod.outlook.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dlt-networking/-8l3exCLbvnY8CXw-36n61qSK1k>
Subject: Re: [Dlt-networking] updated draft-mcbride-rtgwg-bgp-blockchain
X-BeenThere: dlt-networking@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: DLT Networking <dlt-networking.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dlt-networking>, <mailto:dlt-networking-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dlt-networking/>
List-Post: <mailto:dlt-networking@ietf.org>
List-Help: <mailto:dlt-networking-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dlt-networking>, <mailto:dlt-networking-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Nov 2022 16:14:24 -0000

Hi Thomas, Mike,

I had a quick look at your draft and a key question that comes to my 
mind is: which consensus algorithm would you use in the this blockchain? 
You mention linking the blockchain access control to the the RPKI, but 
not how you'd achieve consensus.

However, even though I am a blockchain enthusiast, I see some 
difficulties in deploying such blockchain. What would be really nice, 
adding the AS_PATH (right now not covered by the RPKI and dependent on 
the deployment of BGPsec) presents some scalability challenges, because 
there is a significant amount of data to validate and needs to propagate 
as fast as possible so routers can validate the BGP announcements.

You may want to have a look at our paper about the topic: 
https://ieeexplore.ieee.org/abstract/document/8903274

Thanks,

Jordi

El 17/11/22 a les 1:52, Michael McBride ha escrit:
>
> Good points Thomas and Dirk.
>
> We will add some of that text to the draft, Thomas, thank you, you are 
> welcome to join the draft as an author if interested. By group of 
> users I was thinking of those devices (minors, validators) which 
> actually create the blocks. Good point about smart contracts, we need 
> to explain their role in greater detail.
>
> Before our next IETF (Yokohama) I’d like to have a draft which 
> proposes specifically how we think blockchain can help a routing 
> protocol such as BGP. The current draft simply provides an overview of 
> various possibilities. It’ll probably be a good idea to have a side 
> meeting as well to discuss this topic beyond 10 minutes in rtgwg.
>
> Lastly, some of the comments during the rtgwg meeting (cc’d) included:
>
>  1. Having a blockchain as part of the bgp control loop is probably
>     not a good thing due it’s low transaction speed.
>  2. Only way this may be useful is to show proof of ownership of
>     network assignments (addr, prefix, AS, etc).
>  3. BGP policy may be a good area of focus for blockchain: Address
>     delegation contracts. Billing. ARIN/RIPE databases...
>
> mike
>
> *From:* Dirk Trossen <dirk.trossen@huawei.com>
> *Sent:* Wednesday, November 16, 2022 5:09 AM
> *To:* Thomas Martin <T.Martin@mmu.ac.uk>; Michael McBride 
> <michael.mcbride@futurewei.com>; dlt-networking@ietf.org
> *Subject:* RE: updated draft-mcbride-rtgwg-bgp-blockchain
>
> Hi Thomas,
>
> Many thanks for the feedback and comments. Good to see the discussion; 
> I will leave it to Mike to decide whether we should reflect this 
> discussion also on the RTG WG list (where the draft was presented). 
> For now, I am quite fine here.
>
> Best,
>
> Dirk
>
> *From:* Dlt-networking <dlt-networking-bounces@ietf.org> *On Behalf Of 
> *Thomas Martin
> *Sent:* 16 November 2022 12:40
> *To:* Michael McBride <michael.mcbride@futurewei.com>; 
> dlt-networking@ietf.org
> *Subject:* Re: [Dlt-networking] updated draft-mcbride-rtgwg-bgp-blockchain
>
> Hello,
>
> I've read the draft and I have some comments (first time posting to a 
> IETF mailing list, apologies if there's etiquette I'm not aware of). 
> The proposal seems to be written with a view of putting BGP data in 
> the blockchain and using smart contracts to control how the data is 
> managed. This is creating a single source of truth, something that 
> blockchains are particularly well suited for. However, reading some of 
> the draft indicates to me that there is potential that has not been 
> identified:
>
> "In terms of trust assumptions, a DCS for BGP may require 
> authentication to prevent fraudulent DCS transactions, such as 
> fraudulent BGP announcements being made. For this, the existing RPKI 
> system could be used to authorize any client before sending suitable 
> smart contract transactions into the DCS."
>
> "Furthermore, the DCS could be permissisoned, thereby restricting the 
> nodes holding as well as accessing information to trusted members of 
> the community."
>
> Both of these quotes indicates that authentication/authorisation would 
> need to be added-on to the DCS. Blockchains have inherent 
> authentication through the use of public-private keys. Any action that 
> changes the state of the blockchain ledger requires a signature, which 
> authenticates the entity (only someone with the private key could have 
> created the signature). If you need some method of relating a 
> blockchain address to a real-world entity, then that is something that 
> would need to be added-on. But any blockchain solution should take 
> advantage of the inherent authentication provided by the use of public 
> keys.
>
> */[DOT] Your reference to the pub/priv keys used is, in fact, similar 
> to the use of the RPKI system for achieving the same objective. The 
> BGP community is quite familiar with its objective and purpose, hence 
> the mentioning on it rather than the pub/priv keys usually used in BC. 
> /**//*
>
> */[DOT] When it comes to the permissioned aspect, it more relates to 
> your issue below, I think./*
>
> The other implicit message I read from the above quotes (and the rest 
> of the draft) was the idea of a group of authorised users. That there 
> is some set of users who can make changes to the BGP data on the 
> blockchain, and everyone else is prevented from changing anything/can 
> only read the data. To me, this is not implementing the principle of 
> least privilege.
>
> */[DOT] I am not entirely sure that this is the message that was 
> intended here and I would argue that the possibly commissioned nature 
> is not about that either (if anything, it is restricting the set of 
> users per se, period, not just for write access). /*
>
> If the smart contract is only checking membership in the authorised 
> set, then the users would have the capability to perform many actions 
> beyond what they should. Accidental errors (or compromised accounts) 
> could lead to harm. A secure blockchain system will place as much of 
> the logic controlling/restricting access in the code of the smart 
> contract itself as possible as this is the least corruptible part of 
> the system.
>
> */[DOT] I agree with that, if that was indeed the intended objective 
> but see my last comment. /*
>
> To apply this to BGP, it could be possible to use another thing that 
> blockchains do very well: namely assigning individual owners to 
> resources. NFTs gets a lot of deserved ridicule for the associated 
> hype and unethical behaviour, but the technology allows a verifiable 
> single source of ownership to be determined. This is something that a 
> PKI cannot do. It is possible to have multiple conflicting chains of 
> certificates signed (e.g., through error or attack). To me, the 
> natural application of blockchains to BGP would be to consider 
> prefixes as tokens assigned to AS blockchain addresses. The unique 
> owner of any prefix could be determined with high confidence. This, 
> plus the signing of peering relationships by the relevant ASes, could 
> solve a lot of the problems with fraudulent announcements. If the 
> smart contract is written correctly (big if, obviously), then it would 
> be impossible for any entity to announce a route they were not 
> authorised to.
>
> */[DOT] I think this is an excellent point and worthwhile capturing in 
> the draft, i.e., using BC to assert ownership of a resource (like a 
> prefix). If we positioned this (rightly) as the key issue for BGP 
> operations, all else may just be ‘bootstrapped’ from it. /*
>
> There are a lot of unanswered questions about how practical and 
> scalable any of the above is.
>
> */[DOT] You may (or may not) have noticed a second draft in the IETF 
> on “impact of DLTs on provider networks”, now superseded by a more 
> detailed publication and originating from some work done in the IIC 
> (Industrial Internet Consortium) with a whitepaper released in Jan 
> 2022. This work is looking at DCS (example there is Ethereum) and what 
> it ‘does’ to a network, largely driven by the need for 
> capability-based communication to realise the randomized diffusion 
> broadcast/multicast that underlies the DLT operation. From a network 
> perspective, it is quite painful but raises also interesting questions 
> on how networks could improve on it or provide support (through 
> network-level innovations). /*
>
> It is an area of research I've put some thought into, but not yet had 
> much of a chance to do any serious work on it. If any of the above may 
> be applicable to the aim of this group, please let me know.
>
> */[DOT] It sure sounds like it and it would be good to get these 
> thoughts into a revision of the draft and further discussed. We are 
> still looking into the constituency within the IETF to have this 
> conversation but it may well be this group, which will hopefully grow. /*
>
> Kind Regards,
>
> Thomas.
>
> **
>
> Dr Thomas Martin (he/him) | Senior Lecturer | Department of Computing 
> and Mathematics | t.martin@mmu.ac.uk
>
>
> 0161 247 1501 | Room JD E120
>
> Manchester Metropolitan University | John Dalton Building | Manchester 
> | M1 5GD
>
> Office Hours: Monday 3:00 - 4:30 pm and Wednesday 11:30 - 1:00 pm
>
> Please note that I am on a flexible working schedule and will only be 
> reading/answering MMU email on Monday/Tuesday/Wednesday
>
> ------------------------------------------------------------------------
>
> *From:*Dlt-networking <dlt-networking-bounces@ietf.org> on behalf of 
> Michael McBride <michael.mcbride@futurewei.com>
> *Sent:* 01 July 2022 9:46 PM
> *To:* dlt-networking@ietf.org <dlt-networking@ietf.org>
> *Subject:* [Dlt-networking] updated draft-mcbride-rtgwg-bgp-blockchain
>
> *This email originated from outside of Manchester Met. Do not click 
> links or open attachments unless you recognise the sender and believe 
> the content to be safe. Please contact the IT Helpline if you have any 
> concerns, https://www.mmu.ac.uk/isds/contact 
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mmu.ac.uk%2Fisds%2Fcontact&data=05%7C01%7Cmichael.mcbride%40futurewei.com%7C3c48c5a9deb648bd46e708dac7d3b518%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638042009342782431%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=SZxvPzLDwCZ7YkLp43K77bLq8NSaqUmJWHipD7Writg%3D&reserved=0>*
>
> ------------------------------------------------------------------------
>
> Hello,
>
> A couple of new authors joined in and we’ve updated 
> https://www.ietf.org/archive/id/draft-mcbride-rtgwg-bgp-blockchain-01.txt 
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-mcbride-rtgwg-bgp-blockchain-01.txt&data=05%7C01%7Cmichael.mcbride%40futurewei.com%7C3c48c5a9deb648bd46e708dac7d3b518%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638042009342782431%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FBDHIa9semYZv6DXO4UpUdG5HzOOBtSeYPict4JYK8w%3D&reserved=0> 
> with a fair amount of new information including the use of smart 
> contracts. Please give it a read and comment if you feel it’s on the 
> right track or not. We have time to update the draft again before the 
> deadline. We will likely discuss this at the upcoming IETF 114 meeting 
> in rtgwg if there is time. Hope to see many of you in Philly.
>
> Thanks,
>
> mike
>
> "Before acting on this email or opening any attachments you should 
> read the Manchester Metropolitan University email disclaimer available 
> on its website http://www.mmu.ac.uk/emaildisclaimer 
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mmu.ac.uk%2Femaildisclaimer&data=05%7C01%7Cmichael.mcbride%40futurewei.com%7C3c48c5a9deb648bd46e708dac7d3b518%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638042009342782431%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=sUy1w7ALgeupl84GVTwst2RUE1d90jCBQ7o5Voog78E%3D&reserved=0> 
> "
>
>
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg