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

[Jordi Paillissé Vilanova <[e-mail]>]

Hi Dirk,

Thanks for your answer.

If I understood your last paragraph correctly, do you mean that a DCS 
for BGP updates would have some kind of bounded delay for message 
propagation, so its data can keep up with the propagation speed of 
"regular" BGP messages?

Thanks,

Jordi

El 17/11/22 a les 18:02, Dirk Trossen ha escrit:
>
> Hi Jordi,
>
> Thanks for the reference, which is really useful. We’ve not looked 
> specifically into the right consensus mechanism but as you outline in 
> your paper, PoS seems to be fitting given the use case here, indeed. 
> PoW seems to not only be somehow disconnected from the ‘ownership’ 
> aspect that the use case embodies but its prohibitive footprint makes 
> it not a candidate of choice when proposing this as a mechanism going 
> forward (the IAB workshop on environmental impact of Internet 
> applications comes to mind here).
>
> You are right that the challenge lies in the consensus convergence, 
> i.e., the ‘throughput’ of the DCS in terms of transaction validations. 
> This also relates to the draft on impact of DLTs on provider networks 
> (https://datatracker.ietf.org/doc/draft-trossen-rtgwg-impact-of-dlts/) 
> , where we studied what the required messaging in a DCS (with the 
> example being ETH in the work) caused by the needed diffusion 
> multicast in DLT is doing in and to networks.
>
> Those insights, however, may be useful to think of network innovations 
> that may improve not just on that impact (in terms of signaling and 
> thus costs) but also convergence time. A first step would be to bound 
> that required time, given by the use case here (validating BGP 
> updates) in order to define the boundary against which any possible 
> (DCS) solution must be designed.
>
> Best,
>
> Dirk
>
> *From:*Dlt-networking <[e-mail]> *On Behalf Of 
> *Jordi Paillissé Vilanova
> *Sent:* 17 November 2022 17:14
> *To:* Michael McBride <[e-mail]>; Dirk Trossen 
> <[e-mail]>; Thomas Martin <[e-mail]>; 
> [e-mail]
> *Cc:* [e-mail]
> *Subject:* Re: [Dlt-networking] updated draft-mcbride-rtgwg-bgp-blockchain
>
> 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 <[e-mail]>
>     <mailto:[e-mail]>
>     *Sent:* Wednesday, November 16, 2022 5:09 AM
>     *To:* Thomas Martin <[e-mail]>
>     <mailto:[e-mail]>; Michael McBride
>     <[e-mail]>
>     <mailto:[e-mail]>; [e-mail]
>     *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 <[e-mail]> *On
>     Behalf Of *Thomas Martin
>     *Sent:* 16 November 2022 12:40
>     *To:* Michael McBride <[e-mail]>;
>     [e-mail]
>     *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 | [e-mail]
>
>
>     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 <[e-mail]> on behalf
>     of Michael McBride <[e-mail]>
>     *Sent:* 01 July 2022 9:46 PM
>     *To:* [e-mail] <[e-mail]>
>     *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
>
>     [e-mail]
>
>     https://www.ietf.org/mailman/listinfo/rtgwg
>