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

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

Hi Dirk,

Yep, this makes sense to me.

Thanks,

Jordi

El 28/11/22 a les 09:24, Dirk Trossen ha escrit:
>
> Hi Jordi,
>
> My point is that gathering the need for those latency boundaries 
> allows for designing/thinking of a DCS that would indeed have the 
> ‘right’ boundary (to be any useful for BGP updates). IOW, any DCS not 
> being ‘fast enough’ is of no use, is it?
>
> Best,
>
> Dirk
>
> *From:*Jordi Paillissé Vilanova <[e-mail]>
> *Sent:* 25 November 2022 16:32
> *To:* Dirk Trossen <[e-mail]>; Michael McBride 
> <[e-mail]>; Thomas Martin <[e-mail]>; 
> [e-mail]
> *Cc:* [e-mail]
> *Subject:* Re: [Dlt-networking] updated draft-mcbride-rtgwg-bgp-blockchain
>
> 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]>
>     <mailto:[e-mail]> *On Behalf Of *Jordi
>     Paillissé Vilanova
>     *Sent:* 17 November 2022 17:14
>     *To:* Michael McBride <[e-mail]>
>     <mailto:[e-mail]>; Dirk Trossen
>     <[e-mail]> <mailto:[e-mail]>; Thomas
>     Martin <[e-mail]> <mailto:[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
>