Re: Blockchain and Networking

[Anthony Kolka - Handy Networks LLC]

When your trying to find a use for your new hammer; everything tends to look 
like nails.

Anthony Kolka
Systems Engineer
303-414-6904
anth...@handynetworks.com
https://www.handynetworks.com





On Jan 24, 2018, at 1:28 PM, 
valdis.kletni...@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 due to (insert valid reason here)"?

Re: Blockchain and Networking

[valdis . kletnieks]

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)"?




pgpMuMZCXCzX6.pgp
Description: PGP signature

Re: Blockchain and Networking

[Christopher Morrow]

On Tue, Jan 23, 2018 at 8:19 PM, Christopher Morrow  wrote:

>
>
> On Tue, Jan 23, 2018 at 6:27 PM, Jimmy Hess  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...

Re: Blockchain and Networking

[Christopher Morrow]

On Tue, Jan 23, 2018 at 6:27 PM, Jimmy Hess  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)

Re: Blockchain and Networking

[K. Scott Helms]

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  wrote:

> On Tue, Jan 23, 2018 at 9:39 AM, John R. Levine  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
>

Re: Blockchain and Networking

[Jimmy Hess]

On Tue, Jan 23, 2018 at 9:39 AM, John R. Levine  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

Re: Blockchain and Networking

[William Herrin]

On Tue, Jan 23, 2018 at 11:12 AM, Michael O Holstein
 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  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Re: Blockchain and Networking

[Jean-Francois Mezei]

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.

Re: Blockchain and Networking

[Mel Beckman]

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  
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

Re: Blockchain and Networking

[Michael O Holstein]

> 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

Re: Blockchain and Networking

[William Herrin]

On Tue, Jan 23, 2018 at 8:17 AM, Jimmy Hess  wrote:

> On Tue, Jan 9, 2018 at 10:22 AM, William Herrin  wrote:
>
>> On Tue, Jan 9, 2018 at 1:07 AM, John R. Levine  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  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Re: Blockchain and Networking

[John R. Levine]

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  wrote:


On Tue, Jan 9, 2018 at 1:07 AM, John R. Levine  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, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

Re: Blockchain and Networking

[Brock Tice]

On 1/23/2018 6:17 AM, Jimmy Hess wrote:

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 
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

Re: Blockchain and Networking

[Jimmy Hess]

On Tue, Jan 9, 2018 at 10:22 AM, William Herrin  wrote:

> On Tue, Jan 9, 2018 at 1:07 AM, John R. Levine  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

Re: Blockchain and Networking

[Alex White-Robinson]

I'd be interested in applications around ownership of IP space or ASNs, but
there's so many ways to skin that cat already that people don't do because
it's 'hard' or 'reduces our flexibility' or sometimes because it involves
hardware upgrades as Christopher Morrow pointed out with RPKI and BGPsec.

On Thu, Jan 18, 2018 at 2:20 AM, Fredrik Korsbäck  wrote:

> On 2018-01-13 03:26, Christopher Morrow wrote:
>
>> On Fri, Jan 12, 2018 at 5:20 PM,  wrote:
>>
>> On Thu, 11 Jan 2018 15:28:19 -0500, William Herrin said:
>>>
 On Thu, Jan 11, 2018 at 2:46 PM, Dale W. Carder 
 wrote:

>
> Traceroute or any other path diagnostics comes to mind.
>

>>> That's not obvious to me. Assuming the time-exceeded message was modified
 to include the necessary data, how would blockchain authenticate the
 responding router?

>>>
>>> And do you really want to do *all* that on every single 'TTL Exceeded'
>>> ICMP?  Sounds like
>>> a *really* easy way to DDoS a router
>>>
>>>
>> pish-posh! the asics will do it.
>>
>>
> Apparently we are not keeping up with the cool kids here.
>
> https://www.openct.io/
>
> * Open in the name
> * .IO TLD
> * A scrolling website
>
> It all checks out as a legitimate web3.0 biz
>
> ###
>
> * Blockchain as a Transport (BaaT): BaaT leverages blockchain to create an
> architecture that can connect geographically dispersed Layer 2 islands over
> any available infrastructure, including the public Internet. As the
> resulting solution securely supports all kinds of traffic: Unicast,
> Multicast and Broadcast - BaaT will become the transport service of choice
> for all businesses.
>
> * Blockchain-Defined Wide Area Networks (BD-WAN): BD-WAN integrates
> blockchain with Software-Defined WAN (SD-WAN) for a secure, scalable
> virtualization of WAN transport technologies. Among the unique features
> (not available with most SD-WAN architectures):
>
> The ability to dynamically establish and tear down logical and physical
> circuits so customers pay only for what they consume.
>
> * Inter-Domain MPLS Traffic Engineering via blockchain (near zero time
> delay).
>
> Trusted per-usage billings that are verified and hard-coded over the
> blockchain.
>
> Full visibility and control over all transport facilities either via Fiber
> to the Premises (FTTP) or via partnership with key telco operators and
> metro Ethernet providers worldwide.
>
> Bringing public cloud and content services seamlessly to the customers'
> doorstep as part of the standard offering.
>
>
> ###
>
>
> I wanna buy all of these stuff right now!
>
>
> --
> hugge
>
>

