Security and Mobility First: Looking Back and Looking Forward

The Mobility First TeamParticular thanks to:

Arun Venkataramani (UMass)

Z. Morley Mao (UMich)

Mike Reiter (UNC)

Wade Trappe (Rutgers)

[1]

WINLAB

Introduction: FIA-NP Collaborating Institutions

(LEAD)

D. Raychaudhuri, W. Trappe, R, Martin, Y. Zhang, I. Seskar

S. Bannerjee

W. Lehr

Z. Morley MaoB. Ramamurthy

X. Yang

A. Venkataramani, (J. Kurose), P. Shenoy

WINLAB

Talk Roadmap… Where are we going?

MobilityFirst Overview– Brief (I hope!): motivation and overall design objectives

Dave’s Questions Rewind: Behind closed doors, what the team was thinking

– Initial security discussions– Amusing philosophical points of views

MobilityFirst’s Security Design– Objectives, toolbox and wishlist– Highlights of what we actually did…– Half-baked things that are unfinished

Dave’s questions, answered directly…

[3]

WINLAB

Ultra-quick recap: the original design concepts

Mobility as a basic service (location tracking; fast address assignment, handoff, network mobiilty)

Robustness with respect to intrinsic properties of wireless medium (disconnection, varying bandwidth, high error rates)

Support for anticipated mobile/pervasive applications (requiring features such as location or context awareness)

Enhanced trust models suitable for open wireless channels and mobile end-users (strong authentication, resistance to eavesdropping, DDoS and routing attacks)

General usability requirements (such as evolvability, ease and trustworthiness of management, backwards compatibility, technology neutrality, economic viability, universal access)

[4]

WINLAB

Concepts led to design goals…

Host and network mobility (G1): End-to-end communication must continue (i) despite frequent mobility of end-hosts or networks; (ii) despite the absence of a contemporaneous end-to-end path.

No global root of trust (G2): Correct network behavior must not depend on a single root of global trust. 

Intentional data receipt (G3): An end-host must receive data only if the transmission is consistent with its receipt policy.

Byzantine robustness (G4): End-to-end communication must continue despite the compromise of (a small fraction of) routers or end-hosts.

Location-independent content (G5): The network should assist with content retrieval in addition to enabling host-to-host communication.

Evolvable network services (G6): The architecture should allow for the co-existence or rapid creation of alternate network services.

[5]

WINLAB

And what we got is… The MobilityFirst Future Internet Architecture

Routers with IntegratedStorage & ComputingHeterogeneous

Wireless AccessEnd-Point mobilitywith multi-homing • In-network

• content cache

Network Mobility &Disconnected Mode

• Hop-by-hop• file transport

• Edge-aware• Inter-domain• routing

Named devices, content,and context

11001101011100100…0011Public Key BasedGlobal Identifier (GUID)

Storage-awareIntra-domain

routing

Service API withunicast, multi-homing,mcast, anycast, content query, etc.

Strong authentication, privacy

• Ad-hoc p2p• mode

Human-readablename

Connectionless Packet Switched Networkwith hybrid name/address routing

• MobilityFirst Protocol Design Goals:- 10B+ mobile/wireless devices- Mobility as a basic service- BW variation & disconnection tolerance- Ad-hoc edge networks & network mobility- Multihoming, multipath, multicast- Content & context-aware services- Strong security/trust and privacy model

Global NameResolution Service

WINLAB

MobilityFirst Concepts: Protocol Stack

IP

Hop-by-Hop Block Transfer

Link Layer 1(802.11)

Link Layer 2(LTE)

Link Layer 3(Ethernet)

Link Layer 4(SONET)

Link Layer 5(etc.)

GSTAR Routing MF Inter-Domain

E2E TP1 E2E TP2 E2E TP3 E2E TP4

App 1 App 2 App 3 App 4

GUID Service Layer Narrow Waist

GNRS

MF RoutingControl Protocol

NCSNameCertification& AssignmentService

Global NameResolutionService

Data PlaneControl Plane

Socket API

SwitchingOption

Optional ComputeLayer

Plug-In A

WINLAB

MobilityFirst Concepts: GUID Service Example

MobilityFirst Network(Data Plane)

GNRS

Register “John Smith22’s devices” with NCS

GUID lookupfrom directory

GUID assigned

GUID = 11011..011

