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 <[email protected]>
*Sent:* Wednesday, November 16, 2022 5:09 AM
*To:* Thomas Martin <[email protected]>; Michael McBride
<[email protected]>; [email protected]
*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 <[email protected]> *On Behalf Of
*Thomas Martin
*Sent:* 16 November 2022 12:40
*To:* Michael McBride <[email protected]>;
[email protected]
*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 | [email protected]
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 <[email protected]> on behalf of
Michael McBride <[email protected]>
*Sent:* 01 July 2022 9:46 PM
*To:* [email protected] <[email protected]>
*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
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