Re: Blockchain and Networking

[Fredrik Korsbäck]

On 2018-01-13 03:26, Christopher Morrow wrote:

On Fri, Jan 12, 2018 at 5:20 PM,  wrote:


On Thu, 11 Jan 2018 15:28:19 -0500, William Herrin said:

On Thu, Jan 11, 2018 at 2:46 PM, Dale W. Carder  wrote:


Traceroute or any other path diagnostics comes to mind.



That's not obvious to me. Assuming the time-exceeded message was modified
to include the necessary data, how would blockchain authenticate the
responding router?


And do you really want to do *all* that on every single 'TTL Exceeded'
ICMP?  Sounds like
a *really* easy way to DDoS a router



pish-posh! the asics will do it.



Apparently we are not keeping up with the cool kids here.

https://www.openct.io/

* Open in the name
* .IO TLD
* A scrolling website

It all checks out as a legitimate web3.0 biz

###

* Blockchain as a Transport (BaaT): BaaT leverages blockchain to create an architecture that can connect geographically 
dispersed Layer 2 islands over any available infrastructure, including the public Internet. As the resulting solution 
securely supports all kinds of traffic: Unicast, Multicast and Broadcast - BaaT will become the transport service of 
choice for all businesses.


* Blockchain-Defined Wide Area Networks (BD-WAN): BD-WAN integrates blockchain with Software-Defined WAN (SD-WAN) for a 
secure, scalable virtualization of WAN transport technologies. Among the unique features (not available with most SD-WAN 
architectures):


The ability to dynamically establish and tear down logical and physical circuits so customers pay only for what they 
consume.


* Inter-Domain MPLS Traffic Engineering via blockchain (near zero time delay).

Trusted per-usage billings that are verified and hard-coded over the blockchain.

Full visibility and control over all transport facilities either via Fiber to the Premises (FTTP) or via partnership 
with key telco operators and metro Ethernet providers worldwide.


Bringing public cloud and content services seamlessly to the customers' 
doorstep as part of the standard offering.


###


I wanna buy all of these stuff right now!


--
hugge

Re: Blockchain and Networking

[Christopher Morrow]

On Fri, Jan 12, 2018 at 5:20 PM,  wrote:

> On Thu, 11 Jan 2018 15:28:19 -0500, William Herrin said:
> > On Thu, Jan 11, 2018 at 2:46 PM, Dale W. Carder  wrote:
> > >
> > > Traceroute or any other path diagnostics comes to mind.
>
> > That's not obvious to me. Assuming the time-exceeded message was modified
> > to include the necessary data, how would blockchain authenticate the
> > responding router?
>
> And do you really want to do *all* that on every single 'TTL Exceeded'
> ICMP?  Sounds like
> a *really* easy way to DDoS a router
>

pish-posh! the asics will do it.

Re: Blockchain and Networking

[valdis . kletnieks]

On Thu, 11 Jan 2018 15:28:19 -0500, William Herrin said:
> On Thu, Jan 11, 2018 at 2:46 PM, Dale W. Carder  wrote:
> >
> > Traceroute or any other path diagnostics comes to mind.

> That's not obvious to me. Assuming the time-exceeded message was modified
> to include the necessary data, how would blockchain authenticate the
> responding router?

And do you really want to do *all* that on every single 'TTL Exceeded' ICMP?  
Sounds like
a *really* easy way to DDoS a router


pgp2reTgCcYbW.pgp
Description: PGP signature

Re: Blockchain and Networking

[William Herrin]

On Thu, Jan 11, 2018 at 2:44 PM, Miles Fidelman 
wrote:

> Transferring log files, used as forensic evidence, comes to mind.
>

Blockchain is no better at transferring log files than regular PKI.

Blockchain could be used to authenticate that forensic evidence presented
later is the same evidence that was originally logged by the individual who
collected it where the agency responsible for custody of the evidence is
not trusted or where there have been claims evidence tampering. Interesting
law enforcement application. Dubious utility in networking where the
networking staff are a trusted authority.


Any kind of paperwork, tables, etc. associated with network configuration -
> particularly if you're trying to preserve changes.


AFAICT, blockchain is no better at this than regular PKI and regular PKI is
much less expensive to operate.


On Thu, Jan 11, 2018 at 2:46 PM, Dale W. Carder  wrote:
>
> Traceroute or any other path diagnostics comes to mind.


