Verifiable Network Function Outsourcing Seyed K. Fayazbakhsh Michael K. Reiter Vyas Sekar 1

advertisement
Verifiable Network Function Outsourcing
Seyed K. Fayazbakhsh
Michael K. Reiter Vyas Sekar
1
Case for Network Function Outsourcing (NFO)
Today:
High CapEx, OpEx,
Delay in innovation
Cloud Provider
Internet
+ Economies of scale, pay-per use
+ Simplifies configuration & deployment
2
Concerns with ceding control
Cloud Provider
Internet
e.g., Is this equivalent to in-house?
e.g., Am I really getting cost reduction?
3
Our Vision: Verifiable NFO
• Our focus is meeting customer expectations
• Key correctness properties:
– Behavior
– Performance
– Accounting
• Other issues outside our scope:
isolation, privacy, bandwidth costs ..
4
What makes this challenging?
• Lack of visibility into the workload
• Dynamic, traffic-dependent, and potentially
proprietary actions of the middleboxes
• Stochastic effects introduced by the network
5
Outline
• Motivation for verifiable NFO
• Formalizing properties
• A roadmap for vNFO
• Ongoing work and discussion
6
1
2
Our firs
Formal Framework
functions.
Customer(
at the leve
Management
of theent
stem parameters necessary to specify the formal
Interface
tions.
BCPU, BMem
, BNet
rements of NFO: the sequence
of input packets
Asasta
CPU,
CPU,
) is processed by
a sequence
of
functions
(i.e.,
Net
Mem the sequence of processed
Mem
for each p
n the NFO provider;
, ⇡ 2out , . . . ) is then sent
customerf alongσ with
f1 toσthe
• Bla
n
n
1
ntsusageof variousresources(e.g.,
BCPU , BM em ,
….
π1in, π2in,…
π1out, π2out,... Giv
9σi
which serves as a point
CustomerThi
f averifiable NFO by highlighting
the systemthe
and customer
We assume
Net
pac
Spaceto beState
Space
ctsPacket
that need
captured.
Reference
of t
b
tion.
For
instance,
f
ma
implementation
i
hav
Let f : (⇧ ⇥ ⌃ ) ! (⇧ ⇥ ⌃ ) denote a primitive
7
Behavioral equivalence?
Cloud IPS
Customer
Are packets being modified
or incorrectly processed?
8
Blackbox Behavioral Correctness
σ1
π1in
….
σn
π1out
visible to customer
?
σ’1
π1in
….
?
σ’n
Is there some
viable state?
π1out
9
Snapshot Behavioral Correctness
σ1
π1in
….
σn
π1out
visible to customer
σ1
π1in
….
σn
Would I get the
same output?
π1out?
10
Performance impact?
Cloud IPS
Customer
t3
t2
t1
Is the cloud processing introducing delays?
11
Performance Correctness
σ1
π1in,
π2in,…
σ1
π1in, π2in,…
….
….
σn
σn
t1out, t2out,...
π1out, π2out,...
Would it really
take this long?
t’1out, t’2out,...
π1out, π2out,...
observed provider performance ≈ reference performance
12
Accounting correctness?
Cloud IPS
Customer
Is the provider overcharging me?
13
“Did-It” Accounting Correctness
σ1
π1in,
π2in,…
….
σn
π1out, π2out,...
Did It actually
consume?
Charged value of resource r ≈
Consumption of resource r by provider
14
“Should-It” Accounting Correctness
σ1
π1in, π2in,…
….
σn
π1out, π2out,...
Should It really
cost this much?
Consumption of resource r by provider ≈
Consumption of resource r by reference implementation
15
Summarizing Correctness Properties
• Behavioral correctness
– Blackbox: Function states are not visible to customer.
– Snapshot: Function states are visible to customer
• Performance correctness
– Is performance metric within Δ (SLA) of reference?
• Accounting correctness
– Did-It: Were resources actually consumed?
– Should-It: Was the consumption necessary?
16
Outline
• Motivation for NFO + vNFO
• Formalizing vNFO properties
• A roadmap for vNFO
• Ongoing work and discussion
17
Verifiable NFO (vNFO) Overview
Management
Interface
CPU,
Mem
BCPU, BMem, BNet
CPU,
Mem
Net
….
π1in, π2in,…
π1out, π2out,...
Customer
Each function is implemented as a virtual appliance.
NFO provider deploys a trusted shim for logging.
18
Idealized view
Management
Interface
CPU,
Mem
BCPU, BMem, BNet
CPU,
Mem
Net
….
π1in, π2in,…
π1out, π2out,...
Customer
Shim logs every packet, instantaneous VM state, and
resource usage, timestamps per packet
19
Challenges with Idealized view
Management
Interface
CPU,
Mem
BCPU, BMem, BNet
CPU,
Mem
Net
….
π1in, π2in,…
π1out, π2out,...
Customer
1. Middlebox actions make it difficult to correlate logs
2. Scalability and performance impact due to logging
20
Potential solutions to challenges
1. Lack of visibility into middlebox actions:
– Packets may be modified by middleboxes.
FlowTags
1. Scalability
– Infeasible to log all packets and processing stats.
Trajectory Sampling
21
Ongoing work
• Leveraging nested virtualization
– NFO provider does not need any platform change
• Adding hooks to KVM
– Trustworthy accounting (CPU, memory)
– Trajectory sampling + FlowTags
– Instantaneous snapshotting
• Benchmark memory/time overheads associate with:
– Packet sampling
– Resource consumption calculations
– Snapshotting
22
Discussion
• Does the customer trust the NFO provider?
• Is the NFO provider willing to deploy the shim layer?
– Market forces: Premium service, competitive edge, etc.
• What are the market factors for customers?
– Can customer easily switch to a different NFO provider?
• What is the role of SLA?
– Can the billed amount always be formulated in terms of
resource consumption?
• …
23
Download