Represents networkobject with 2 devices

Send (GUID = 11011..011, SID=01, data)

Send (GUID = 11011..011, SID=01, NA99, NA32, data)

GUID <-> NA lookup

NA99

NA32

GNRS update(after link-layer association)

DATA

SIDNAs

Packet sent out by host

GNRS query

GUID

Service API capabilities: - send (GUID, options, data)Options = anycast, mcast, time, .. - get (content_GUID, options)Options = nearest, all, ..

Name CertificationServices (NCS)

WINLAB

Architecture: Name-Address Separation

Separation of names (ID) from network addresses (NA)

Globally unique name (GUID) for network attached objects– User name, device ID, content, context, AS

name, and so on– Multiple domain-specific naming services

Global Name Resolution Service for GUID NA mappings

Hybrid GUID/NA approach– Both name/address headers in PDU– “Fast path” when NA is available– GUID resolution, late binding option

Globally Unique Flat Identifier (GUID)

John’s _laptop_1

Sue’s_mobile_2

Server_1234

Sensor@XYZ

Media File_ABC

Host NamingService

Network

SensorNamingService

ContentNamingService

Global Name Resolution Service

Network addressNet1.local_ID

Net2.local_ID

ContextNamingService

Taxis in NB

WINLAB

BACK AT THE SECURITY RANCH…

[11]

WINLAB

Dave’s Questions, up front…

What were the security requirements that the project set itself? How were these requirements developed? Which aspects of the system were expected to deal with which

security requirements? Core architecture? Did any features of the new architecture lead to a material

change with respect to the security landscape? Did the project require or lead to innovations in security

thinking, or the development of new mechanisms?

[12]

WINLAB

The team’s security discussions… philosophical viewpoints

Looking back, the MF team had some interesting philosophical discussions about security:– Is security design like network design?– Could one “ARCHITECT” security?– Weren’t all the security exploits a consequence of “devil in the details”

associated with protocols, implementations, etc?

What we all agreed upon was something along the lines:– Proper network architecture and design does not achieve security, but

creates a toolbox that facilitates the ability to have security– A bad network design would be one that left out key “tools” that one

needs to then later build (in detail) solutions that address security problems and are themselves complete.

So: What should we put in the toolbox? And: Would our toolbox even work?

[13]

WINLAB

The toolbox should have…

No single root of trust:– We wanted to move away from the single root of trust (c.f. ICANN)– This gives a decentralized model of trust, e.g. each country manages its

own NCS, or one can shop around for the NCS that meets their needs.

Self-authenticating names– Public key cryptography provides the ability to prove ownership of the

address if the public key is associated with the address

Apply access control to information that could facilitate attacks Intentional receipt: recipients should be able to specify what reaches it

– Support intrusion detection and prevention

Disruption tolerance as a means to withstand “broken” or “being damaged” parts of the network

Understanding the applications that run on top of the network– Network traffic as a signature for intrusions and bad traffic

[14]

WINLAB

A Wishlist of Mobility First Security Mechanisms (circa MF Year 1)

• GNRS access control mechanisms can support white-listing/black-listing, as well as multi-grade security policies

• Network capabilities will be integrated into routing to ensure only capable entities can participate

• Public key identifiers provide automatic means for access control

• Access Control

• Secure routing protocols will address black hole, replay and misrouting• Watchdog processes running on network routers will share information, detect

network anomalies, and enforce policies• Multipath routing and network coding will be explored to ensure resilience in the

presence of selective forwarding by corrupted nodes

• Service• Integrity

• Secure storage and key management mechanisms will be developed to ensure confidentiality of cached information

• Randomization of paths will be integrated into routing to support location privacy• Pseudonymous variant of public key addresses will allow for disposable

identifiers

• Confidentiality/

• Privacy

WINLAB

The core security work followed a nice “hindsight” flow

GUIDs and the GNS:– The public key as an identifier that can allow for us to rapidly resolve

was paramount to MF– But is the introduction of a GNS “feasible”? (c.f. Auspice and Caesar)– What are the security concerns associated with such a new service?

Recipient-driven regulation– Leverage the GNS to regulate who gets to look GUID-to-NA mappings

(access control at the GNS)– Issue policies that tell the network “here is how I want you to process

traffic for me” Could be something like “only certain protocols for me” On-path and off-path filtering as an allocation problem Finding signatures for mobile traffic

