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 <[email protected]>
*Sent:* 25 November 2022 16:32
*To:* Dirk Trossen <[email protected]>; Michael McBride
<[email protected]>; Thomas Martin <[email protected]>;
[email protected]
*Cc:* [email protected]
*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 <[email protected]>
<mailto:[email protected]> *On Behalf Of *Jordi
Paillissé Vilanova
*Sent:* 17 November 2022 17:14
*To:* Michael McBride <[email protected]>
<mailto:[email protected]>; Dirk Trossen
<[email protected]> <mailto:[email protected]>; Thomas
Martin <[email protected]> <mailto:[email protected]>;
[email protected]
*Cc:* [email protected]
*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 <[email protected]>
<mailto:[email protected]>
*Sent:* Wednesday, November 16, 2022 5:09 AM
*To:* Thomas Martin <[email protected]>
<mailto:[email protected]>; Michael McBride
<[email protected]>
<mailto:[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