That's not obvious to me. Assuming the time-exceeded message was modified
to include the necessary data, how would blockchain authenticate the
responding router?

Regards,
Bill Herrin



-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Re: Blockchain and Networking

[Dale W. Carder]

Traceroute or any other path diagnostics comes to mind.

Dale

Thus spake Tom Beecher (beec...@beecher.cc) on Thu, Jan 11, 2018 at 12:22:43PM 
-0500:
> "Blockchain is great at proving chain of custody, but when do you need to do
> that in computer networking?"
> 
> This is the most important question to ask. Everything else is just
> buzzwordy shenanigans.
> 
> On Mon, Jan 8, 2018 at 12:52 AM, William Herrin  wrote:
> 
> > On Mon, Jan 8, 2018 at 12:26 AM, Glen Kent  wrote:
> >
> > > Do folks on this list see blockchain technology making inroads into the
> > > networking? I can see blockchain being used to secure the SDN environment
> > > where blockchain will allow encrypted data transfers between nodes (ones
> > > hosting different applications, the SDN controller, the data plane
> > devices)
> > > regardless of the network size or its geographical distribution.
> > >
> >
> > Hi Glen,
> >
> > I'm having trouble envisioning a scenario where blockchain does that any
> > better than plain old PKI.
> >
> > Blockchain is great at proving chain of custody, but when do you need to do
> > that in computer networking?
> >
> > Regards,
> > Bill Herrin
> >
> >
> > --
> > William Herrin  her...@dirtside.com  b...@herrin.us
> > Dirtside Systems . Web: 
> >

Re: Blockchain and Networking

[Miles Fidelman]

Transferring log files, used as forensic evidence, comes to mind.

Any kind of paperwork, tables, etc. associated with network 
configuration - particularly if you're trying to preserve changes.



On 1/11/18 10:22 AM, Tom Beecher wrote:

"Blockchain is great at proving chain of custody, but when do you need to do
that in computer networking?"

This is the most important question to ask. Everything else is just
buzzwordy shenanigans.

On Mon, Jan 8, 2018 at 12:52 AM, William Herrin  wrote:


On Mon, Jan 8, 2018 at 12:26 AM, Glen Kent  wrote:


Do folks on this list see blockchain technology making inroads into the
networking? I can see blockchain being used to secure the SDN environment
where blockchain will allow encrypted data transfers between nodes (ones
hosting different applications, the SDN controller, the data plane

devices)

regardless of the network size or its geographical distribution.


Hi Glen,

I'm having trouble envisioning a scenario where blockchain does that any
better than plain old PKI.

Blockchain is great at proving chain of custody, but when do you need to do
that in computer networking?

Regards,
Bill Herrin


--
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 



--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Re: Blockchain and Networking

[Tom Beecher]

"Blockchain is great at proving chain of custody, but when do you need to do
that in computer networking?"

This is the most important question to ask. Everything else is just
buzzwordy shenanigans.

On Mon, Jan 8, 2018 at 12:52 AM, William Herrin  wrote:

> On Mon, Jan 8, 2018 at 12:26 AM, Glen Kent  wrote:
>
> > Do folks on this list see blockchain technology making inroads into the
> > networking? I can see blockchain being used to secure the SDN environment
> > where blockchain will allow encrypted data transfers between nodes (ones
> > hosting different applications, the SDN controller, the data plane
> devices)
> > regardless of the network size or its geographical distribution.
> >
>
> Hi Glen,
>
> I'm having trouble envisioning a scenario where blockchain does that any
> better than plain old PKI.
>
> Blockchain is great at proving chain of custody, but when do you need to do
> that in computer networking?
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin  her...@dirtside.com  b...@herrin.us
> Dirtside Systems . Web: 
>

Re: Blockchain and Networking

[Saku Ytti]

On 11 January 2018 at 00:54, Filip Hruska  wrote:

> You can't just run normal software on ASICs. It's not a computer. They're
> literally hard-wired to do one thing - and do it well.
> Switch ASICs, for example, are good for switching network packets around.
> Though (I would assume) they
> can't do any kind of hashing, much less Bitcoin-specific stuff.

You're probably right that Switch ASICs would not be able to do any
BTC stuff. But most of them do use hashes, MACs are in hash tables
often, balancing requires hashes. There is also somewhat hazy
definition what is ASIC and what is NPU, NPU boxes are large
collection of same chips, and chips are executing same software to
completion, they can do anything, just matter of how long it takes and
how effective they are doing it, they certainly wouldn't be practical
BTC miners..


-- 
  ++ytti

Re: Blockchain and Networking

[Filip Hruska]

Application Specific Integrated Circuit. It's even in the name!

You can't just run normal software on ASICs. It's not a computer. 
They're literally hard-wired to do one thing - and do it well.
Switch ASICs, for example, are good for switching network packets 
around. Though (I would assume) they