Securing interdomain routing– attacks exist beyond the cryptographic routing protocols

[16]

WINLAB

Key Architectural Features: Named Objects

Globally unique identifiers (GUID) used to define all network-attached objects

Key design choice: flat identifier vs. hierarchical semantic identifier….

MobilityFirst uses a flat public key as the GUID

NDN uses domain name/hierarchical descriptor

Globally Unique Flat IdentifiersGlobal Name Resolution

Service

Host Naming Service

Content Naming Service

Context Naming Service

Integrated storage and computing

Routers with integrated

storage and computing

Hop-by-hop transport

Media file M

Context C

John’s laptop

Sue’s phone

WINLAB

Wait: GUIDs… aren’t they big? Could we ever use them for real?

How to reduce GUID size: elliptic curve cryptography– ECC P-256 of FIPS PUB186-3 DSS

Protection for classified information is up to the secret level Has security strength comparable to RSA with key size of

3072 bits But one might want to keep crypto choice flexible for future-

proofing

Even so, is the whole concept of public keys as a name ever going to be able to be realized in practical, real router deployments?– And what about flat vs. non-flat GUIDs?

The team was aware of this challenge and the team developed fast and memory-efficient forwarding engine for border routers (CAESAR)

Key contribution: scalable Bloom filters that support not only MobilityFirst, but also XIA and other AIP-like architectures[18]

WINLAB

A quick look at CAESAR… A forwarding and routing architecture

– For future Internet architectures– Memory-efficient and high-speed

Scalable and reliable Bloom filters Two forwarding pipelines

– Performance and correctness– Multi-match (MM) line

Primary for vast majority of packets– Compress states using Bloom filters– Encode filters in TCAMs for speed

Backup for very rare cases– Correct false positives at high speed– Use a hardware flag

Optimize hash computations Optimize route updates support

19

Primary Path (Scalable and

Reliable Bloom Filters)

Backup Path

Common Path

WINLAB

CAESAR: Performance comparison

• The total cost is stable for various address lengthso nmax=4, w = 288

WINLAB

Overview of Two-Tier Name Resolution: GUIDs, NCS, GNS

[21]

• Network Entity’s Three Attributes:- User-level descriptor- Network-level identifier- Routable Topological address

• Two Core Services:- Name Certificate &

Resolution Service (NCRS)- Global Name Resolution

Service (GNRS)Obligatory caveat: At some point we had a slight divergence in names…GNS/GNRS, NCS/NCRS… this talk does not address this…Call it Multi-homing.

WINLAB

GNS: Decoupling certification and resolution

Nam

e: “A

lice’

s p

hone

”

TLD name services

Auth. name services

Root name service (ICANN, US. Dept. of Commerce)

Certificate search services

GU

ID=X, G

NS=Auspice

Domain name system Global name system

getA

ddre

ss(X

) [IP

1, I

P 2,…

]

3

3

4

41

0Local name services

1

Local name services

2Name certification services

Managed DNS services

Auspice-like global name services

WINLAB

Implementation

Geo-distributed key-value store

Name certification service

msocket user-level socket library with Auspice integration

23

GUID: { {IPs: [123.45.67.89, 98.76.54.321]},{geoloc:[lat, long]},{TE_prefs: [“prefer WiFi”,…]},{ACL: {whitelist: […]}},}

Human-readable name: abhigyan@cs.umass.edu:phoneGUID: 21EC2020-3AEA-4069-A2DD-08002B30309D

MSocket socket = new MSocket(abhigyan@cs.umass.edu:phone);MServerSocket socket = new MServerSocket(8080);

WINLAB

Managed DNS comparison

24

• One-third replication cost, similar latency

• 60% less latency, • similar cost

• Auspice reduces cost/latency over • today’s managed DNS

• Ultra DNS (16 replicas) vs. Auspice 5/10/15 replicas out of 80 locations

WINLAB

Back to the NCRS & GNRS: We also looked at the “dirty” security details…

[25]

GNRS Server

NA1

NA2

NA3

Jim’s phone

Jim’s phone

Annie’s car

5. GNRS

Query3. GNRS

Update

GNRS Server

GNRS Server

NCRS Server

NCRS Server

NCRS Server

1. NCRS

Insert2. GNRS

Insert

4. NCRS

Query

6. Communication

WINLAB

