Proof of Backhaul Trustfree Measurement of Broadband Bandwidth Peiyao Sheng1Nikita Yadav12Vishal Sevani1Arun Babu1 SVR Anand1Himanshu Tyagi12Pramod Viswanath1

2025-05-02 0 0 536.53KB 15 页 10玖币

侵权投诉

Proof of Backhaul: Trustfree Measurement of Broadband Bandwidth

Peiyao Sheng1,Nikita Yadav1,2,Vishal Sevani1,Arun Babu1,

SVR Anand1,Himanshu Tyagi1,2,Pramod Viswanath1

1Kaleidoscope Blockchain Inc., 2Indian Institute of Science

Abstract

Recent years have seen the emergence of decentralized wire-

less networks consisting of nodes hosted by many individuals

and small enterprises, reawakening the decades-old dream

of open networking. These networks have been deployed in

an organic, distributed manner and are driven by new eco-

nomic models resting on tokenized incentives. A critical re-

quirement for the incentives to scale is the ability to prove

network performance in a decentralized “trustfree" manner,

i.e., a Byzantine fault tolerant network telemetry system.

In this paper, we present a Proof of Backhaul (PoB) proto-

col which measures the bandwidth of the (broadband) back-

haul link of a wireless access point, termed prover, in a de-

centralized and trustfree manner. In particular, our proposed

protocol is the ﬁrst one to satisfy the following two proper-

ties: (1) Trustfree. Bandwidth measurement is secure against

Byzantine attacks by collaborations of challenge servers and

the prover. (2) Open. The barrier-to-entry for being a chal-

lenge server is low; there is no requirement of having a low

latency and high throughput path to the measured link. At a

high-level, our protocol aggregates the challenge trafﬁc from

multiple challenge servers and uses cryptographic primitives

to ensure that a subset of challengers or, even challengers and

provers, cannot maliciously modify results in their favor. A

formal security model allows us to establish guarantees of

accurate bandwidth measurement as a function of the fraction

of malicious actors.

We implement our protocol with challengers spread across

geographical locations. Our evaluation shows that our PoB

protocol can verify backhaul bandwidth of upto 1000 Mbps

with less than 8% error using measurements lasting only 100

ms. The measurement accuracy is not affected in the presence

of corrupted challengers. Importantly, the basic veriﬁcation

protocol lends itself to a minor modiﬁcation that can measure

available bandwidth even in the presence of cross-trafﬁc.

Finally, the security guarantees of our PoB protocol output

are naturally composable with “commitments" on blockchain

ledgers, which are commonly used for decentralized networks.

1 Introduction

Decentralized networks have been in the making for decades.

Starting with Software Deﬁned Networking [28,29] to sim-

plify the hardware and open software [38] to facilitate appli-

cation development, ﬁnally real-world deployments of decen-

tralized Internet Service Providers (ISPs) [7] and decentral-

ized Mobile Network Operators (MNOs) [18] have emerged.

These decentralized networks have been made possible by

the convergence of several engineering, business, and policy

developments: the availability of cheap hardware for WiFi

access points, and now even cellular base stations; the avail-

ability of cloud-native orchestration and AAA software [32];

and the availability of lightly licensed spectrum for cellu-

lar communication [16]. However, the real breakthrough in

deployment comes with the emergence of a token-driven in-

centive ecosystem to bootstrap network growth and make

individual hosts provide good network service. The leading

exponent of such growth is the Helium network [18], which

is a multi-RAT network supported by hundreds of thousands

of “hotspots” hosted by individuals.

But a new engineering challenge has emerged – we need

to design secure and decentralized network telemetry. In cen-

trally managed networks, network telemetry is used for perfor-

mance measurement and subsequent optimization. In contrast,

network telemetry plays a more pivotal role in decentralized

networks. It is now needed to ensure that the network nodes

provide the service that they are being paid for. For this pur-

pose, there are two new requirements for decentralized net-

work telemetry:

•Trustfree.

The protocol is secure against Byzantine at-

tacks by the parties involved.

•Open.

The barrier-to-entry for servers participating in

decentralized telemetry is low. In particular, any node

with a “reasonably good" internet connection should be

able to participate.

The measurements that we get as the output of such trust-

free and open network telemetry protocols can be viewed

arXiv:2210.11546v1 [cs.CR] 20 Oct 2022

as a cryptographically secure proof of appropriate network

performance.

In this paper, we focus on measuring a speciﬁc network per-

formance parameter which is of central importance in decen-

tralized wireless network deployments. In such deployments,

users are required to get a broadband connection with appro-

priate bandwidth, as a backhaul for the wireless access point.

But how do we know that the user has indeed set up a good

backhaul connection? Can we simply use any of the existing

techniques from the large body of literature, spanning over

decades, on bottleneck link-throughput measurement? It turns

out none of the existing tools is applicable for our setting;

below we point out shortcomings of prominent techniques

and clarify our contributions.