can't do any kind of hashing, much less Bitcoin-specific stuff.

Trying to mine Bitcoin on switch ASICs would be like trying to transfer
water through a 2.4GHz WiFi connection - both are absolutely 
preposterous ideas.



Regards

--
Filip Hruska
Linux System Administrator

Dne 1/9/18 v 17:02 Michael Crapse napsal(a):

The definition of an ASIC is that it has only one use. Just because half of
a 100gb switch is not in use doesn't mean that you can mine bitcoin, or run
a blockchain with the asics not in use..

On 9 January 2018 at 08:49, Jean | ddostest.me via NANOG 
wrote:


BTC miners use asics. Big switches/routers use 100Gb asics. Some
switches have multiple 100 Gb asics and sometimes only half is use or
even less.

I guess it could be nice for some smaller telcos to generate some profit
during off peak period. I don't know how feasible and I fully understand
that the vendor warranty should be instantly void.

Also, sometimes telcos have off the shelves spare that gather dust for
years... It could be interesting to also generate few coins.

Jean

On 18-01-09 10:31 AM, Naslund, Steve wrote:

Sure but there are lots of blockchains other than bitcoin.  A lot of

real smart people do not even suspect that bitcoin is a long term survivor
due to its long transaction times.  Which blockchains do you want to
support?  150GB may not seem like a lot (although a lot of my gear does not
have the memory to cache that) but 10 of those is beyond the memory on the
vast majority of network gear I am aware of.  That sure looks like a
slippery slope to me.   Now that a lot of network switching and routers can
support applications, you could just host all of your apps on them just
like you could do all of your routing in your servers.   The question for
you is what responsibilities do you want to take on.   That probably
depends on what business you are in.

There is absolutely no reason that the networking equipment itself

can't both operate the blockchain and keep a full copy.  It's a pretty good
bet that your own routers will probably be online;  if not, you have bigger
problems.

The storage requirements aren't particularly onerous.  The entire

Bitcoin blockchain is around 150GB, with several orders of magnitude more
transactions (read: config changes) than you're likely to see even on a
very large network.  SSDs are small >enough and reliable enough now that
the physical space requirements are quite small.

Steven Naslund
Chicago IL

Re: Blockchain and Networking

[Christopher Morrow]

On Tue, Jan 9, 2018 at 11:22 AM, William Herrin  wrote:

> On Tue, Jan 9, 2018 at 1:07 AM, John R. Levine  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  her...@dirtside.com  b...@herrin.us
> Dirtside Systems . Web: 
>

Re: Blockchain and Networking

[Jörg Kost]

New devices like the former Brocade SLX even has its own hypervisor on 
x86-intel and runs an Ubuntu VM for management and monitoring. You can 
even install your own things,  therefore new applications and purposes 
will rise in the future.


I also believe that dockerization will come to the networks and we will  
handle routing protocols more like containers that will be linked to the 
host-os, adding  reseller and namespace capabilities and so on.


There will be room for blockchain typeof-handlers that does not need to 
be a "full node" or a "miner". It could just be a "wallet"-type, that is 
linked to companies-internal-"light" nodes, to exchanges or registries 
or $y for purposes, that we might not even think of right now or still 
need to write PoC for (remind me in $x years).


Jörg


On 9 Jan 2018, at 16:31, Naslund, Steve wrote:

Sure but there are lots of blockchains other than bitcoin.  A lot of 
real smart people do not even suspect that bitcoin is a long term 
survivor due to its long transaction times.  Which blockchains do you 
want to support?  150GB may not seem like a lot (although a lot of my 
gear does not have the memory to cache that) but 10 of those is beyond 
the memory on the vast majority of network gear I am aware of.  That 
sure looks like a slippery slope to me.   Now that a lot of network 
switching and routers can support applications, you could just host 
all of your apps on them just like you could do all of your routing in 
your servers.   The question for you is what responsibilities do you 
want to take on.   That probably depends on what business you are in.


There is absolutely no reason that the networking equipment itself 
can't both operate the blockchain and keep a full copy.  It's a 
pretty good bet that your own routers will probably be online;  if 
not, you have bigger problems.


The storage requirements aren't particularly onerous.  The entire 
Bitcoin blockchain is around 150GB, with several orders of magnitude 
more transactions (read: config changes) than you're likely to see 
even on a very large network.  SSDs are small >enough and reliable 
enough now that the physical space requirements are quite small.


Steven Naslund
Chicago IL

Re: Blockchain and Networking

[William Herrin]

On Tue, Jan 9, 2018 at 1:07 AM, John R. Levine  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  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Re: Blockchain and Networking

[Brian Kantor]

