How about validating whether a given AS is an acceptable origin for a set of prefixes? Seems like a problem (route hijacking) that's still been looking for a solution. Lots of BGP routers, RRs, prefix databases are around, maintained and generally online. Current practices are incomplete and for many large carriers, operate on a 24 hour cycle which might not be acceptable if the world had a more instant option in place.
It is not my impression that maintaining an updatable database of (AS, prefix) pairs is particularly difficult. What's hard is figuring out who's allowed to put what into the database, and blockchains offer no help at all there. See https://xkcd.com/927/ Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
On Tue, Jan 9, 2018 at 1:07 AM, John R. Levine <johnl@iecc.com> wrote:
How about validating whether a given AS is an acceptable origin for a set
of prefixes?
That's a job for ordinary PKI. Any time you have a trusted central authority to serve as an anchor, ordinary PKI works fine. The RIRs serve as anchors for who has the right to authorize which prefixes. A harder task is validating whether your peer is part of a legitimate AS path to that origin. It's not obvious to me that blockchain could help solve that problem, but it's at least a problem that isn't solved by ordinary PKI. Now, if we wanted to replace the RIRs and allow people to self-assign IPv6 addresses out of ULA space which we'd then honor in the global BGP table, blockchain could have a role. -Bill -- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>
On Tue, Jan 9, 2018 at 11:22 AM, William Herrin <bill@herrin.us> wrote:
On Tue, Jan 9, 2018 at 1:07 AM, John R. Levine <johnl@iecc.com> wrote:
How about validating whether a given AS is an acceptable origin for a set
of prefixes?
That's a job for ordinary PKI. Any time you have a trusted central
in particular RPKI -> https://tools.ietf.org/html/rfc6810
authority to serve as an anchor, ordinary PKI works fine. The RIRs serve as anchors for who has the right to authorize which prefixes.
A harder task is validating whether your peer is part of a legitimate AS path to that origin. It's not obvious to me that blockchain could help solve that problem, but it's at least a problem that isn't solved by ordinary PKI.
this part of the problem is BGPsec -> https://tools.ietf.org/html/rfc8205
Now, if we wanted to replace the RIRs and allow people to self-assign IPv6 addresses out of ULA space which we'd then honor in the global BGP table, blockchain could have a role.
yes, here's a useful use for blockchains... allocation of random numbers, and logging of same in a globally available fashion.
-Bill
-- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>
On Tue, Jan 9, 2018 at 10:22 AM, William Herrin <bill@herrin.us> wrote:
On Tue, Jan 9, 2018 at 1:07 AM, John R. Levine <johnl@iecc.com> wrote:
The promise of blockchain is fraud-resistant recordkeeping, database management, AND resource management maintained by a distributed decentralized network which eliminates or reduces the extent to which there are central points of trust involved in the recordkeeping, AND can implement resource-management rules or policies programmatically and in an unbiased way (E.G. "Smart Contracts"). For example: A decentralized internet number registry could use a blockchain as the means of making the public records showing the transferrence of the ownership of a particular internet number from the originator to the registrant. The potential is there to go a step beyond replacing RPKI, as a blockchain could be the AS number authority itself, thus eliminating the need to have any centralized organizations for tracking and managing number resource assignments.
How about validating whether a given AS is an acceptable origin for a set
of prefixes? That's a job for ordinary PKI. Any time you have a trusted central authority to serve as an anchor, ordinary PKI works fine. The RIRs serve as
See: That's the problem. Ordinary PKI DEPENDS on centralized trust -- that is, with PKI there are corruptible or potentially corruptible or compromisable entities in your system that you assign an unwarranted or unnecessary level of trust to. That would include organizations such AS Number and IP Address registries. Under the current system, they retain an Unwarranted level of trust, for example: ARIN Could Delete an IP address allocation or an AS number allocation after it was assigned, because someone else told them to, or maybe someone didn't like the content on your website and coerced/tricked someone who manipulated or legally forced the central figure to do so. This would include whatever entities can be signing authorities of your PKI. This includes any organization with unsecured resource management capabilities, such as the DNS Root server, TLD Server operators, and Domain registrars. Which includes the risks: (1) The signing authority could be breached by an outsider or insider attack (2) The signing authority could prove untrustworthy or later change the rules. (3) The signing authority could be covertly corrupted by a government authority or foreign power: to support nefarious goals or surveilance or censorship. For example: A DNS Registrar or TLD Registry could make a change to the DS Key or remove the DS Key and confiscate a domain to intercept traffic, without even the permission of the original registrant. -- -JH
The potential is there to go a step beyond replacing RPKI, as a blockchain could be the AS number authority itself, thus eliminating the need to have any centralized organizations for tracking and managing number resource assignments. I am a long-time follower and fan of Bitcoin and I have a lot of skepticism of most of the ideas for using blockchain tech for other
On 1/23/2018 6:17 AM, Jimmy Hess wrote: things. They seem like ill-thought-out solutions in search of a problem. HOWEVER, various Internet/number authorities are sometimes a big point of contention, subject to government pressure, etc, and this is one case where I can see a trustless, distributed blockchain architecture actually improving things. I think your email (not just the quoted part) was a good insight on the subject. --Brock
Thanks for this note -- I couldn't ask for a better explanation of why blockchains don't solve any actual real world problems. Trust problems are difficult, and waving hands and saying decentralize! solves nothing. For the nanog-related example of validating AS origin, the problem isn't keeping the database, it's figuring out who can make authoritative statements about each block of IP addresses. That is an inherently hierarchical question since all IP blocks originally trace back to allocations from IANA. We can have arguments about the best way to document the chain of ownership, and conspiracy theories about how the evil RIRs are planning to steal our precious bodily flu^W^WIPs, but "put it in a blockchain!" Puhleeze. R's, John On Tue, 23 Jan 2018, Jimmy Hess wrote:
On Tue, Jan 9, 2018 at 10:22 AM, William Herrin <bill@herrin.us> wrote:
On Tue, Jan 9, 2018 at 1:07 AM, John R. Levine <johnl@iecc.com> wrote:
The promise of blockchain is fraud-resistant recordkeeping, database management, AND resource management maintained by a distributed decentralized network which eliminates or reduces the extent to which there are central points of trust involved in the recordkeeping,
AND can implement resource-management rules or policies programmatically and in an unbiased way (E.G. "Smart Contracts").
For example: A decentralized internet number registry could use a blockchain as the means of making the public records showing the transferrence of the ownership of a particular internet number from the originator to the registrant.
The potential is there to go a step beyond replacing RPKI, as a blockchain could be the AS number authority itself, thus eliminating the need to have any centralized organizations for tracking and managing number resource assignments.
How about validating whether a given AS is an acceptable origin for a set
of prefixes? That's a job for ordinary PKI. Any time you have a trusted central authority to serve as an anchor, ordinary PKI works fine. The RIRs serve as
See: That's the problem. Ordinary PKI DEPENDS on centralized trust -- that is, with PKI there are corruptible or potentially corruptible or compromisable entities in your system that you assign an unwarranted or unnecessary level of trust to.
That would include organizations such AS Number and IP Address registries. Under the current system, they retain an Unwarranted level of trust, for example: ARIN Could Delete an IP address allocation or an AS number allocation after it was assigned, because someone else told them to, or maybe someone didn't like the content on your website and coerced/tricked someone who manipulated or legally forced the central figure to do so.
This would include whatever entities can be signing authorities of your PKI. This includes any organization with unsecured resource management capabilities, such as the DNS Root server, TLD Server operators, and Domain registrars.
Which includes the risks: (1) The signing authority could be breached by an outsider or insider attack (2) The signing authority could prove untrustworthy or later change the rules. (3) The signing authority could be covertly corrupted by a government authority or foreign power: to support nefarious goals or surveilance or censorship.
For example: A DNS Registrar or TLD Registry could make a change to the DS Key or remove the DS Key and confiscate a domain to intercept traffic, without even the permission of the original registrant.
Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
On Tue, Jan 23, 2018 at 9:39 AM, John R. Levine <johnl@iecc.com> wrote:
the problem isn't keeping the database, it's figuring out who can make authoritative statements about each block of IP addresses.
That is an inherently hierarchical question since all IP blocks originally
trace back to allocations from IANA.
Well; It's a hierarchical question only because the current registration scheme is defined in a hierarchical manner. If BGP were being designed today, we could choose 256-Bit AS numbers, and allow each mined or staked block to yield a block of AS numbers prepended by some random previously-unused 128-bit GUID. However, a blockchain could also be used to allow an authority to make a statement representing a resource that can be made a non-withdrawable statement --- in other words, the authority's role or job in the registration process is to originate the registration, and after that is done: their authoritative statement is accepted ONCE per resource. The registration is permanent --- the authority has no ongoing role and no ability to later make a new conflicting statement about that same resource, and the authority has no operational role except to originate new registrations. This would mean that a foreign government could not coerce the authority to "cancel" or mangle a registration to meet a political or adversarial objective of disrupting the ability to co-ordinate networks, since the number registry is an authority of limited power: not an authority of complete power. We can have arguments about the best way to document the chain of
ownership, and conspiracy theories about how the evil RIRs are planning to steal our precious bodily flu^W^WIPs, but "put it in a blockchain!" Puhleeze. R's, John
-- -JH
That sounds like giving up an awful lot of utility for a (at least in most places) something that's an exceedingly rare corner case. The other problem is that even if the record is immutable there's nothing that prevents governments from being coercive in other ways. At the end of the day there's no technology that prevents authoritarian governments from behaving badly. On Tue, Jan 23, 2018 at 6:27 PM, Jimmy Hess <mysidia@gmail.com> wrote:
On Tue, Jan 23, 2018 at 9:39 AM, John R. Levine <johnl@iecc.com> wrote:
the problem isn't keeping the database, it's figuring out who can make authoritative statements about each block of IP addresses.
That is an inherently hierarchical question since all IP blocks originally
trace back to allocations from IANA.
Well; It's a hierarchical question only because the current registration scheme is defined in a hierarchical manner. If BGP were being designed today, we could choose 256-Bit AS numbers, and allow each mined or staked block to yield a block of AS numbers prepended by some random previously-unused 128-bit GUID.
However, a blockchain could also be used to allow an authority to make a statement representing a resource that can be made a non-withdrawable statement --- in other words, the authority's role or job in the registration process is to originate the registration, and after that is done: their authoritative statement is accepted ONCE per resource.
The registration is permanent --- the authority has no ongoing role and no ability to later make a new conflicting statement about that same resource, and the authority has no operational role except to originate new registrations.
This would mean that a foreign government could not coerce the authority to "cancel" or mangle a registration to meet a political or adversarial objective of disrupting the ability to co-ordinate networks, since the number registry is an authority of limited power: not an authority of complete power.
We can have arguments about the best way to document the chain of
ownership, and conspiracy theories about how the evil RIRs are planning to steal our precious bodily flu^W^WIPs, but "put it in a blockchain!" Puhleeze. R's, John
-- -JH
On Tue, Jan 23, 2018 at 6:27 PM, Jimmy Hess <mysidia@gmail.com> wrote:
since the number registry is an authority of limited power: not an authority of complete power.
Oh, the RIR's went and got complete power? When did that happen? Can they now stop hijacked ip space and announcements like in the case of: "Subject: Spectrum prefix hijacks" AS | BGP IPv4 Prefix | AS Name 10512 | 102.196.0.0/16 | EFOREX-AS - E-FOREX, US 10512 | 103.119.0.0/16 | EFOREX-AS - E-FOREX, US (forex seemed to have removed their previous other hijacked ip announcements)
On Tue, Jan 23, 2018 at 8:19 PM, Christopher Morrow <morrowc.lists@gmail.com
wrote:
On Tue, Jan 23, 2018 at 6:27 PM, Jimmy Hess <mysidia@gmail.com> wrote:
since the number registry is an authority of limited power: not an authority of complete power.
Oh, the RIR's went and got complete power? When did that happen? Can they now stop hijacked ip space and announcements like in the case of:
"Subject: Spectrum prefix hijacks"
AS | BGP IPv4 Prefix | AS Name 10512 | 102.196.0.0/16 | EFOREX-AS - E-FOREX, US 10512 | 103.119.0.0/16 | EFOREX-AS - E-FOREX, US
(forex seemed to have removed their previous other hijacked ip announcements)
note that 'hilariously' neither of those 2 address blocks are registered to anyone, at all...
On Tue, 23 Jan 2018 17:27:45 -0600, Jimmy Hess said:
However, a blockchain could also be used to allow an authority to make a statement representing a resource that can be made a non-withdrawable statement --- in other words, the authority's role or job in the registration process is to originate the registration, and after that is done: their authoritative statement is accepted ONCE per resource.
The registration is permanent --- the authority has no ongoing role and no ability to later make a new conflicting statement about that same resource, and the authority has no operational role except to originate new registration.
How do you express the conflicting statement "We are hereby revoking the registration of CyberFoo.com due to (insert valid reason here)"?
When your trying to find a use for your new hammer; everything tends to look like nails. Anthony Kolka Systems Engineer 303-414-6904 anthony@handynetworks.com<mailto:anthony@handynetworks.com> https://www.handynetworks.com On Jan 24, 2018, at 1:28 PM, Valdis.Kletnieks@vt.edu<mailto:Valdis.Kletnieks@vt.edu> wrote: On Tue, 23 Jan 2018 17:27:45 -0600, Jimmy Hess said: However, a blockchain could also be used to allow an authority to make a statement representing a resource that can be made a non-withdrawable statement --- in other words, the authority's role or job in the registration process is to originate the registration, and after that is done: their authoritative statement is accepted ONCE per resource. The registration is permanent --- the authority has no ongoing role and no ability to later make a new conflicting statement about that same resource, and the authority has no operational role except to originate new registration. How do you express the conflicting statement "We are hereby revoking the registration of CyberFoo.com<http://CyberFoo.com> due to (insert valid reason here)"?
On Tue, Jan 23, 2018 at 8:17 AM, Jimmy Hess <mysidia@gmail.com> wrote:
On Tue, Jan 9, 2018 at 10:22 AM, William Herrin <bill@herrin.us> wrote:
On Tue, Jan 9, 2018 at 1:07 AM, John R. Levine <johnl@iecc.com> wrote:
The promise of blockchain is fraud-resistant recordkeeping, database management,
Hi Jimmy, That is -so- not the case. The single most important concept in fraud resistance is reversibility. Once a transaction is determined to be fraudulent, the authority making the determination must be able to reverse the transaction. Banks bouncing a check. The tax records office restoring ownership of a house upon order by the court. Blockchain's objective was to make transactions non-repudiable and they succeeded. However, that interacts with its decentralized nature to make those transactions irreversible as well. Bitcoins have been stolen from exchanges. The fraud can't be reversed. Blockchain is not resistant to fraud. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>
Blockchain's objective was to make transactions non-repudiable and > they succeeded. However, that interacts with its decentralized
nature to make those transactions irreversible as well.
To re-use your example, banks don't "delete" the record of the bad check, they just create an offsetting journal entry, as both records are important to preserve. A transaction ledger is supposed to authenticate *every* transaction, and if you need to create an offsetting transaction, you do so in the same manner, and process the result in your code .. but the "bad" transaction DID happen as did your "deletion" of it, and as such, both actions are recorded. To apply to a real-world example .. Betty votes for X, but it's later determined that Betty was ineligible because (whatever). Betty's vote is recorded, as is the administrative cancellation thereof. It's critical that both transactions be recorded, attributed, non-reputeable. The system isn't designed to prevent fraud *itself*, it's designed to prevent alteration of the ledger. Regards, Michael Holstein CISSP Mgr. Network & Data Security Cleveland State University
You're precisely right Michael. People who say blockchain doesn't solve any real world problems, haven't tried solving the problems Block chain so handily tackles using some other method. Trust is a huge vulnerability, as we have seen over and over in the crypto biz. In aviation, for example, we use blockchain now to authenticate parts used in maintenance, repair, and overhaul (MRO). Because trust (in the supply chain) failed us, and unsafe counterfeit parts have flooded the market, making this a life or death problem. -mel beckman On Jan 23, 2018, at 8:12 AM, Michael O Holstein <michael.holstein@csuohio.edu> wrote:
Blockchain's objective was to make transactions non-repudiable and > they succeeded. However, that interacts with its decentralized
nature to make those transactions irreversible as well.
To re-use your example, banks don't "delete" the record of the bad check, they just create an offsetting journal entry, as both records are important to preserve.
A transaction ledger is supposed to authenticate *every* transaction, and if you need to create an offsetting transaction, you do so in the same manner, and process the result in your code .. but the "bad" transaction DID happen as did your "deletion" of it, and as such, both actions are recorded.
To apply to a real-world example .. Betty votes for X, but it's later determined that Betty was ineligible because (whatever). Betty's vote is recorded, as is the administrative cancellation thereof. It's critical that both transactions be recorded, attributed, non-reputeable.
The system isn't designed to prevent fraud *itself*, it's designed to prevent alteration of the ledger.
Regards,
Michael Holstein CISSP Mgr. Network & Data Security Cleveland State University
On Tue, Jan 23, 2018 at 11:12 AM, Michael O Holstein <michael.holstein@csuohio.edu> wrote:
Blockchain's objective was to make transactions non-repudiable and > they succeeded. However, that interacts with its decentralized nature to make those transactions irreversible as well.
To re-use your example, banks don't "delete" the record of the bad check, they just create an offsetting journal entry, as both records are important to preserve.
The system isn't designed to prevent fraud *itself*, it's designed to prevent alteration of the ledger.
Hi Michael, That's correct, and in the bank scenario the bank acting as an authority is able make additions the the ledger which reverse the transaction. In blockchain, there is no central authority and there's a cryptographic guarantee than only the most recent holder of the block may add to the block's ledger. As a consequence, non-repudiability escalates to irreversibility making the system vulnerable to fraud perpetrated by anyone who can briefly gain access to a block's current credentials. If someone steals my credit card, I don't end up paying a nickel. If someone steals my bitcoin wallet, I'm f******. Given the cost of renumbering, we'd have to be insane to depend on blockchain for address management. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>
On 2018-01-23 08:17, Jimmy Hess wrote:
The promise of blockchain is fraud-resistant recordkeeping, database management, AND resource management maintained by a distributed decentralized network which eliminates or reduces the extent to which there are central points of trust involved in the recordkeeping,
Current distributed "block chain" systems are architecturally insecure, but with the requirement of computationally intensive "proof of work", reduce risk of someone succesfully tampering a block to near 0. However, to put things in perspective: Hydro Québec recently revealed that it was not interested in "bitcoin mining" operations in Québec which consume inordinate amount of power without producing anything of value.
Under the current system, they retain an Unwarranted level of trust, for example: ARIN Could Delete an IP address allocation or an AS number allocation after it was assigned, because someone else told them to,
A recent case in Canada had the supreme court order Google to remove a domain name from worldwide searches (so extra territorial court powers). (rogue company stole product design freom real company, refused to appear in court, so real company went to court asking Google to remove that rogue compamy from searches). The correct way would have been to get warrant on the registrar to take the domain name out of the onwer's hands. Or go after the web site provider. When the legal system starts to go after the wrong people"/process to enforce law, you get problems. There may be impulse to make the Internet "government proof", but this will simply shift government actions to more inappropriate but still avaialble methods of trying to enforce the law.
For example: A DNS Registrar or TLD Registry could make a change to the DS Key or remove the DS Key and confiscate a domain to intercept traffic, without even the permission of the original registrant.
Choose your registrar/regitry who will only take actiosn with valid court orders and otherwise protect your privacy.
participants (11)
-
Anthony Kolka - Handy Networks LLC -
Brock Tice -
Christopher Morrow -
Jean-Francois Mezei -
Jimmy Hess -
John R. Levine -
K. Scott Helms -
Mel Beckman -
Michael O Holstein -
valdis.kletnieks＠vt.edu -
William Herrin