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