It seems to me that at the current moment in the evolution of bitcoin, the
only way to make money from it is to sell the equipment to mine coins, as
the chances of ever making any money from mining coins yourself are
vanishingly small.  And then only if you get your electricity and cooling
for free.

It has been estimated that the amount of electricity being consumed worldwide
in the attempt to mine bitcoins exceeds the consumption of several smaller
European countries.  Since little of this power is generated from renewable
sources, it could represent a significant consumption of fossil fuels.
- Brian


On Tue, Jan 09, 2018 at 10:49:52AM -0500, Jean | ddostest.me via NANOG wrote:
> BTC miners use asics. Big switches/routers use 100Gb asics. Some
> switches have multiple 100 Gb asics and sometimes only half is use or
> even less.
> 
> I guess it could be nice for some smaller telcos to generate some profit
> during off peak period. I don't know how feasible and I fully understand
> that the vendor warranty should be instantly void.
> 
> Also, sometimes telcos have off the shelves spare that gather dust for
> years... It could be interesting to also generate few coins.
> 
> Jean

Re: Blockchain and Networking

[Michael Crapse]

The definition of an ASIC is that it has only one use. Just because half of
a 100gb switch is not in use doesn't mean that you can mine bitcoin, or run
a blockchain with the asics not in use..

On 9 January 2018 at 08:49, Jean | ddostest.me via NANOG 
wrote:

> BTC miners use asics. Big switches/routers use 100Gb asics. Some
> switches have multiple 100 Gb asics and sometimes only half is use or
> even less.
>
> I guess it could be nice for some smaller telcos to generate some profit
> during off peak period. I don't know how feasible and I fully understand
> that the vendor warranty should be instantly void.
>
> Also, sometimes telcos have off the shelves spare that gather dust for
> years... It could be interesting to also generate few coins.
>
> Jean
>
> On 18-01-09 10:31 AM, Naslund, Steve wrote:
> > Sure but there are lots of blockchains other than bitcoin.  A lot of
> real smart people do not even suspect that bitcoin is a long term survivor
> due to its long transaction times.  Which blockchains do you want to
> support?  150GB may not seem like a lot (although a lot of my gear does not
> have the memory to cache that) but 10 of those is beyond the memory on the
> vast majority of network gear I am aware of.  That sure looks like a
> slippery slope to me.   Now that a lot of network switching and routers can
> support applications, you could just host all of your apps on them just
> like you could do all of your routing in your servers.   The question for
> you is what responsibilities do you want to take on.   That probably
> depends on what business you are in.
> >
> >> There is absolutely no reason that the networking equipment itself
> can't both operate the blockchain and keep a full copy.  It's a pretty good
> bet that your own routers will probably be online;  if not, you have bigger
> problems.
> >>
> >> The storage requirements aren't particularly onerous.  The entire
> Bitcoin blockchain is around 150GB, with several orders of magnitude more
> transactions (read: config changes) than you're likely to see even on a
> very large network.  SSDs are small >enough and reliable enough now that
> the physical space requirements are quite small.
> >
> > Steven Naslund
> > Chicago IL
> >
>

Re: Blockchain and Networking

[Jean | ddostest.me via NANOG]

BTC miners use asics. Big switches/routers use 100Gb asics. Some
switches have multiple 100 Gb asics and sometimes only half is use or
even less.

I guess it could be nice for some smaller telcos to generate some profit
during off peak period. I don't know how feasible and I fully understand
that the vendor warranty should be instantly void.

Also, sometimes telcos have off the shelves spare that gather dust for
years... It could be interesting to also generate few coins.

Jean

On 18-01-09 10:31 AM, Naslund, Steve wrote:
> Sure but there are lots of blockchains other than bitcoin.  A lot of real 
> smart people do not even suspect that bitcoin is a long term survivor due to 
> its long transaction times.  Which blockchains do you want to support?  150GB 
> may not seem like a lot (although a lot of my gear does not have the memory 
> to cache that) but 10 of those is beyond the memory on the vast majority of 
> network gear I am aware of.  That sure looks like a slippery slope to me.   
> Now that a lot of network switching and routers can support applications, you 
> could just host all of your apps on them just like you could do all of your 
> routing in your servers.   The question for you is what responsibilities do 
> you want to take on.   That probably depends on what business you are in.
> 
>> There is absolutely no reason that the networking equipment itself can't 
>> both operate the blockchain and keep a full copy.  It's a pretty good bet 
>> that your own routers will probably be online;  if not, you have bigger 
>> problems.
>>
>> The storage requirements aren't particularly onerous.  The entire Bitcoin 
>> blockchain is around 150GB, with several orders of magnitude more 
>> transactions (read: config changes) than you're likely to see even on a very 
>> large network.  SSDs are small >enough and reliable enough now that the 
>> physical space requirements are quite small.
> 
> Steven Naslund
> Chicago IL
> 

RE: Blockchain and Networking