NCRS Functionalities

Name Translation– Provide translation between Human

Readable Keywords and Globally Unique

Identifier (GUID)

Certificate Registry– Analogous to Public Key

Infrastructure (PKI)– Define certificate format– Allow self-certifying & certificate assignment– Certificate registry operations:

Insert (self-certifying) / Certificate request (certificate assignment)

Query Update Revoke

[26]

WINLAB

Potential GNRS Attacks

[27]

GUID Spoofing Attack:– A masquerading threat– A malicious user A claims another user B's GUID and attempts to

associate it with A's own network address by announcing the mapping (GUIDB, NAA).

– Consequence: denial of service

Stale Mapping Attack:– A message manipulation attack– A device moves and issues an update, the malicious GNRS server can

purposely ignore the update and claim it still has the most recent mapping. Perhaps worse, a GNRS server can selectively choose which (possibly stale) mapping to give out during queries.

– Consequence: denial of service

WINLAB

Potential GNRS Attacks

[28]

False Announcement Attack:– A information modification attack– User A, which is in network NAA, claims its GUIDA binds to a different

network address, (GUIDA, NAB).

– Consequence: illegitimate resource consumption

Collusion Attack:– A information modification attack– A malicious user, its network and the location where the mapping is stored

collude with each other to allow a fake mapping involving a false network address to pass the verification and become stored in the storage location.

– Consequence: denial of service

WINLAB

And we got stuff like: Securing GNRS Update

[29]

Main network components: updater, local router, border gateway router, DHCP server, mapping storage location.

NA1

A

Border

Gateway

Router G

1. A to L:

{GUIDA, [Na, GUIDL, (GUIDA, NA1, TA, EA)A-1 ]L}

NA2

X

7. G to X:

{GUIDG, { [GUIDA, Ng’, (GUIDA, NA1, TA, EA)A

-1,G

-1 ]G-1}x}

DHCP

Server D

Local

Router L2. L to G:

{GUIDL, [Nl, GUIDA, GUIDG, (GUIDA, NA1, TA, EA)A-1]L

-1 }G

6. L to A:

{Na+1}L-1

5. G to L:

{Nl+1}G-1

4. D to G: {Ng+1, (GUIDA, NA1, TA’, EA’)D

-1}G

3. G to D: {GUIDG, [Ng, GUIDA,

(GUIDA, NA1, TA, EA)A-1]D}

8. X to G: {Ng’+1}X-1

More where that came from…But let’s save that for the student talk tomorrow…

WINLAB

Revisiting recipient control: Controlling Access to GNRS Information

User (the recipient) should be able to specify:– Which people can see what information about the user’s name– Which people can see which set of available interfaces mapped to the user’s name– How frequently people are allowed to receive information about the user’s name

(similar to location privacy)

User-initiated cryptographic techniques:– Encrypt specific updates with a group key only available to a target group

Leads to key distribution problems

GNRS-based access control:– Updates contain a policy that specifies who can access what– Queries contain an authentication token that can be used in conjunction with the

policy to supply appropriate information

NameAddress

ListTimestamps Policy

Cryptographic Package

NameAuthentication

Token

Cryptographic Package

Update Query

WINLAB

Further problems and why “Access Control in GNRS” is good…

[31]

Problem– No protection for the mapping from being queried by illegitimate

users.

Consequences – Information/privacy leakage.– Attacks, e.g. DoS attack.– Track users’ behavior, etc.

Solution– Integrating access control to the GNRS.

Benefits– Protect mapping information from unauthorized access.– Support advanced services and fine-grained functionalities.

WINLAB

Overview of Access Control in GNRS

[32]

Access control language– eXtensible Access Control Markup Language (XACML)– Can handle basic GNRS access control, identity-based access control

(IBAC) and attribute-based access control (ABAC)

Policy format– Basic format: – Whitelist/backlist:

WINLAB

Spatio-temporal Access Control in GNRS

General Spatio-temporal access control (STAC)– Target

Grant the mapping based on spatio-temporal (ST) characteristics.

– Challenge A malicious user may lie about its location. No guarantee for the correctness of the ST information. Little support for the security of submission process

– What our team managed to do: Incorporate ST verification to ensure the correctness of ST

information. Adopt various security mechanisms to secure the query

process.

[33]

WINLAB

Spatio-temporal Access Control in GNRS

Spatio-temporal access control with state transitions– Definition of state

Being at a specific location in a specific time interval. Is represented by a location L and time interval (T, E) as

<L,T,E>.– Target: A stateful form of access control

Accessibility to the mapping depends on not only the current state, but also the previous state.

– Challenge Scalability & efficiency issue: a large burden for

distributed servers to maintain users’ state records in a large scale mobile network.

– Solution Introduce a token-based approach to handle the state

verification process.

[34]

WINLAB

Back to intentional receipt and NIDS/NIPS

AC at the GNRS does not completely remove adversaries from knowing network addresses

“Intentional receipt” (versus receiver control) was one of the goals that was set out at the beginning of the project:– Each end-user device or neighbor network attached to network X ought

to be able to express policies (that X should enforce) about the traffic that X passes along to it.

These policies could be rich (e.g., content-based, not just address-based). With potentially every end-user device expressing such policies, the real

challenge for network X is how to scalably enforce those policies. The MF team addressed this problem

– Solution also addresses fundamental challenge in network intrusion prevention systems (NIPS)

– Validated through an SDN implementation

[35]

WINLAB

Perpetual Scaling Challenge

36

• Traffic increase More packets to process• User applications changing More functions/modules• Attacks evolving Larger set of “rules” to apply

WINLAB

SNIPS System Overview

37

N1 N3N2

D1

Administrator/Recipients announcePolicies to SNIPS

SNIPS Network Controller

High-level goals: Latency, UnwantedLink/Node Load Decide local processing

and offloadingresponsibilities

WINLAB 38

Network-Wide

Optimization

Traffic

Classes

NIPS

Resource Use

NIPS, DC

Hardware

Topology

& Routing

N1N3

N2

D1

Class c = HTTP, N1 N3

c.in= N1; c.out = N3

c.Path = <N1, N2, N3>

SNIPS Controller Design

Decide local processing and offloadingresponsibilities

High-level goals: Latency, UnwantedLink/Node Load

WINLAB

SNIPS Offers Better Load Balancing

39

WINLAB

Complementing the work on SNIPS is the need to be able to characterize traffic

Mobile traffic is difficult to characterize– Most mobile applications do not use specific protocols or IP ports

with distinctive features– This makes it hard for “the local network” (e.g. enterprises and

service providers) to regulate the traffic that flows over their network

In order to support in-network removal of traffic, the team developed a solution (FLOWR) that identifies apps via traffic analysis– FLOWR uses a customized supervised learning approach that can

grow its collection of app signatures

[40]

WINLAB

FLOWR: Basic Principles

41

1. What to identify?Bi-directional flows

2. How to identify flows?Signature matching

3. How to extract signatures?HTTP metadata can be indicative to app identities

4. How to construct a knowledge base?Flow signatures from the same app often co-occur

5. How to initialize the knowledge base? App IDs are always embedded in ad and analytics

KV tokenization

flow regression

a* services

• http://api.airpush.com/v2/api.php?...&packageName=zz.rings.rww2&...

WINLAB

Key-value (KV) examples

admob.com &preqs=0&u_sd=1&slotname=a14d9cfab0d6002&u_w=320&ms

id=tls.game.fiar&cap=m%2Ca&js=afma-sdk-4.1.1&isu=F139F4FD31A7049ECD

A0C320F96B92CB&format=320x50_mb&net=ed&app_name=9.android.tls.game.fiar&hl=en&u_h=480&u_audio=1&u_so=p&output=htmlscorecardresearch.com &c1=19&c4=Total%20Beauty&c10=android&c12=5d

30b552b3874617ed84ca2de98c3ff1-a&ns_ap_device=generic&ns_ap_as=13384

40029585&ns_type=View&ns_ts=1338440029626&ns_m2=yes&c2=6035713&name=start&c3=Start&ns_ap_ver=1.5.2&ns_ap_res=480x800App ID: msid=tls.game.fiar, c12=5d30b552b3874617ed84ca2de98c3ff1-a

Developer ID: c2=6035713

Device ID: isu=F139F4FD31A7049ECDA0C320F96B92CB

General: js=afma-sdk-4.1.1, format=320x50_mb, hl=en, ns_ap_res=480x800

Random: ns_ts=1338440029626, ns_ap_as=1338440029585

42

WINLAB