Comparison with speedtest.

Speedtest (

speedtest.net

) is

a state-of-the-art bandwidth testing tool widely used globally.

Whenever a user (the “prover") sends a measurement request,

a nearby server is selected from a centralized challenger server

pool. The selected server generates trafﬁc continuously until

the target link is saturated. This requires the challenger server

to have a high bandwidth, low latency, low packet loss link

to the prover; this represents a high barrier to becoming a

challenger. Furthermore, the measurements rely on the rates

of sending packets from challengers and acknowledgements

from the prover – an untrustworthy prover or challenger can

adversely impact the measurement. Speedtest and similar

architectures are unsuited for trustfree network telemetry.

Trafﬁc aggregation.

One way to allow more challengers to

participate in the telemetry (and thus being more open) is to

aggregate trafﬁc from multiple challengers. Such aggregation

removes the requirement of high capacity for a single server to

measure high-bandwidth links, by uniting a group of servers to

generate sufﬁcient trafﬁc in parallel. While this technique can

improve the accuracy (e.g., recent works [3,4,49]), the method

is not trustfree: a Byzantine prover can readily manipulate the

measurement results with no check or balance.

Interactive Measurement.

To eliminate the need of trust on

the prover, challengers should interact with other parties in

the network to generate measurements. Popular interactive

telemetry tools such as traceroute [22] and pathchar [21] use

the timing information obtained by combining the Internet

control message protocol’s (ICMP) time-to-live (TTL) and

packet dropped messages to estimate link performance over

the Internet. In particular, challengers estimate the round-trip

time (RTT) to the two end-points of the link to be measured,

the throughput is derived by dividing the packet size by the

difference of RTT

. Secure measurement, resistant to collu-

sion between the prover and challengers, is not guaranteed in

these protocols.

Our contributions.

We present the ﬁrst protocol for mea-

The actual protocol is slightly different: packets of different sizes are

transmitted and linear regression is used to aggregate the measurements,

c.f., [15,21].

suring backhaul bandwidth that satisﬁes the aforementioned

trustfree and open properties, c.f., §3. Broadly, the protocol is

built by implementing the following ideas:

Trafﬁc aggregation. We simultaneously send challenge

trafﬁc from multiple challengers to the prover. The dura-

tion of the challenge is chosen to be sufﬁciently high to

ensure that trafﬁc from all the challengers queues at the

prover’s backhaul link.

Unforgeable probe. The challengers are selected ran-

domly from a larger pool and each sends digital sig-

natures as trafﬁc, so that no other party can forge the

measurement probe. Furthermore, to limit the inﬂuence

of any one challenger, we limit the amount of challenge

trafﬁc that can come from a single challenger.

Short witness. The prover can send a short message to

the challengers to prove that it has received appropriate

amount of data. As will be seen below, our security con-

siderations require us to use a partially veriﬁable hash.

For this purpose, we use a Merkle tree [36].

Robust timing measurement. We estimate the RTT for the

overall challenge by taking median of the RTT measured

by different challengers.

We implement these steps and experimentally validate the

design choices to identify the best performing conﬁguration;

see Figure 1for a depiction. The main contribution of this

work is the trustfree property of the proposed protocol – it

is secure under a rigorous threat model that we outline in

§4. It is interesting to note that, even ignoring the security

requirements, our proposed protocol is the ﬁrst one that can

measure bandwidth of hundreds of Mbps without requiring

any specialized server with high throughput and low latency

for challengers. We further extend this protocol to measure

available bandwidth in the presence of cross-trafﬁc, making

it a truly distributed “speedtest.”

.......

Challenger

Prover

Backhaul link

1k ...

111

Verifier

RTT Measurements Packets Receipt

Figure 1: The multichallenger PoB Protocol.

We analyze the security of our multichallenger PoB proto-

col under a formal threat model which allows any subset of

Technique Secure Challenger BW <Backhaul BW Accuracy

Pathchar [15,21,33]7 3 Low

Packet dispersion based [12,13,31,42]7 7 –

Secure BW estimation [26,45,50]3 7 –

Multichallenger PoB 3 3 High

(a)

Backhaul BW Challenger BW Challenge Data Attack Measured BW Guaranteed BW

(Mbps) (Mbps) (MB) (Error %) (Mbps)

250 25 3.44 –246 (1.6%) 184

500 20 6.86 –475 (5%) 356

750 75 10.31 –705 (6%) 529

1000 100 13.75 –921 (8%) 691

250 32 3.44 Rushing 331 (0.6%) 249

250 32 3.44 Withholding 241 (3.6%) 181

(b)

Figure 2: (a) Comparison of our multichallenger PoB protocol with prior-art techniques. (b) Summary of our performance results

with 10 challengers. We perform attacks with 2 corrupted challengers.

parties (up to 1/3 challengers collaborating with the prover)

to maliciously deviate from the protocol. Since our probe is

unforgeable, a corrupted prover still must get probe packets

from the challengers. However, corrupted challengers, too,

can modify the packet ﬂow using two attacks: (i) the with-

holding attack where a corrupted challenger does not send

probe packets; and (ii) the rushing attack where a corrupted

challenger coordinates with the corrupted prover to send the

packets or their information quickly without using the chal-

lenged link. To compensate for the withholding attack, we

must send more packets than the link bandwidth to have sufﬁ-

cient trafﬁc even after withholding attack. To compensate for

the rushing attack, we multiply the actual measured bandwidth

with a correction factor to arrive at the guaranteed bandwidth.

In addition, corrupted challengers can modify their outputs

needed for veriﬁcation. Speciﬁcally, they may report wrong

RTT or they may claim modiﬁed packet data. We circumvent

the former attack by taking a median of the measurements.

To circumvent the latter attack, we use a Merkle tree which

allows us to verify the consistency of the hash response from

the prover with the data of uncorrupted challengers, without

requiring correct data from the corrupted ones.

Overall, denoting the fraction of corrupted challengers by

, we show that for

β<1/32

, our protocol does not allow any

prover to inﬂate the bandwidth and allows an honest prover

to establish at least a fraction

(1−2β)/(1−β)

of the true

bandwidth.

Implementation and evaluation.

To convert the idealized

protocol into a practical tool, we implement a variant of our

protocol designed to address real-world issues (§5) and thor-

oughly evaluate its performance (§6). For instance of a real-

world challenge, measuring links with 100 Mbps and higher

We remark that the adversarial threshold can be

1/2

if the veriﬁer has

access to a timer. See the discussion in §4.2.

bandwidth (commonplace in broadband services) requires

latency measurements with an accuracy that is hard to achieve

due to jitter in the Internet; we elaborate on overcoming this

challenge in §6.1.

In our evaluation, we focus on the loss of measurement

accuracy when using multiple challengers and trafﬁc aggre-

gation; in particular, we consider the loss of accuracy due

to: (i) time synchronization errors and network jitter; (ii)

computation time delays due to the use of digital signatures,

hash computation, veriﬁcation, and Merkle trees; and (iii)

geographically spread challengers with heterogeneous capa-

bilities. We also implement rushing and withholding attacks

to illustrate that the security guarantees of the theory hold in

practice. Our main experimental results are summarized in

Figure 2. We report both the actual measured bandwidth and

the output of our protocol – the guaranteed bandwidth – which

is obtained by applying the correction factor

(1−2β)/(1−β)

2 Background and Related Work

Bandwidth estimation.

The term bandwidth in the context

of data networks quantiﬁes the amount of data a network path

can transfer per unit of time. Two metrics related to bandwidth

are extensively investigated in the literature, the maximum

possible data rate called capacity and the maximum available

data rate called available bandwidth [42]. Packet dispersion

techniques [12,13,27,31,44] are widely used to measure the

capacity of the bottleneck link in a network path. Some of

the techniques to measure available bandwidth are outlined

in [3,8,10,20,23,24,34,35,43,46,48,49]. Of these, tools such

as Pathload [23,24] and Pathchirp [43] create a short trafﬁc

load with different stream rates and observe the differences

of one-way delay to adjust estimations. The state-of-the-art

commercial tool Speedtest [8] employs a pool of servers with

文档加载中……请稍候！
如果长时间未打开，您也可以点击刷新试试。

下载文档到电脑，查找使用更方便

10 玖币 0人已下载

立即下载

摘要：

ProofofBackhaul:TrustfreeMeasurementofBroadbandBandwidthPeiyaoSheng1,NikitaYadav1;2,VishalSevani1,ArunBabu1,SVRAnand1,HimanshuTyagi1;2,PramodViswanath11KaleidoscopeBlockchainInc.,2IndianInstituteofScienceAbstractRecentyearshaveseentheemergenceofdecentralizedwire-lessnetworksconsistingofnodeshostedby...

展开>> 收起<<

Proof of Backhaul Trustfree Measurement of Broadband Bandwidth Peiyao Sheng1Nikita Yadav12Vishal Sevani1Arun Babu1 SVR Anand1Himanshu Tyagi12Pramod Viswanath1.pdf

共15页,预览3页

还剩页未读，继续阅读

声明：本站为文档C2C交易模式，即用户上传的文档直接被用户下载，本站只是中间服务平台，本站所有文档下载所得的收益归上传人(含作者)所有。玖贝云文库仅提供信息存储空间，仅对用户上传内容的表现方式做保护处理，对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私，请立即通知玖贝云文库，我们立即给予删除！

Proof of Backhaul Trustfree Measurement of Broadband Bandwidth Peiyao Sheng1Nikita Yadav12Vishal Sevani1Arun Babu1 SVR Anand1Himanshu Tyagi12Pramod Viswanath1

相关推荐

开通VIP享超值会员特权

作者详情

相关内容

热门标签

举报选择: