Minutes for ICNRG at interim-2016-icnrg-1
minutes-interim-2016-icnrg-1-1

ICNRG information at: https://trac.tools.ietf.org/group/irtf/trac/wiki/icnrg

Morning 14/1/2016

Performance evaluation of cache networks - Dario Rossi

- If you downscale by 5 orders of magnitude, you get an improvement of 2 orders
of magnitude. Is that correct? ÊÊÊ - Correct. The relationship is not linear
(it's sub-linear). Downgrading also doesn't affect the accuracy. - Do
simulations model work required to perform cache lookups (in the presence of
opportunistic caching)? Line rate per-packet lookups are expensive. ÊÊÊ - Not
currently, but it'd be easy to add. - Not a measure of underlying cache system.
It's a model of the simulator. - Unsure if caching can be done at scale
(10Gbps) and simulations need or should take the actual scale into account. ÊÊÊ
- We assume line rates are feasible (we showed this at ICN). Lookup speed has
increased two orders of magnitude in the last five years. ÊÊÊ The objective was
to do performance evaluation faster for large systems and large numbers of
objects - Have you thought about parallelizing the simulator? Maybe by breaking
it up among several machines? ÊÊÊ - Yes, we thought about it and briefly tried,
but we didn't gain a lot.

Challenges and directions for the management of ICN services -- Thibault Cholez

- The security slides discussed attacks not directed at consumers but at the
infrastructure. But the experiments focused on consumers. ÊÊÊ - The idea is
that consumers would be attacking each other. (Remainder of the answer not
heard due to reseating in the audience.) - One of the attack vectors is to
enable packets with bad signatures (as a computational DoS). The enforcement
box is then attacked by having to check these signatures. (Move the problem:
attack the firewall instead of the router.) ÊÊÊ - Firewall enforcement is based
on a blacklist of untrusted producers. Not by actually checking the signature.
- Is everything HTTP-based? Do students just install an HTTP(S) proxy? ÊÊÊ -
Yes. Students install an HTTP(S) proxy. - The approach seems to look at
managing ICN. What is the management protocol? ÊÊÊ - Maybe SNMP? We haven't
defined this part yet. - Have you given thought to how to generate synthetic
attack traffic? We really need traces that contain attack traffic to evaluate
ICN architectures and how they respond to this traffic. These traces should be
made available to people. - One of the biggest challenges is how (firewall)
rules are distributed to the correct boxes. ÊÊÊ - We defer the scalability
problem to the future. - Even a big enterprise will have ~500 firewalls
scattered around. The rules have to be installed to these firewalls. How is
that done? ÊÊÊ - Scalability might not be hard to achieve if the underlying
techniques work. - Benefits of virtual environments are elasticity and
scalability. Have you looked at criteria to scale? ÊÊÊ - Yes, we did some
performance evaluation and identified signature processing/generation as a
scalability barrier. - Docker is used for virtualization. - There are a lot of
NFV-independent management systems, e.g., OpenSec. ÊÊÊ - We may need specific
technologies to deal with NDN virtualization management. - What are the new
challenges in trying to manage virtualized NDN? - Will a routing protocol be
used in the system? ÊÊÊ - Yes, we use NLSR. - IP tables are not necessarily
"user friendly." - What are the assumptions about rules pertaining to faces and
their next hops? - Attackers will just use random names that make
human-readable rules unusable. ÊÊÊ - That's right. Our approach relies on
meaningful names.

Making connectivity decisions -- Konstantinos V. Katsaros

- What are your assumptions on cache stability and eviction rates?
ÊÊÊ - Each cache uses LFU with a sliding window.
- The assumption is that a consumer may only access on AP at a time?
ÊÊÊ - It depends on the granularity of the request (per-session -> one AP,
per-request -> different APs per request). - Requests could be sent to multiple
APs simultaneously. - Time is number of users that are connected to the users.
The number of active users remains constant. What happens if you start from
scratch (without prefetching)? ÊÊÊ - We do start from scratch. Initial users
populate the AP caches. ÊÊÊ - It would be interesting to see the time required
for the initialization phase. - Does this resemble real world traffic where all
data exists in a different form? We want the cache rate to represent the
reality of today's traffic (most of which is encrypted). - (Brief argument
about privacy and caching: TLS doesn't enable privacy with CDNs) - The problem
of figuring out what path (AP) to use is interesting. The capture effect needs
to be foiled. - Not comfortable advertising interests to entities with which I
have no relationship. - How does the user get the reference or name about what
they want to watch (content they want to retrieve)? ÊÊÊ - User has a profile
(that's built offline), e.g., "every morning I read BBC news." ÊÊÊ - Profiles
determine what traffic will be requested when users connect. - Are profiles
given to the AP? ÊÊÊ - Yes (?). - What type of information needs to be stored
in a profile to make an AP selection? ÊÊÊ - For example, rules that map content
names to APs (e.g., /com/cisco to the Cisco AP). - There may be other
interesting use cases, e.g., making AP decisions when under time pressure or
other constraints

- Announcement: PARC is releasing CCNx code as open source.
- The governance model needs to be figured out so that contributions can be
made to the code base.

ICN 5G (summary of recent mailing list discussion) -- Dirk Kutscher

- Disentangling the need and use of TCP proxies is important.
- The number of experiments and simulations that use properties of real-world
traffic is rare. Parameters for real-world traffic should be provided (e.g.,
number of hops, loss rates, etc.). - The evolution of CDNs is an interesting
topic -- opportunistic caching is (really) not a real replacement. The RG
should be looking at "what a real-world CDN does"? Current mechanisms for
delivery are based on protocols (TLS) that rely on point-to-point addresses.
ICN is not encumbered with those constraints and we may exploit that to do
better than CDNs. We could (should) be focusing on stack and application layer
services and APIs that can help solve privacy problems presented by HTTP. ÊÊÊ -
The way TLS is currently used does not promote or enable very good privacy
(it's necessary, not sufficient). - Encrypted and authenticated traffic will
not be reversed (or with very low, negligible probability). - Claim: privacy is
not actually gained from TLS. Don't sell it as privacy-enhancing. - TLS was
deployed because there was no other alternative. - Services that are built on
TLS-based traffic will never accept anything less. - Typical networking trap:
solving all the problems at the network layer. We should propose privacy as a
high-level construct and build on the work of differential privacy. A user may
care about their loss of privacy (to Google, e.g.). Basing solutions on TLS
does not allow this privacy gradient. There are different privacy requirements.
- Consider a popular piece of content: what is to gain from completely private
retrieval of this content? - If privacy options are provided, people have the
freedom to choose less private approaches that lead to attacks and
infrastructure degradation. - ICN key exchange protocols allow A&A to be
isolated to the application, i.e., private keys don't need to be put in CDNs
for TLS connection establishment.

ÊÊÊÊÊÊÊÊÊÊ ----> Client (authenticates with App)
ÊÊÊ App <--+ÊÊÊÊÊÊÊÊÊÊÊ (generates session keys and gives them to the Client
and CDN) ÊÊÊÊÊÊÊÊÊÊ ----> CDNÊÊÊ (no private key!)

- We don't want to abandon TLS. Some people want object security. There has to
be a mixture of object encryption and session-based encryption that has the
benefits of both. - In the set of IETF protocols we have there is no
intermediate state between full and no privacy. There is no privacy spectrum.

--------------------------------
Afternoon 1/14/16

# Mobility in ICNÊ

* Realizing Mobility-as-a-Service over CCN -- Ravi RavindranÊ

Dirk Kutcher: This looks like horizontal handover. Another use case would need
a different mechanism. Ravi Ravindran: We always assume the Mobility Service
Controller is within a domain, similar to current cellular networks. Dirk: So
you are replicating anchor-based cellular networks to ICN? Ravi: In
anchor-based cellular networks, the one anchor is always updated. ThereÕs no
anchor here.

Ravi: I call it a forwarding label, not flow label. The forwarding label is
only for routing interests. ItÕs not saved in the PIT.

Mark Stapp: You said your system is more stable than having just a routing
update. But packets get through with the wrong route until you get the first
routing update. Ravi: There is only interest loss during handoff.

Q: Do interests have a nonce?
Ravi: No, but interests that are U-turned are marked.

Dave Oran: Is the forwarding label a hint or required?Ê
RavI; We prefer packets with forwarding labels.
DaveO: If the mobile producer returns to the first station will packets drop?
Ravi: Yes.

Nacho Solis: WhoÕs allowed to add forwarding labels?
Ravi: Only ISR nodes.

Nacho: How is this different than encapsulation?
Ravi: Encapsulation has more overhead.
DaveO: ItÕs not clear that inserting routing diversions in the packet is any
more efficient than encapsulation tunneling. Ralph Droms: And header
modification can lose info that encapsulation doesnÕt. Ravi: If encapsulation
achieves the same thing you can do it. But you can use the forwarding label for
opportunistic routing.

Q: Does the consumer get notification of a handoff?
Ravi: No, the consumer doesnÕt know.

Alex Afanasyev: Clarification - ThereÕs no separate Trace Name Table and Trace
Forwarding Table in NDN. They use use the existing tables.

MarkS: Could youÊ compare with how FaceTime or Skype actually works? It would
be a much more compelling story. Ravi: Skype is peer to peer. MarkS: Not any
more. They couldnÕt make it scale. They had trouble with NAT and now itÕs
server based. So you need to compare to how things actually work now at scale.

Dirk: Take aways - Need to understand better the actual differences between
your proposal and encapsulation. Ravi: If thereÕs a concrete proposal for
encapsulation we can compare. Dirk: Second take away - ItÕs not quite right to
say itÕs just an Òimplementation detailÓ. Ravi: I was saying what info is in
the packet, not how itÕs encoded.

* Supporting Mobility in Named Data Networking - Alex AfanasyevÊ

MP = mobile producer
RP = rendezvous point
HA = home agent

Ralph: At Cisco we have mobility support to modify the FIB with where the
producer is. Alex: ThatÕs covered in Òtrace-state-in-FIBÓ. Ralph: But we donÕt
have a rendezvous point. Alex: The rendezvous point and consumer can be the
same thing.

Ralph: How does the consumer know what name to use for the data. Or how does
the network know to send the data to the hub for that name? Alex: The mobile
publisher publishes under the same prefix as interests which reach the data
depot. An interest can ÒcrossÓ the path and go to the mobile.

Mark Stapp: For the Mapping approach, you have all the problems of scaling to
maintain the mapping. Alex: ThatÕs true.

Nacho: Nameless objects donÕt fall within your tradeoffs table. The name
doesnÕt change. ItÕs just a hash. Alex: Objects are identified. The hash
becomes the identifier. Nacho: I was just observing that nameless objects donÕt
fit in the table you showed.

# ICN Network Service and Privacy

* FLIC/Manifests -- Nacho, Marc, Chris

Nacho: The manifest is a DAG, not a tree. Because leaves could be the same hash.

Jeff THompson: HashValue OCTET[32] means hardwired to SHA256?
Chris Wood: At the moment. We need to merge in hash agility.

Marc Mosko: One could sign a nameless manifest to say ÒItÕs really a Disney
object.Ó Alex: A signature binds a name to data. What is the context if itÕs
nameless? Dave Oran: The consumer still needs to know the context to trust the
signer.

Mark Stapp: If thereÕs no name, then the publisher needs to maintain separate
info for nameless object for what that object is? Chris: Yes, the repo would
need an extra data structure. Nacho: Since all the info is not in the name, we
assume the publisher would typically maintain an extra data structure anyway
for extra meta data.

Nacho: Implementation status of FLIC?
Chris: Fully implemented in CCN-Lite. Alpha in CCNx.

Alex: We need to clarify what we mean by FLIC vs. manifest.
Chris: FLIC is a type of manifest. But yes, we need a session on terminology.

Nacho: Is the group interested in adopting the FLIC work as an RG working
document? Dirk: If no one objects, weÕll bring up the suggestion on the list.
[no objection]

* Options for network support, caching, prefetching etc.

Nacho: Some background - the original ÒmanifestÓ was too general. So we picked
a first step: How to represent a single static object. Hence the FLIC proposal.
We can talk about how it can be used in the more general cases. Dave Oran: It
may turn out the a FLIC object can form a part of the more general objects. Or
we may discover that FLIC has to be made a little more complicated. We need a
laundry list of needs for more general objects. For example, collections of
objects.

Mark Stapp: What to use for rendezvous, for example finding the latest version
of some content? Dave Oran: Whatever handles rendezvous will need something to
represent state, and it could use FLIC. Nacho: We have thought that you send an
interest for the latest BBC page and get back a manifest which is good for the
next hour pointing to the current content, which can be FLIC.

Mark Stapp: Would we want a mechanism to do all of what DASH can do?
Nacho: We still donÕt know if streaming will be so different that we need a
different data structure. Mark Stapp: Even for DASH, dynamic streaming is a
different case. Marc Mosko: FLIC gives byte offsets, but not time offsets into
a video. Nacho: A video application typically has its own native way to
optimize indexing which we wouldnÕt put in the standard. But there may be a
middle ground where we can offer more structure to help this.

Ravi: Each content object should have a name, but able to be duplicated at
different locations. Nacho: You want a name and locator, separate. To be named
ÒfooÓ but get from ÒbarÓ. Mark Stapp: You should write a draft that shows how
to do that. Dave Oran: ThereÕs a deep mental model difference between Òone
object with many names (which imply different locations to get it)Ó vs. Òan
object with one name plus other hint names for where to get itÓ. This mental
model difference may underlie a lot of the discussion. But ultimately I only
care to be sure that the thing I got is what the producer produced.Ê Borje:
Also depends on what you think the name is. If the name is the hash, you donÕt
care about checking signatures.

Alex: In HTTPS you trust the binding between the data and the name.
Marc Mosko: In HTTPS, what you actually trust are the root certificates which
are pre-loaded in your browser.

Alex: I have replicas of the ndnSim in Latvia and U.S. How to handle that? Need
a way to put a link object with the location in the interest. Marc Mosko: That
assumes that the network can decide where to go better than the application.
Alex: Yes, of course. Dave Oran: The object function may not be Òget the
closestÓ but some other function with policy implications. The network may not
be able to handle all the cases. People have tried to put such resolution in
the network but have wrapped around the axle with general policy languages.Ê
You have to put it in the client. Maybe the client doesnÕt want to get it from
Iran. You canÕt have the network handling these cases.

Dirk: In summary, FLIC manifests will be a core mechanism. LetÕs think about
how mobility could make use of this mechanism. And letÕs think about what other
features we want from more general manifests.

----------------------------------------

Day 2 Morning Notes 15/1/2016

Agenda:
ICNRG documents
status: challenges, video, eval
CCNX messages & semantics -- Nacho, Marc, Chris
Nameless objects -- Nacho, Marc, Chris
Key exchange -- Nacho, Marc, Chris

ICNRG IETF Document update:
1. ICN Challenges draft : IRSG provided feedback on the draft, comments being
addressed now 2. Video streaming draft send to IRSG review, being undertaken now

Presentations:

Marc: CCNx specification updates
- Main changes - hash agility - new formats for some fields
- New interest return codes
- LCI name clarifications
- optional header for carrying contentobjecthash inside a trusted domain

Should this be calculated for all content objects ?
- should be calculated based on the interest request

Multiple type of hash support in the network?
- Nodes should know the hash algorithm capability, if it doesnt support, then a
Interest return is expected - to support both SHAH-2/3

ContentObjectHashRestriction: Encapsulation of the hashid type ?
- the best approach
- The hash algorithm is referred as a sub-tlv
- Reuse type values based on different contexts
- Encoding efficiency
- Experimental values reserved for other type of hash algorithm
- affects keyidrestriction and keyid, contentobjecthashrestriction,
interestPayloadID

New Return code for hash algorithm that cannot be computed

Malformed Interest
- the Interest return is also malformed

Name clarifications
- T_name WITH LENGTH 4 AND T_NAMESEGMETN with 0 length corresponds to LCK:/NAME=

This is mostly required for:
-  for default route, mostly for management purpose
- have a separate LCI document

LCI is confusing, call in CCNx or something else

typing LCI name in the browser  ?
- yes

what about old spec, definition for zero length components ?
- CCNx-0.8, did not have type..

Namelesss Objects
- with no name
- very first TLV in the packet

content object to interest matching
- should have a hash restriction if it is without name

At what point do you compute Hash restriction ?
- need to compute both hashes for incoming content objects ?
- option to drop one of them..e.g. SHAH512

Can the CO carry the type of hash algorithm ?

contentObjectHash inside a trusted domain ?
- Router can compute the hash in the network and insert into the packet
- privacy implication ?
- Border nodes within trusted domain computes the hash

Marc: Nameless Objects
- Hash Based Names
- Hash restriction is the only way to name immutable objects
- optional KeyId and the object Hash
- Nameless object does not imply trusted
- trust chain for immutable

Is calculating SHAH expensive ?
- yes, has to touch every byte of the packet

Affect on fib lookup ?
- shouldnÕt be affected

Christopher :CCNx private communication

- need ta way to establish session keys between consumers an producers..
- consumers know the prefix of the producers
Round 1) Obtain the server config
Round 2) hello handshake and estabilish ephemeral keys
Round 3 )Exchange the data

Results in a bi-directional communication
- different symmetric keys for bi-directional keys

who names the consumer to send interest to it ?
- ?

Service affinity to a particular instance ?
-
Key Material Generation

Client Authentication
New Material
- optional consumer-provided prefix in Round 2 interest
- optional client authentication
- server challenges
- updated key derivation procedure to support re-keying

Map an existing certificate to CCN ?
-
Session Rekeying
- Consumer and producer generate a keyupdate message in an interest or content
after Round 3 is finished

Key Material Generation

open issues
- identifying the minimal producer routable prefix
- balancing consumer/producer work for the round 2 Interest

Broadcast encryption research in CCN
-

Chris:
TLV Encryption and packet Encapsulation
- Specify an opaque tlv to encapsulate encrypted objects-
- T_ENCAP tlv
- Wrap interest and content objects in T_ENCAP TLVs
- Routable prefix /prefix
- An identifier for the encapsulation decryption key and salt
- The encryption nonce
- similar in Components
- Interest Encapsulation
- Content Object encapsulation
-
separating the function the content auditing from content distribution
- encrypted private access from the content aggregator

----------------------------------

2nd session on Friday 15/1/2016

ICN in Disaster Scenarios -- Jan Seedorf

- updated the draft, incorporated feedback from DTN community and others
-  asking for adoption
- not many people have read it
- chairs: will remind people on the ML to read it and would then ask for
opinions on adoption - chairs question: do people think this is something the
group should work on
  + Dave (individual view): important scenario, could add thrust to ICN adoption
  + Alex: agree
Ravi: also would like to advance decision process on merged IoT draft
Chairs: will send out reminder on ML

Terminology -- Dave Oran

- important to have common terminology
- Christian Tschudin and Dave Oran wanted to start some work
- plan is to have something for IETF-95
- asking for additional contributors: Nacho
- Mark Stapp: is the idea to update this frequently?
  + Dave: should not be that dynamic
- Dave: no intent to hold up any work with the terminology document -- will be
complementary and be done in parallel

ICN DevOps -- Dirk Kutscher

- CCNx implementation in Clojure for edge devices, applications etc.
- work in progress, to be released soon

Other Business

- next meeting: interest to have regular meeting and full day Sunday meeting at
IETF-95 - discussion about work on routing in ICNRG: please bring contributions
- discussion about normative specs and possible IETF WG: different possible
scenarios

Meeting finished at 1:30