Blockchain and Networking

• Subject: Blockchain and Networking
• From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu)
• Date: Fri, 12 Jan 2018 17:20:28 -0500
• In-reply-to: <CAP-guGVxmUSvgCiH9ZBtNs6OsVgFXCqUOp8oATx9OhCGsezrAg@mail.gmail.com>
• References: <CAPLq3UMioqLCcj2s=jWKoqotiizMCGN8irAiuhDL9Mb5Kt9Rnw@mail.gmail.com> <CAP-guGW+L9u8rGuMwYyySCHHHXLJJXB+ChRi3CUS0woUTaH73w@mail.gmail.com> <CAL9Qcx4Wty=k3df-U_GTJe6nt8wheYhr7X5uBt7o2a9hsx+mSA@mail.gmail.com> <[email protected]> <CAP-guGVxmUSvgCiH9ZBtNs6OsVgFXCqUOp8oATx9OhCGsezrAg@mail.gmail.com>

On Thu, 11 Jan 2018 15:28:19 -0500, William Herrin said:
> On Thu, Jan 11, 2018 at 2:46 PM, Dale W. Carder <dwcarder at es.net> 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....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20180112/8a5fc829/attachment.sig>

• Follow-Ups:
  • Blockchain and Networking
    • From: morrowc.lists at gmail.com (Christopher Morrow)

• References:
  • Blockchain and Networking
    • From: glen.kent at gmail.com (Glen Kent)
  • Blockchain and Networking
    • From: bill at herrin.us (William Herrin)
  • Blockchain and Networking
    • From: beecher at beecher.cc (Tom Beecher)
  • Blockchain and Networking
    • From: mfidelman at meetinghouse.net (Miles Fidelman)
  • Blockchain and Networking
    • From: bill at herrin.us (William Herrin)

• Prev by Date: AS15133 (EdgeCast)?
• Next by Date: Blockchain and Networking
• Previous by thread: Blockchain and Networking
• Next by thread: Blockchain and Networking
• Index(es):
  • Date
  • Thread