[Naslund, Steve]

Sure but there are lots of blockchains other than bitcoin.  A lot of real smart 
people do not even suspect that bitcoin is a long term survivor due to its long 
transaction times.  Which blockchains do you want to support?  150GB may not 
seem like a lot (although a lot of my gear does not have the memory to cache 
that) but 10 of those is beyond the memory on the vast majority of network gear 
I am aware of.  That sure looks like a slippery slope to me.   Now that a lot 
of network switching and routers can support applications, you could just host 
all of your apps on them just like you could do all of your routing in your 
servers.   The question for you is what responsibilities do you want to take 
on.   That probably depends on what business you are in.

>There is absolutely no reason that the networking equipment itself can't both 
>operate the blockchain and keep a full copy.  It's a pretty good bet that your 
>own routers will probably be online;  if not, you have bigger problems.
>
>The storage requirements aren't particularly onerous.  The entire Bitcoin 
>blockchain is around 150GB, with several orders of magnitude more transactions 
>(read: config changes) than you're likely to see even on a very large network. 
> SSDs are small >enough and reliable enough now that the physical space 
>requirements are quite small.

Steven Naslund
Chicago IL

Re: Blockchain and Networking

[Hugo Slabbert]

A slightly more pessimistic view:

https://hackernoon.com/ten-years-in-nobody-has-come-up-with-a-use-case-for-blockchain-ee98c180100

--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


signature.asc
Description: Digital signature

Re: Blockchain and Networking

[Christopher Morrow]

(watching this thread and wondering..)

On Tue, Jan 9, 2018 at 2:39 AM, Peter Kristolaitis 
wrote:

> On 2018-01-08 10:19 PM, John Levine wrote:
>
>> In article <0c45eee2-ffcb-2066-1456-eb2d38075...@alter3d.ca>,
>> Peter Kristolaitis   wrote:
>>
>>> We can build all of the above in other ways today, of course.  But
>>> there's certainly something to be said for a vendor-supported solution
>>> that is inherent in the platform and requires no additional
>>> infrastructure. ...
>>>
>> No additional infrastructure?  Blockchains need multiple devices that
>> are online and have enough storage to keep a full copy of the chain.
>>
> There is absolutely no reason that the networking equipment itself can't
> both operate the blockchain and keep a full copy.  It's a pretty good bet
> that your own routers will probably be online;  if not, you have bigger
> problems.
>
>
I don't know that offloading computation on already busy network devices is
a win for the rest of the network though.
I don't know that you want to depend on local storage on devices which
could be thousands of miles away from the people who can replace the
hdd/ssd/storage-item.. especially when that storage is critical to the
operations of the device.

It turns out it's both expensive in time and pesos to fly someone into
west-africa/east-asia/china/texas to repair a device in an emergency
(unplanned work).

The storage requirements aren't particularly onerous.  The entire Bitcoin
> blockchain is around 150GB, with several orders of magnitude more
> transactions (read: config changes) than you're likely to see even on a
> very large network.  SSDs are small enough and reliable enough now that the
> physical space requirements are quite small.
>
>
I really don't think storage is the only problem here, and 'aren't
particularly onerous' overlooks a whole host of actual problems in
operations with blockchains... which just using git/sccs/cvs/etc fixes for
your standard configuration management concerns. All of the
git/sccs/cvs/etc avoid 'lots of storage necessary on remote devices' and
'lots of compute required on remote deices'.


> They make sense in an environment with multiple sophisticated parties
>> that sort of but not entirely trust each other, but there aren't as
>> many of those as you might think.
>>
> You (presumably) trust your own routers.  There is absolutely no reason
> that your own little network can't run your own private blockchain.   In
> fact, for my use case of configuration management, you wouldn't WANT to use
> a single global public blockchain.
>
>
someone 12 messages back asked: "why is this better/different/etc from just
using git/sccs/cvs/etc for configuration management/revision-control?"

I've not seen that answered, except by the speculative: "well, it's a cool
buzzword" comment.


> - Peter
>

Re: Blockchain and Networking

[Peter Kristolaitis]

On 2018-01-08 10:19 PM, John Levine wrote:

In article <0c45eee2-ffcb-2066-1456-eb2d38075...@alter3d.ca>,
Peter Kristolaitis   wrote:

We can build all of the above in other ways today, of course.  But
there's certainly something to be said for a vendor-supported solution
that is inherent in the platform and requires no additional
infrastructure. ...

No additional infrastructure?  Blockchains need multiple devices that
are online and have enough storage to keep a full copy of the chain.
There is absolutely no reason that the networking equipment itself can't 
both operate the blockchain and keep a full copy.  It's a pretty good 
bet that your own routers will probably be online;  if not, you have 
bigger problems.


