Download From NDNS - Internet Research Lab

PhD thesis
defense
Addressing operational
challenges in Named Data
Networking through NDNS
distributed database
Alexander Afanasyev
[email protected]
Wednesday, September 18 th , 2013
Research problem
• Named Data Networking (NDN) uses pure datacentric communication model
– solves many outstanding problems with current
communication patterns
• build-in multicast
• privacy and security
• Deployment of the architecture faces a number of
operational challenges, including
– management of security credentials
– authorization of routing resources (namespace regulation)
– named-based routing scalability
2
Research objective
• Design a universal, scalable, secure, and easy to
use distributed database system for NDN, leveraging
all advantages of NDN
– borrow from DNS that has been working well enough over
last 25 years
• Use it to support solutions of operational problems in
the architecture
–
–
–
–
3
security credential management
scalability of name-based NDN routing
regulate NDN namespace
other solutions to come
Outline
• Part 1: NDNS – scalable, distributed, and generalpurpose database for NDN
–
–
–
–
NDN overview
design
security
evaluation
• Part 2: Applying NDNS to address operational
challenges
– security credential management
– scalability of name-based NDN routing
4
NDNS scalable distributed general-use
database for NDN
Part 1
5
NDN overview: basics
• Two types of packets
– Interest packet
• name
• nonce
• optional selectors
– Data packet
• name
• content
• signature
• Names defined by applications
– /net/ndnsim/www/index.html/...
6
Interest packet
Name
Selectors (opt)
Nonce
Data packet
Name
Content
Signature
NDN overview
• NDN separates
– objective of retrieving
– specifics of how to do it
• Interest names exactly what to fetch
– matching (secured) Data is retrieved by the network
– from caches, in-network storage, or data producers
Cache
s
Interest
Data
7
Innetwork
storage
DNS overview
•
DNS is data-centric (data query, data reply), but on application layer only
– DNS design based on on IP’s point-to-point packet delivery
•
Caching resolver navigates through hierarchy distributed DNS authority servers
to find one who can answer the query
– figuring out exactly which server to ask
– exactly the same questions
Stub
resolvers
root
NS
Caching
resolver
? www.ndnsim.net A
1
2
3
ndnsim.net. A
131.179.196.70
8
.net
NS
.ndnsim.net
NS
DNS  NDNS: What don’t need changes?
• DNS name space and the name space governance
• DNS’s application-level data-centricity matches
directly to NDN’s Interest-Data exchange
• The roles of
– authority server (provided by name owners)
– caching resolver (provided by ISP or service provider)
– stub resolver (inside end nodes)
9
NDNS namespace considerations
• NDN has no restrictions on Data names
• As a design goal, NDNS uses DNS-compatible
names
– DNS already defines a strict hierarchy and name
delegation from TLD, SLDs, etc.
– NDNS do not introduce new naming, rather than taking the
existing names and move them into NDN world
• re-using well-established governance (ICANN, IANA, registrars)
10
DNS  NDNS: What needs to be changed?
•
Data unit and zone management
– DNS uses different data units at different levels:
•
•
•
DNS message (network)
RR set (resolver app)
DNS zone file (name server app)
– NDNS uses Data packets at all levels
•
Iterative query
– NDN Interest cannot be answered with non-explicitly asked data
•
Interest and Data should match
– need to navigate hierarchy without relying on p2p connections
– utilize both network- (routers) and application-level (caching resolver) caches
•
Recursive query
– no need for discovery of local caching resolver
•
Security
– NDN has build-in security for Data fetching
•
11
Mechanism for dynamic zone updates
NDNS components
• NDNS query protocol
• NDNS (authoritative) name servers
• NDNS resolvers
NDNS name space
/
/edu
/net
...
NDN network is not just
delivery mechanism, but
essential part of any NDN
application
• app-network cooperation
• in-network storage
Name servers /
caching resolvers
/net/ndnsim/docs
zone (authority)
/net/ndnsim
/net/ndnsim/docs
12
/net/ndnsim/www
Name servers
(authoritative)
...
NDN
in-network storage
(caches)
Stub resolvers
NDNS (authoritative) name servers
• Playing the same role as in DNS
• Different zone data management
– zone is a collection of RR sets = NDN Data packets
• NDN secures every Data packet
– crypto-signatures should be done in advance
– signatures “seal” RR set
– instead of AXFR-type zone transfers use data-centric
synchronization primitives
• make use of build-in multicast capability of NDN
13
Changes with iterative queries in NDNS
• Iterative query (Interest) requests/fetches RR
set
– RR set = NDN Data packet
• Only the requested Data can be returned
– explicit question to discover delegation
• not all Data names can be globally reachable
– To fetch data about /net/ndnsim/www, must first
find if
•
•
•
•
/net is delegate, then if
/net/ndnsim is delegated, then if
/net/ndnsim/www is delegated
...
– The final answer belongs to lowest-level domain
zone
• NDNS iterative query = Interest for the
specific RR sets in the specific zone
14
Data is returned to the
requester using pending
interest states on routers:
name of Data must match
name of the Interest
(longest prefix match)
NDNS example: iterative query
1.
2.
3.
4.
Check with root
zone if net
delegated
Check with .net
zone if ndnsim.net
delegated
Check with
ndnsim.net zone if
www.ndnsim.net
delegated
Authority found, ask
the final question
Iterative responses are
cached by the caching
resolver and within NDN
network
root
NS
Caching
resolvers
1
/net
NS
2
3 4
/net/ndnsim
NS
Cached data packets on caching
resolver and NDN caches
/DNS/net/NS
/net/DNS/ndnsim/NS
/net/ndnsim/DNS/www/NS
/net/ndnsim/DNS/www/TXT
15
NDNS naming conventions
• NDN the same for
– application
– transport
– network layers
• NDN names should be expressive
to provide functions for all layers
• 3-tier structure of NDNS names
– for network layer
• routable prefix
– for transport layer
• application de-multiplexor (demux)
– for application layer
• application-specific data descriptor
(query)
16
NDNS iterative query
Data
Name: /net/ndnsim/DNS/www/TXT/20130823
Content: Type:
"NDN Resp"
Freshness: 3600
ContentBlob: 1
<"NS-3 based
NDN simulator">
signature
•
•
•
Zone that Data belongs to
“DNS” application de-multiplexor
Specific question for zone’s data
•
<serial> is a "version" of a specific RR set
– a rough equivalent of zone's serial number, but with RR set granularity
17
Recursive query example
• Request recursive query
data for
– /net/ndnsim/www domain
– TXT type
Interest
Stub
resolvers
/DNS-R
/net/ndnsim/www
/TXT
Caching
resolvers
• Caching resolvers supply
data for recursive query
• Caching resolver
performs iterative query
– discovers authority
– get the answer and
encapsulates
• Process encapsulated
iterative response Data
– verify outer and/or
– internal signature
18
Data
/DNS-R
/net/ndnsim/www
/TXT encapsulated Data
/net/ndnsim
/DNS
/www
/TXT
NDNS recursive query
“root” scope = local routers
know how to get Data for
“DNS-R” app
Data
Name: /DNS-R/net/ndnsim/www/TXT/1377326330
Content: Type:
"NDN Recur"
Freshness: 3600
ContentBlob:
encapsulated Data
Name: /net/ndnsim/DNS/www/TXT/20130823
Content: Type:
"NDN Resp"
Freshness: 3600
ContentBlob: 1
<"NS-3 based
NDN simulator">
• Double-secured response
– outer signed by caching resolver
– inner signed by the authoritative name server
whom to trust depends on
trust relationships
• <id> ensures uniqueness of the NDN Data packet name
19
– a timestamp value
NDNS Security
20
Security of NDNS
• NDNS is NDN applications
– security is build-in into the architecture
• DNS is secured by DNSSEC extension
• NDNS directly provides DNSSEC-equivalent trust
model and security
21
Security properties inherited from NDN
• Existing reflector DDoS attacks are not possible
– NDN does not have source addresses in packets
– Data is always returned to the requester
• Existing direct DDoS attacks not possible
– For each name, only the first request reaches the server
• the rest will pull data out of cache
– DDoS by asking for different name can be easily mitigated
• per-packet state
• matched Interest-Data two-way traffic
22
DNSSEC security model example
• Each RR set is signed
–
–
signature stored in RRSIG record
key stored in DNSKEY record
• DS record is used to authorize delegation
–
23
hash of child zone’s DNSKEY
Similarities and differences between
DNSSEC and NDN trust model
DNSSEC
NDN
• each RR set is bundled with • each Data packet is bundled
RRSIG
with a Signature and
KeyLocator
• each Data packet contains
• each DNS message can
exactly one RR set
contain multiple [RRset,
RRSIG]
• NDN’s KeyLocator refers to
the unique key-certificate
• RRSIG “specifies/hints”
name used to sign data
DNSKEY RR set used to
packet
produce signature using
“Key tag”
• Keys-certificates are also
Data packets, thus can be
• DNSKEY RRset is signed
further signed
by another DNSKEY or
• Key-certificate is authorized
24 self-signed
NDNS security model
• NDNCERT for security delegation and record signing
• No need for DS (Delegated Signer) record
– DNSSEC is DNS extension and is optional
– NDNS mandates security
– DS and DNSKEY distinguish authority over data
– NDNS use name to distinguish authority
"/" zone
"/net" zone
"/net/ndnsim" zone
Data
Data
NDNS root
/DNS/...
Both keys
/NDNCERT/...
for
.net, but
managed
Data by
Key delegate
for
different
.NET zone
authorities
25
/DNS/net/...
/NDNCERT/...
Data
Key-certificate for
NDNSIM.NET zone
Key-certificate for
.NET zone
/net/ndnsim/DNS/...
/NDNCERT/...
/net/DNS/...
/NDNCERT/...
Data
Key delegate for
NDNSIM.NET zone
/net/DNS/ndnsim/...
/NDNCERT/...
Data
TXT RR set
/net/ndnsim/DNS/www
/TXT/...
Evaluations
26
Simulation-based evaluation of NDNS
• Real python-based
prototype implementation
– the same code is running on
the testbed and within the
simulator
• Based on the developed
ndnSIM simulator
• Using AT&T-based
topology (Rocketfuel
project)
– 625 nodes, 2101 links
– 296 “clients”, 108 “gateways”
and “221” backbone
27
ndnSIM: another piece of contribution
• Based on NS-3 network simulator
• Has modular architecture and easily extended
28
Current ndnSIM status
• 17 public forks on github
• Active development
– new features
– extended API
– usage examples and documentation
• A lot of activity on the mailing list
29
ndnSIM usage scope trends
(based on published papers and mailing list data)
•
http://ndnsim.net/ndnsim-research-papers.html#research-papers-that-usendnsim
– at least 17 published papers (by the early adopters, excluding us) use ndnSIM
• Caching-related evaluation
– various caching replacement policies, collaborative caching
• Congestion control related
– TCP-like transfers (end-to-end, host-by-host)
– queueing
• Mobile and vehicular environment evaluations
• DDoS-related evaluations
– interest flooding (us)
– content poisoning
•
Forwarding strategy experimentation (us)
– behavior in the presence of link failures, prefix black-holing
•
Application-level evaluations (us)
– exploration of ChronoSync protocol design
– NDNS evaluation in this thesis
30
Simulation setup
• Trace-driven:
– 1 million queries to .com zone from large ISP
• Objective
– check the degree of help from the NDN in-network caches
Backbone network
/DNS/com/NS
/DNS/com/NS
Root zone name server
/com/DNS/google/NS
/com/DNS/bing/NS
/com/DNS/twitter/NS
/com/DNS/google/NS
/com/DNS/bing/NS
/com/DNS/twitter/NS
...
13 "/com" zone
"anycasted"
name server
"gateway"
nodes
200 NDNS caching resolvers,
randomly placed among 298 "client" nodes
31
We did not evaluate application levelcache, assuming it is unlimited
No other traffic in the simulated network
Number of received queries by .com servers
Number of queries that reached authoritative
name servers
32
800,000
Baseline: total number of Interests out of caching
resolvers (after app-caches)
600,000
Cache type
LRU
400,000
LFU
Random
200,000
0
10
100
1000
10000
Maximum cache size, packets
100000
Percent of queries satisfied by NDN caches
Relative impact of NDN caches: percent of
queries satisfied from NDN caches
60%
Cache type
40%
LRU
LFU
Random
20%
0%
10
33
100
1000
10000
Maximum cache size, packets
100000
Cache hits of in-network NDN caches
Using in-network NDN caches allows sharing of iterative queries
34
Addressing NDN operational
challenges with NDNS
Part 2
35
Security credential management
36
Security credentials storage for NDN
applications
• NDN builds security directly into data delivery
– Data packets must be signed
– KeyLocators specified in Data packets
• Two open issues
– NDN does not specify how and where to store keycertificates
– Key-certificate revocation: remains a challenge
• NDNS provides a solution to these issues
37
Security credential management on NDN
• Initial attempt to deploy security credential on NDN
testbed uses “repo” element
– in-network permanent storage
– can store any Data packet
– But
• repo is not authoritative source for Data (cannot say “NO”)
• current implementation is limited
• NDNS
– general-purpose secure distributed storage
– application can define any custom RR type to store in NDNS
– authoritative source for Data
• authoritative NDNS name servers have full “authority” over the zone
• if RR does not exist in the zone, NDNS will vouch for that
38
Using NDNS to store key-certificate
• Key-certificate can be fetched by name
– From where? From NDNS
• Each NDN site run NDNS server
– primary for the site’s zone
– secondary for other site’s zone
/ndn/ucla/DNS
/ndn/caida/DNS
/ndn/uarizona/DNS
/ndn/washu/DNS
...
UCLA site
/ndn/caida/DNS
/ndn/ucla/DNS
/ndn/uarizona/DNS
/ndn/washu/DNS
...
CAIDA site
ChronoSync'ed
NDNS zones
/ndn/uarizona/DNS
/ndn/ucla/DNS
/ndn/washu/DNS
/ndn/caida/DNS
...
39
WashU site
UArizona
site
...
/ndn/washu/DNS
/ndn/ucla/DNS
/ndn/uarizona/DNS
/ndn/caida/DNS
...
Key-certificate revocation with NDNS
• Crypto credentials (key-certificates) need to be revocable
– by certificate issuer
– by key owner
• Mechanisms
– Revocation lists and online certification checks
– Physically removing key-certificate
• invalid key-certificate should be removed from NDN network
• All of these supported by NDNS
– NDNS can be a revocation list/lookup service
• issue/owner can have they own (implicit) lists
– Any NDNS record can be removed
• owner (= delegated zone) can revoke (delete) individual records
• issuer (= parent) can revoke (delete) delegation record
• takes effect after TTL/freshness period
40
NDNS storage options for users
•
Site provides storage for user’s data
/ndn/ucla zone
/ndn/ucla/alex namespace in /ndn/ucla zone
Data
Data
Data
Data
Key delegate for
alex sub-zone
App-specific data
signs
/ndn/ucla/DNS/alex/...
/NDNCERT/...
•
/ndn/ucla/DNS/alex
/<app-label>/...
/<app-RR-type>/...
User uses its own persistent storage
/ndn/ucla zone
/ndn/ucla/alex zone
Data
Data
Data
Data
Key delegate for
alex sub-zone
41
/ndn/ucla/DNS/alex/...
/NDNCERT/...
delegates
signs
App-specific data
/ndn/ucla/alex/DNS
/<app-label>/...
/<app-RR-type>/...
Routing scalability
42
Scale Interest forwarding
• NDN forwards Interest by data names
– Number of application names virtually infinite
• over 200 million just 2nd-level DNS names
• Solution: map-n-encap
– proposed many years back to scale IP routing
• globally routable and non-routable addresses
• DNS to map
• IP-IP encapsulation to forward packets
•
•
•
43
•
S. Deering. “The Map & Encap Scheme for
scalable IPv4 routing with portable site prefixes.”
Presentation Xerox PARC, 1996.
M. O’Dell. “8+8—An alternate addressing
architecture for IPv6.” Internet draft (draft-odell8+8-00), 1996.
D. Farinacci. “Locator/ID separation protocol
(LISP).” Internet draft (draft-farinacci-lisp-00),
2007.
R. Atkinson, S. Bhatti, and S. Hailes. “ILNP:
mobility, multi-homing, localized addressing and
User Networks
encapsulation
Transit networks
Routing scalability in NDN
• All NDN names are applications names
– some names are directly routable world-wide (DFZ)
– other names are routable just only inside ISP networks
• Globally routable names
– large ISPs
• /telia, /cenic
– large content providers
• /com/google; /com/cnn; /com/wikipedia
– large organizations
• /edu/ucla; /edu/caida
• Locally routable only
– local communication only
• /localnet/...
– for global communication
• /net/ndnsim; /com/lynch; /org/gnu
• applications “registers” prefix within ISP
44
Forwarding hint
• Interest name “uniquely” identifies
the requested Data
– but routers may not known where the
Data is or could be
• Solution: add “Forwarding Hint” to
the Interest packet
– an NDN name, known to be routable
within DFZ
– routers can ignore hint, if they know
other ways to satisfy Interest
• local Data producer
• already in local cache
• NDNS as FH storage/lookup service
– similar to ILNP effort [1]
– new “FH” RR
• priority can be used to define Data
producer policy on which hint is
“preferred”
45
[1] http://ilnp.cs.st-andrews.ac.uk/
Interest packet
Name
Forwarding
Hint
Selectors (opt)
Nonce
Example of map-n-encap world for NDN
Dual-homed /net/ndnsim/www server
/net/ndnsim/www
/net/ndnsim/www
Customer's
network
/telia/customer
FIB
/net/ndnsim
default
UCLA
CS Department
/ucla/cs
FIB
/net/ndnsim
default
UCLA
/ucla
Default free
zone (DFZ)
FIB
/telia/customer
/telia/...
/cenic
/ucla
Telia
/telia
FIB
/cenic/...
/telia
/ucla
FIB
/ucla/cs
/ucla/...
/cenic
/telia
CENIC
/cenic
Data
NDNS query
1 Mapping lookup
using NDNS
? /net/ndnsim/www FH
Name: /net/ndnsim/DNS/www/FH/%01
Content: <2 RR datas>
FH /ucla
FH /telia
Interest
46
2 "Encapsulating" using
forwarding hint
Name: /net/ndnsim/www/index.html/%00
ForwardingHint: /ucla
Forwarding hint lookup options
Consumer-based lookup
Network-based lookup
47
Who does the lookup is still a research question
• consumer may not know which names are not
“routable”
Forwarding hint for mobility support
• Network must be able to forward Interests to mobile
producers
– Mobile producer updates its FH in NDNS
• TTL (Freshness) specifies basic granularity for the hint lifetime
– New consumers lookup NDNS to fetch data of mobile
producers
• mobile producer can notify existing consumers about the hint
changes directly (inside the returned Data packet)
48
Future work plan
• Deploying NDNS within NDN testbed (and beyond)
• Providing storage for security credentials of NDN
testbed participants
• Developing libraries to scale NDN communication
globally using NDNS
49
Conclusions
• Designed and prototyped NDNS to meet operational
needs in NDN rollout
– provides storage for NDN security credentials
– provides a mapping service to scale NDN name-based routing
– and more
• NDNS is among the first attempts to “port” existing
Internet infrastructure system onto NDN
– one could imitate IP in NDN, but it would be inefficient
– naming considerations dominates design of NDN applications
– NDN’s build-in security proves useful and simplifies overall
design
50
Questions
51
6.
7. A. Af anasyev, S. Lee, U. Lee, and M. Gerla, "Content Distribution in VANETs using Network Coding:
Comparison of Generation Selection Mechanisms," UCLA Computer Science Department, Technical
Report , 2009.
List of publications
asyev
ds
A. Af anasyev, C. Yi, L. Wang, B. Zhang, and L. Zhang, "Scaling NDN Routing," NDN, Technical Report
NDN-0004, 2012.
Publications
Research Projects
Software
8. A. Af anasyev, "Distributed Multimedia Broadcasting System in the Data Transmission Networks,"
Master Thesis, Bauman Moscow State Technical University, June 2007. (in Russian)
9. A. Af anasyev, "Researching of Methods and Development of Means of Multimedia Broadcasting in
Data Transmission Networks," Bachelors Thesis, Bauman Moscow State Technical University, July 2005.
JOURNAL AND CONFERENCE PAPERS
(In Russian)
17. V. Knyazev and A. Af anasyev, "Computer Measurement Laboratory," Informatics and Control Systems
21st Century, 2003.
(In Russian)
1.
Z. Zhu and A. Af anasyev, "Let's ChronoSync: Decentralized Dataset State in
Synchronization
in
CONFERENCE ABSTRACTS
Named Data Networking," in Proceedings of the 21st IEEE International Conference on Network
TECHNICAL REPORTS
Protocols (ICNP 2013), Goettingen, Germany, October 2013.
1. A. Af anasyev and A. Averyanikhin, "Hybrid Routing Model for Real-Time Broadcasting," in Proceedings
of the
14th International
2.
A. Af anasyev, P. Mahadevan, I. Moiseenko, E. Uzun, and L. Zhang, "Interest
Flooding
Attack and Scientific and Practical Conference of Students, Postgraduates and Young
1. Scientists
Z. Zhu,"Modern
A. Af anasyev,
and L.and
Zhang,
"A New Perspective
on Mobility
NDN, Technical
Techniques
Technologies"
(MTT), Tomsk,
Russia,Support,"
Tomsk, March
2008, pp. 234–
Countermeasures in Named Data Networking," in Proc. of IFIP Networking 2013,
May 2013.
Report
NDN-0013,
2013.
235. (In Russian)
3.
C. Yi, A. Af anasyev, I. Moiseenko, L. Wang, B. Zhang, and L. Zhang, "A Case for Stateful Forwarding
2.
C. Af
Bian,
Z. Zhu,"Software-Hardware
A. Af anasyev, E. Uzun,
and for
L. Zhang,
"Deploying
Key Management
on NDN
2.
A.
anasyev,
System
Multimedia
Broadcasting
in Data Transmission
Plane," Computer Communications, vol. 36, no. 7, pp. 779–791, 2013. ISSN
0140-3664
Testbed,"
Technical of
Report
NDN-0009,
Revision
2, 2013.
Networks,"NDN,
in Proceeding
Informational
and
Telecommunication
Systems Competition (All-Russia
competition
innovative projects of graduate students), Moscow, Russia, December 2005. (In
4.
C. Yi, A. Af anasyev, L. Wang, B. Zhang, and L. Zhang, "Adaptive Forwarding
in Namedof
Data
3. Russian)
A. Af anasyev, I. Moiseenko, and L. Zhang, "NdnSIM: NDN simulator for NS-3," NDN, Technical
Networking," ACM Computer Communication Reviews, vol. 42, no. 3, pp. 62–67,
July 2012.
Report NDN-0005, 2012.
3. A. Af anasyev and V. Dudko, "Multimedia Broadcasting Systems for Telecommunication Networks," in
5.
L. Wang, A. Af anasyev, R. Kuntz, R. Vuyyuru, R. Wakikawa, and L. Zhang, "Rapid Traffic Information
4. Proceedings
Z. Zhu, C.ofBian,
A. Science
Af anasyev,
V. Jacobson,
L. Zhang,
"Chronos:
Serverless Multi-User
Chat Over
Youth
School
"Materialsand
for Nano-,
Micro-,
and Optoelectronics:
Physical
Dissemination Using Named Data," in Proceedings of the 1st ACM workshop on Emerging NameNDN,"
NDN, Technical
Report NDN-0008,
2012.
Characteristics
and Applications",
Saransk,
Russia, October 2005, pp. 178–179. (In Russian)
Oriented Mobile Networking Design - Architecture, Algorithms, and Applications
(NoM 12), Hilton
Head
Island, South Carolina, June 2012, pp. 7–12.
5. A. AfC.anasyev,
Yi, A. Af anasyev,
I. Moiseenko,
L. Wang, B.
Zhang,
L. Zhang,Broadcasting
"A Case for Stateful
Forwarding
4.
"Developing
Software-Hardware
System
forand
Multimedia
in Educational
Data
Networks,"
in Proceeding
of All-Russia2012.
Science Conference "Informational Technologies in Science,
Plane,"
NDN, Technical
Report NDN-0002,
V. Pournaghshband, L. Kleinrock, P. Reiher, and A. Af anasyev, "Controlling Applications by
Education, and Economics", Yakutsk, Russia, November-December 2005, pp. 6–7. (In Russian)
Managing Network Characteristics," in Proceedings of 2012 IEEE International Conference on
6.
A. Af anasyev, C. Yi, L. Wang, B. Zhang, and L. Zhang, "Scaling NDN Routing," NDN, Technical Report
Communications (ICC), 2012, pp. 1085–1090.
NDN-0004, 2012.
5.
A. Af anasyev, "Automatic Monitoring System for Big Power Systems," in Proceeding of the Federal
7.
E. Kline, A. Af anasyev, and P. Reiher, "Shield: DoS filtering using traffic
in Proceeding
7.deflecting,"
A. Af anasyev,
S. Lee,
U. Technical
Lee, and M.
Gerla, "Content
Distribution
VANETs
using Network
Coding:
Resulting
Scientific
and
Conference
of Creative
RussianinYouth
in Natural,
Technical,
of IEEE International Conference on Network Protocols (ICNP), October 2011,Comparison
pp. 37–42. of Generation Selection Mechanisms," UCLA Computer Science Department, Technical
Humanitarian Science, Moscow, Russia, December 2003. (In Russian)
Report , 2009.
8.
A. Af anasyev, J. Wang, C. Peng, and L. Zhang, "Measuring redundancy level on the Web," in
POSTERS
Proceedings of Asian Internet Engineering Conference 2011 (AINTEC 2011),
8. 2011.
A. Af anasyev, "Distributed Multimedia Broadcasting System in the Data Transmission Networks,"
6.
Master Thesis, Bauman Moscow State Technical University, June 2007. (in Russian)
A. Af anasyev, N. Tilley, P. Reiher, and L. Kleinrock, "Host-to-host congestion
control
for TCP,"
IEEEand L. Zhang, NDNS: scalable and distributed name mapping service for NDN,
1.
A.
Af anasyev,
Y. Yu,
Communication Surveys and Tutorials, vol. 12, no. 3, pp. 304–342, July 2010.
The IEEE
9. Poster,
A. (2012
Af anasyev,
"Researching
of Methods
and Development of Means of Multimedia Broadcasting in
UCLA
Tech
Forum 2013,
May 2013.
Communications Society Best Tutorial Paper Award)
Data Transmission Networks," Bachelors Thesis, Bauman Moscow State Technical University, July 2005.
2. (In Russian)
Z. Zhu, A. Af anasyev, and L. Zhang, ChronoShare: a new perspective on effective collaborations in
10.
A. Af anasyev, N. Tilley, B. Longstaff, and L. Zhang, "BGP Routing Table: Trends
and Internet,
Challenges,"
in UCLA Tech Forum 2013, May 2013.
the future
Poster,
Proceedings of the 12th Youth Technological Conference "High Technologies and Intellectual Systems",
CONFERENCE ABSTRACTS
Moscow, Russia, April 2010.
3.
A. Af anasyev, I. Moiseenko, L. Zhang, E. Uzun, and P. Mahadevan, DoS and DDoS resiliency of NDN
9.
11.
12.
52
3rd NDN retreat, October 2012.
1. architecture,
A. Af anasyev
A. Af anasyev, K. Mayoral, Z. Zhu, and S. Y. Oh, "DTCAST: Delay and Disruption
Tolerantand A. Averyanikhin, "Hybrid Routing Model for Real-Time Broadcasting," in Proceedings
of
the
14th
International
Scientific and Practical Conference of Students, Postgraduates and Young
Multicasting Protocol," in Proceedings of the 11th Youth Technological Conference
Technologies
4. Scientists
A. "High
Af anasyev,
Moiseenko,and
andTechnologies"
L. Zhang, Developing
NS-3 based
NDN
simulator,
"ModernI.Techniques
(MTT), Tomsk,
Russia,
Tomsk,
MarchCCNx
2008, pp. 234–
and Intellectual Systems", Moscow, Russia, April 2009.
Community
Meeting held at PARC, September 2011.
235.
(In Russian)
A. Af anasyev, "Hybrid IP broadcasting multimedia content protection system," in roceedings of the
TALKS
AND
PRESENTATIONS
2.
A. AfMoscow,
anasyev,
"Software-Hardware System for Multimedia Broadcasting in Data Transmission
10th Youth Technological Conference "High Technologies and Intellectual
Systems",
Russia,
Networks," in Proceeding of Informational and Telecommunication Systems Competition (All-Russia
April 2008, pp. 16–20. (In Russian)
of innovative
of graduate
students),
Moscow,
Russia,
December
1. competition
A. Af anasyev,
Tutorialprojects
for students:
ndnSIM,
AsiaFI 2013
Summer
School,
August2005.
2013.(In
NDNS security
• Cryptography
– signature of the Data packet matches the public key
• Application-specific name-based policy
• the specified key-certificate is authorized to certify Data
– key-certificate is the trust anchor
– name of Data and name of key-certificate match the policy rule
53
NDNS security policy (“identity” policy)
• Policy encoded into the NDNS applications
• List of trust anchors
– anchors can have limited scope (unlike current CAs)
• List of name reduction rules, e.g., using NDN regular expressions
– key-certificate name to namespace
– data name to namespace
– OK only if data namespace covered by the key-certificate
namespace
54
DyNDNS as remote database update
protocol
• NDNS is thought to be used as a general-purpose
database
– query operation is important, but not enough
– need efficient protocol(s) for update and data removal
• support “sporadic” updates
• support “bulk” updates
• ensure eventual synchronization
• DyNDNS protocol for updates
– similar to dynamic updates in DNS
– update granularity: RR set
• the updater is responsible to form correct RR set Data packet, if only
one RR data is modified
• “empty” Data to delete RR set
– build-in NDN security, exactly the same way as NDNS itself
55
DyNDNS cycle
Zone "authorizes" DZSK key
Data
/net/ndnsim
zone
Name: /net/ndnsim/DNS
/dzsk-1/NDNCERT/21
KeyLocator: /net/ndnsim/DNS
/zsk-XXXX/NDNCERT
Prepared Data directly installed into the zone
and served for future iterative queries
Data
Name: /net/ndnsim/DNS/www/TXT/01
Content: Type:
"NDN Resp"
Freshness: 3600
ContentBlob: <"Updated">
Remote prepares Data packet,
signing it with DZSK
56
KeyLocator: /net/ndnsim/DNS
/dzsk-1/NDNCERT
Definition of singular DyNDNS updates
(Interest-based transport)
DyNDN update Interest name ::=
AuthorityZone
"DNS"
(NDNS iterative response)*
"DYNDNSUPDATE"
Multiple updates ca be combined together,
if they fit into one Interest packet
DyNDN update Data ::= Name
Content
Signature
Name ::= DyNDN update Interest name + <timestamp>
Content ::= Type
Type ::= "DyNDN OK" |
Freshness
"DyNDN Fail"
ContentBlob
ContentBlob ::= <"OK"> | <"FAIL: …">
Data
Interest
Name: /net/ndnsim/DNS
Data
Name: /net/ndnsim/DNS/www/TXT/01
Content: Type:
"NDN Resp"
Freshness: 3600
ContentBlob: <"Updated">
KeyLocator: /net/ndnsim/DNS
/dzsk-1/NDNCERT
/DYNDNSUPDATE
57
Name: /net/ndnsim/DNS
Data
Name: /net/ndnsim/DNS/www/TXT/01
Content: Type:
"NDN Resp"
Freshness: 3600
ContentBlob: <"Updated">
KeyLocator: /net/ndnsim/DNS
/dzsk-1/NDNCERT
/DYNDNSUPDATE/1377579885
Content: Type:
"DyNDNS OK"
Freshness: 3600
ContentBlob: <"OK">
DyNDNS update overview
• Updater side
– (optional) Lookup existing NDNS RR set
– Create new Data packet with new RR set data
• empty RR set data if RR set needs to be deleted
– Sequence number for the created RR set Data packet should be larger than
any previously used
• current timestamp can be used
– Sign Data packet with DZSK and deliver to authoritative name server
• Authoritative name server side
– (does not matter master or secondary, since zone data is supposed to be
synchronized)
– authorize update
• Check if Data packet satisfies NDNS security policy
• Check NDNCERTSEQ record that corresponds to DZSK (the same label)
– if record does not exist, authorize Data and create NDNCERTSEQ record with the sequence
number from Data packet
– if record exist, authorize Data if record is “less” than sequence number in Data, and update
NDNCERTSEQ record
this effectively prevents any replay att
– install (replace) Data packet to the zone synchronize with others, if necessary
58
DyNDNS bulk updates
• The updater can simply become a temporary NDNS
secondary server and perform zone data
synchronization
– for example, using ChronoSync
• Updates are secured exactly the same way as
sporadic updates
– the zone authorizes DZSK
– updated records are signed by DZSK
– the zone keeps track of DZSK usage in NDNCERTSEQ
RR, as to prevent potential replays
59