KV tokenization extract KVs from flows into signatures

43

• airpush.com:sdkapid=67526 • ->com.rovio.angrybirds (TP:

99%)

• …• http://airpush.com/?

&sdkapid=67526&zipcode=48109• …

• http://airpush.com/? sdkapid=67526&zipcode=

48109

• airpush.com:sdkapid=67526

• airpush.com:zipcode=48109

• com.rovio.angrybirds (TP: 99%)

KV tokenization

WINLAB

Knowledge base initialized using a* services with minimal manual effort

(seed knowledge)

Full picture of FLOWR system

44

WINLAB

t90,95,99: uniquely identify with confidence 90,95,99%n5: narrow down to 5 candidates with confidence 99%

FLOWR: Some results…

45

WINLAB[46]

Routing Security: Advancing the science of secure interdomain routing

The team also explored the problem of secure routing from a new perspective where the adversary was corrupt AS’s with Byzantine behavior

BGP, even with S-BGP mechanisms, vulnerable to serious protocol manipulation attacks

The MF team’s contributions– Formalized two fundamental correctness properties and

show there are feasible attacks that violate them– Validated attacks with commodity routers– Quantified attack vulnerability in the Internet– Propose RCI-based approach to provably satisfy properties

WINLAB

BGP Control Plane Attacks, a solution, but not enough!

BGP control plane attacks– Prefix hijack: pretend to own a

prefix– Path spoofing: announce a

forbidden path Solution: S-BGP

– Ensures existence– Ensures authentication

S-BGP (and follow-ons) ensure verifiability of routing information using cryptographic techniques

Our main contribution– Manipulate the complex BGP

protocol to violate two of its most fundamental goals (even with S-BGP mechanisms)

AS 1

AS 2

BGP, even with S-BGP mechanisms, vulnerable to serious protocol manipulation attacks

Even without breaking any secure protocols, attacks can permanently cut a connection and permanently force a victim AS to select a less preferred path.

WINLAB

Advancement in Security Objectives: Desired Correctness Properties

Property 1: Eventual Reachability (ER)

Existence of a good path should ensure eventual reachability

Property 2: Policy Prevalence (PP)

Existence of multiple good paths should ensure selection of the most preferred path

WINLAB

The Soufflé is still in the oven for many things…

Robust multipath traffic allocation using portfolio theory Integrating trust assessment into MF: router assessment services, how to

incentivize rating, how does one allow for trust to regrow after losing it, integrating trust with inter/intra-domain routing

Designing a context-based communication service in a privacy-preserving manner

Robust network protocol designs to prevent abuses and protocol manipulation attacks from network services.

Network protocol designs to eliminate side channels for protecting user privacy and eliminating data injection attacks

Integrating “security as a network service” in order to support IoT security Storage verification: if in-network caching is being advertised, how do you

trust what you are being told?

[49]

WINLAB

And then there was stuff that just didn’t pan out… aka, the graveyard of failed research…

Example: It was thought that the use of public key naming addressing schemes might facilitate access control through pairing-based (ID) cryptosystems

Using such ID-crypto in public key addressing allows for flexible access control to data:– Data is encrypted at the source using the (single) public key that is derived by the

logical conjunction and disjunction of destinations’ identities (public keys) Example: Packet payloads can be encrypted so that either

Darleen or Victor can access, but only the Darleen who is at NSF and in DC and in the USA, or the Victor who is at NSF and also has a Comcast account

Challenge 1: Does not obviate the need of a structure akin to certificate authorities (must maintain pairing)

Challenge 2: Does not easily support integration with necessary timestamping for integrating within GNRS

Challenge 3: Combinatorial operations in crypto domain were not arbitrary

[50]

WINLAB

Dave’s Questions, revisited… Looking back at Dave’s Questions:

– What were the security requirements that the project set itself?– How were these requirements developed? – Which aspects of the system were expected to deal with which security

requirements? Core architecture? – Did any features of the new architecture lead to a material change with respect to

the security landscape?– Did the project require or lead to innovations in security thinking, or the

development of new mechanisms?

Our requirements arose out of “design goals” and “philosophy” We then found places to apply these goals, e.g. intended receipt/recipient

control We worried about whether our security ideas might be practically realizable

(e.g. CAESAR) Innovation to secure routing thinking: new correctness metrics that exist

outside the cryptographic framework

[51]