The storage requirements aren't particularly onerous.  The entire 
Bitcoin blockchain is around 150GB, with several orders of magnitude 
more transactions (read: config changes) than you're likely to see even 
on a very large network.  SSDs are small enough and reliable enough now 
that the physical space requirements are quite small.



They make sense in an environment with multiple sophisticated parties
that sort of but not entirely trust each other, but there aren't as
many of those as you might think.
You (presumably) trust your own routers.  There is absolutely no reason 
that your own little network can't run your own private blockchain.   In 
fact, for my use case of configuration management, you wouldn't WANT to 
use a single global public blockchain.


- Peter

Re: Blockchain and Networking

[John R. Levine]

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, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

Re: Blockchain and Networking

[John Levine]

In article <0c45eee2-ffcb-2066-1456-eb2d38075...@alter3d.ca>,
Peter Kristolaitis   wrote:
>We can build all of the above in other ways today, of course.  But 
>there's certainly something to be said for a vendor-supported solution 
>that is inherent in the platform and requires no additional 
>infrastructure. ...

No additional infrastructure?  Blockchains need multiple devices that
are online and have enough storage to keep a full copy of the chain.

They make sense in an environment with multiple sophisticated parties
that sort of but not entirely trust each other, but there aren't as
many of those as you might think.

-- 
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

Re: Blockchain and Networking

[Jörg Kost]

Hi,

its not only about PKI. There are some currencies in the wild right now, 
that are more scalable than bitcoin and are made for the "ddos" world of 
IoT.


For example a possible BGP extension could use smart contracts to form 
and confirm peering and also handle the direct payment process to the 
upstreams. Things like the DirectCloud of DE-CIX could be replaced by a 
"BGP-Exchange", where "routers" can sell and order services on their own 
and on-demand, for example if the "router" needs suddenly more bits to 
AS$X on a cold winter night.


Also a "$IoT" device like a streaming dongle could order and pay by 
itself and may book the nearest data-"highway" for a PPV-event.


Jörg



On 2018-01-08 08:59, Peter Kristolaitis wrote:

On 2018-01-08 12:52 AM, William Herrin wrote:
I'm having trouble envisioning a scenario where blockchain does that 
any

better than plain old PKI.

Blockchain is great at proving chain of custody, but when do you 
need to do

that in computer networking?

Regards,
Bill Herrin

Re: Blockchain and Networking

[Denys Fedoryshchenko]

Each offsite copy of git repository will give alert then, as all
hashes in chain changed at some moment.
Same principle as blockchain.

On 2018-01-08 09:54, tglas...@earthlink.net wrote:

Uh since MITM Bill perk of custody is key.

//tsg

Sent from my HTC
- Reply message -
From: "Denys Fedoryshchenko" 
To: 
Subject: Blockchain and Networking
Date: Mon, Jan 8, 2018 10:03

On 2018-01-08 08:59, Peter Kristolaitis wrote:

On 2018-01-08 12:52 AM, William Herrin wrote:

I'm having trouble envisioning a scenario where blockchain does

that >> any

better than plain old PKI.
>> Blockchain is great at proving chain of custody, but when do you

need >> to do

that in computer networking?
>> Regards,
Bill Herrin

> There's probably some potential in using a blockchain for things

like

configuration management.  You can authenticate who made what change
and when (granted, we can kinda-sorta do this already with the

various

authentication and logging mechanisms, but the blockchain is an
immutable, permanent record inherently required for the system to

work

at all).
> That immutable, sequenced chain of events would let you do things

like

"make my test environment look like production did last Thursday at
9AM" trivially by reading the blockchain up until that timestamp,

then

running a fork of the chain for the new test environment to track

its

own changes during testing.
> Or when you know you did something 2 months ago for client A, and

you

need your new NOC guy to now do it for client B -- the blockchain
becomes the documentation of what was done.
> We can build all of the above in other ways today, of course.  But
there's certainly something to be said for a vendor-supported

solution

that is inherent in the platform and requires no additional
infrastructure.  Whether or not that's worth the complexities of
managing a blockchain on networking devices is, perhaps, a whole

other

discussion.   :)
> - Peter

Why to reinvent git? :)
Lot of tools available also, to see diff on git commits, to see who
did commit, and what exactly he changed.
(it is possible to cryptographically sign commits, as well, and yes,
they are chain signed, as "blockchain")

Re: Blockchain and Networking

[Denys Fedoryshchenko]

On 2018-01-08 08:59, Peter Kristolaitis wrote:

On 2018-01-08 12:52 AM, William Herrin wrote:
I'm having trouble envisioning a scenario where blockchain does that 
any

better than plain old PKI.

Blockchain is great at proving chain of custody, but when do you need 
to do

that in computer networking?

Regards,
Bill Herrin


There's probably some potential in using a blockchain for things like
configuration management.  You can authenticate who made what change
and when (granted, we can kinda-sorta do this already with the various
authentication and logging mechanisms, but the blockchain is an
immutable, permanent record inherently required for the system to work
at all).

That immutable, sequenced chain of events would let you do things like
"make my test environment look like production did last Thursday at
9AM" trivially by reading the blockchain up until that timestamp, then
running a fork of the chain for the new test environment to track its
own changes during testing.

Or when you know you did something 2 months ago for client A, and you
need your new NOC guy to now do it for client B -- the blockchain
becomes the documentation of what was done.

We can build all of the above in other ways today, of course.  But
there's certainly something to be said for a vendor-supported solution
that is inherent in the platform and requires no additional
infrastructure.  Whether or not that's worth the complexities of
managing a blockchain on networking devices is, perhaps, a whole other
discussion.   :)

- Peter

Why to reinvent git? :)
Lot of tools available also, to see diff on git commits, to see who did 
commit, and what exactly he changed.
(it is possible to cryptographically sign commits, as well, and yes, 
they are chain signed, as "blockchain")

Re: Blockchain and Networking

[Peter Kristolaitis]

On 2018-01-08 12:52 AM, William Herrin wrote:

I'm having trouble envisioning a scenario where blockchain does that any
better than plain old PKI.

Blockchain is great at proving chain of custody, but when do you need to do
that in computer networking?

Regards,
Bill Herrin


There's probably some potential in using a blockchain for things like 
configuration management.  You can authenticate who made what change and 
when (granted, we can kinda-sorta do this already with the various 
authentication and logging mechanisms, but the blockchain is an 
immutable, permanent record inherently required for the system to work 
at all).


That immutable, sequenced chain of events would let you do things like 
"make my test environment look like production did last Thursday at 9AM" 
trivially by reading the blockchain up until that timestamp, then 
running a fork of the chain for the new test environment to track its 
own changes during testing.


Or when you know you did something 2 months ago for client A, and you 
need your new NOC guy to now do it for client B -- the blockchain 
becomes the documentation of what was done.


We can build all of the above in other ways today, of course.  But 
there's certainly something to be said for a vendor-supported solution 
that is inherent in the platform and requires no additional 
infrastructure.  Whether or not that's worth the complexities of 
managing a blockchain on networking devices is, perhaps, a whole other 
discussion.   :)


- Peter

Re: Blockchain and Networking

[chris]

agreed this could have potential to be the next "devops" style buzzword

On Mon, Jan 8, 2018 at 12:38 AM, Hugo Slabbert  wrote:

> >Where else can blockchain be used in networking?
>
> Other uses notwithstanding, it should be good for inflating the share
> price of any network vendor that adds "now with block chain!" somewhere
> into their product portfolio.
>
> /snark
>
> --
> Hugo Slabbert | email, xmpp/jabber: h...@slabnet.com
> pgp key: B178313E | also on Signal
>
> On January 7, 2018 9:26:47 PM PST, Glen Kent  wrote:
> >Hi,
> >
> >Do folks on this list see blockchain technology making inroads into the
> >networking? I can see blockchain being used to secure the SDN
> >environment
> >where blockchain will allow encrypted data transfers between nodes
> >(ones
> >hosting different applications, the SDN controller, the data plane
> >devices)
> >regardless of the network size or its geographical distribution.
> >
> >Where else can blockchain be used in networking?
> >
> >Glen.
>

Re: Blockchain and Networking

[William Herrin]

On Mon, Jan 8, 2018 at 12:26 AM, Glen Kent  wrote:

> Do folks on this list see blockchain technology making inroads into the
> networking? I can see blockchain being used to secure the SDN environment
> where blockchain will allow encrypted data transfers between nodes (ones
> hosting different applications, the SDN controller, the data plane devices)
> regardless of the network size or its geographical distribution.
>

Hi Glen,

I'm having trouble envisioning a scenario where blockchain does that any
better than plain old PKI.

Blockchain is great at proving chain of custody, but when do you need to do
that in computer networking?

Regards,
Bill Herrin


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Re: Blockchain and Networking

[Hugo Slabbert]

>Where else can blockchain be used in networking?

Other uses notwithstanding, it should be good for inflating the share price of 
any network vendor that adds "now with block chain!" somewhere into their 
product portfolio. 

/snark

-- 
Hugo Slabbert | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E | also on Signal

On January 7, 2018 9:26:47 PM PST, Glen Kent  wrote:
>Hi,
>
>Do folks on this list see blockchain technology making inroads into the
>networking? I can see blockchain being used to secure the SDN
>environment
>where blockchain will allow encrypted data transfers between nodes
>(ones
>hosting different applications, the SDN controller, the data plane
>devices)
>regardless of the network size or its geographical distribution.
>
>Where else can blockchain be used in networking?
>
>Glen.


signature.asc
Description: PGP signature