9:00-10:30 Session 1 Note taker: Dirk Intro by KenKen The Futility of Data Privacy in CCN - Gene Tsudik (45 min) * Q, Asami-san: meta info privacy in CCN? * A: yes, need to say what you encrypt and what not * Q, Asami-san: DPI in SDN/NFV in IP world, but in CCN it may be different * A: at network layer, IP just gives you addresses that map to location. In CCN, you could potentially see the full application name -- you get more "for free" * Q, Asami-san: two types of people: those who care about privacy and those who don't * DaveO: people may not care about privacy from google, but maybe from NSA or ISP * Asami: privacy-by-default? * N.N.: In CCN, we increase the scope to everything in the network. In Gmail, it's just about one application. * Q, George: what if we include some randomness and multiple copies of packets (confusing adversaries) * A: that would be a hand-waiving approach... * Q:, Marc Mosko: would IP & TLS be weak privacy according to your definition? * A: no -- you generate new keys for each session -- cannot correlate between two users * Q: Marc Mosko: but you can correlate requests to responses * A, DaveO: not if server changes order of responses * Q: Asami-san: according to CCN spec, users can specify whether data should be cached or not * DaveO: adversary can always intercept and cache, so cache control would not provide privacy * Asami-san: turning on encryption would also reveal information about privacy concerns * Q: Börje: in media distribution, not everything needs to be encrypted for privacy * A: yes, not every application needs privacy * Gene: may have to do equivalent to IP+TLS * DaveO: CCN-KE draft specifies this is * Marc Mosko: can still do symmetric encryption for some content. Some content providers do not want operators to see who is seeing what (so individual encryption) * Gene: so problem is worse? * Marc: yes * Dave: would not characterize as better/worse. Question is: where to provide caches that are trusted by one or multiple players. Need to be more nuanced and put caches into a trust framework * Jay: need to qualify what we mean by privacy * Marc: today everything is bundled in TLS * Gene: TLS only mitigates some privacy issues -- CCN does not -- goal is to make people aware * Jay: proportion of traffic that needs privacy makes up no more than 10%. For caching, need to understand what we need to cache * Gene: state actors etc. can mount strong adversary attacks * Börje: then we need stronger regulation. can also have attacks on devices (to get viewer statistics the TV industry is including hardware in TVs that do image recognition of what is on the screen, so it does not help if you get your content via an encrypted link or just play from your old VCR, they will still know what you are watching.) * Gene: all security will be broken eventually (no longevity) * Marc: problem of self-identification if encryption is not ubiquitous Survey on ICN Security, Privacy, and Access Control - Satyajayant “Jay” Misra´ (45 min) * Q: DaveO: re content poisoning: are you mixing that with cache pollution? What does it have to do with interest hashes? * work by Gasti et al -- to be discussed offline * Q, DaveO: Google Bombing attack. Large groups of users collude to manipulate popularity, rankings etc. * DaveO, different ways for delaying responses from caches, e.g., adding delay when delivering cached objects * DaveO: for adaptive media-streaming, delaying could also be useful * DaveO: "don't cache" is like the "evil bit" * Jay: With ICN multi-path and network coding parts of the content can be requested over different interfaces, especially useful against censorship 10:30-11:00 Coffee Break 11:00-12:30 Session 2 Note taker: Bastiaan Traceroute & Ping - Jim Gibson (30 min) * MarcM: Forwarders need an identity, not specifically a name. * N.N: What would be the difference between an Identifier and a Name? * Jay: adding signing to ping will more accurately estimate rtt * DaveO: applicable to dynamic generated data packets? How do you tell the difference? * MarcM: Do you allow client to ask for specific payload size? * Jim: Currently not in draft, only minimal size based on TLV * DaveO: because of the cost of signing, more concerned with signing when consumer is trying to get info on your forwarder * Asami-San: According to discussion, network management of ICN seems more complicated. So is ping for ICN quite complicated? * MarcM: Example, Verizon names all routers they want pingable. Summarize in exchange to external world. You don't always have path symmetry. -> One namespace for router, different namespace for application connected to router * DaveO: pinging router versus pinging application connected to router, might give different paths. * MarcM: are you pinging a piece of infrastructure? * DaveO: no, you are pinging a FIB entry. * N.N: as soon as you hit a FIB entry, would then that forwarder name be the box? * DaveO: that's why we return the corresponding forwarder name then * MarcM: does that name need to be globally routable? * DaveO: you can never force that * Jim: assumption, if we are doing the case of pinging a router name, it would be close to the application. Flow classification - Dave Oran (30 min) * Asami-San: Could you define security envelope? * DaveO: The thing that is hashed and signed by producer, is within data packet. Immutable for lifetime of packet. * Jay: Could you give a example of regrouping? * DaveO: Not part of the name. One day, classify * ??: Any scheme for different producers that define same classes (EC3 scheme)? * Jay: For example, one producer chooses 5 equivalence classes, another producer 1000? How does forwarder decide? * DaveO: Depends on how much the forwarder decides to remember, e.g. due to memory, cpu limitations. * N.N: when you include class in security envelope and is cached. Do you also cache security envelope? * DaveO: yes * N.N: three different classes, will they be considered as different objects? * DaveO: yes * Jay: (ECNCT scheme) several subflows with own class, subscribe to super flow. What would you recommend, longest, shortest prefix matching? * DaveO: Not sure * MarcM: Should flow class be part of name? * DaveO: That's one of the questions * DaveO: Consumers can ask for certain treatment, but this just says what should we do with the different classes. * DaveO: two questions on last slide, any feedback? * Jay: I like the second solution (ECNCT scheme), but some aspects seem "scary". We should think/experiment * Dirk: are you in position to present some experiments? * DaveO: unfortunately not * George: Isn't it clear that second mechanism is more globally explicit? Interesting that it doesn't mean any thing about the treatment of classes. Isn't it useful to have explanation about ordering of treatment of classes? * Borje: we need to think in parallel what these treatments mean, e.g. do we cache something longer or less. * Dirk: people have been doing experiments on this topic (in general). See in experiments * MarcM: doing it in the name has some interesting things to it, but also some drawbacks. * DaveO: observation, this seems like the service equivalent of whether or not to have hierarchical names versus flat or attribute-based names * Jay: we are trying to design and ICN architecture for smart grids, where flow classification is also very important. 12:30-14:00 Lunch 14:00-15:00 Session 3 Note taker: Adeel Discussion on the three congestion control papers at ICN2016 (30 min) * Börje puts forward some questions in a slide * Jim: Identify a bunch of mechanisms that could help and use them together. * Bengt: If you don't have a window, it is hard to do a fast retransmit. * Bengt: NACKs can be sent for losses if the losses can be detected. * Jim: Don't have any intuitions of the coexistence of the ICN congestion control approaches and TCP because MIRC/PCON are multipath. * Dave: We didn't look at how it would be if TCP runs over ICN than if it runs over IP. * Dave: We were not running any sophisticated congestion control on ICN in our TCP over ICN work * Marc: Combining multiple control loops that don't know about each other is asking for trouble. TCP operates on byte level when it comes to congestion control. * Jim: The SAID paper was an interesting idea but I don't see how that quite fits in. * Marc: I did not understand about the SAID approach how the publisher knows which byte was asked for. * Bengt: I am interested in the stability properties of the congestion control. Two things, per-hop and multipath. I am not up to date how MIRCC has designed the per hop regulator. * Dave: For the unreliable proxy every arriving TCP packet is treated separately. * Dave: Congestion control for ICN is potentially a career for people and not merely a project :-) * Dave: Van Jacobson has recently published some new work on congestion control. * Bengt: In MIRCC did you figure out a way for the routers to split Interests over outgoing interfaces for a certain prefix? * Jim: We did not figure out a good way. So we chose to go with a client scheme. * Börje: Contributions and discussion on the mailing list are most welcome. Status update on the CCN/NDN harmonization efforts - Alex/Lixia (30 min) * Dirk presents ICN Harmonization Activity Update slides that Paul Polakos put together. Paul was one of the drivers of this activity. * Alex presents his and Lixia's slides on Identifying NDN/CCNx1.x Commonalties and Differences, a high-level summary of the discussions so far. Described the common starting point of CCN and NDN, different goals drove the branching out of the two. * Lixia asks Marc if PARC's protocol changes mentioned in the slide look fine. We want to get it right, hoping to produce a summary draft by Seoul IETF. * Marc: Loosely synchronized clocks are needed among all caches and not all routers. * Marc: Before CCNx 1.0 the definition is about whether a cache entry is stale or fresh. CCNx 1.0 changed to whether cache entries are alive or dead. * Lixia: Any other major changes since CCNx 0.8 missing in the "Parc Protocol Changes" slide? * Dave and Marc: Typed name components * Dave: There are a number of other things that have changed which are not in the slide e.g. key and hash restrictions, etc. but they are secondary level, not architecture * Marc: the selector (including exclusions) draft is technically not part of the ICNRG drafts but an individual contribution. * Alex: One thing not mentioned is scope which was in CCNx 0.8. * Marc: Yes * Dave: Nonces have been removed from CCNx 1.0. * Lixia presents the changes in NDN after the branch out: Our fundamental goal is to experiment with the architecture. That is why we have tried a number of diverse apps, fill in missing holes, identified new issues. In particular we noticed security was a weak point in early app development, so we put in effort and fixed it (schematized trust). Our focus differs. PARC focused more on performance. We could not change the code even before the split. We made the NDN software package modular. * Dave: cisco code pushed for understanding "big O" aspects of performance, but believe PARC's forwarder is also quite modular and flexible. * Lixia: PARC's focus has been mostly the forwarding plane and not trying out a number of different applications to really test out the architecture design. Still so far the discussion shows that the NDN team and the CCN team had pretty different focus. * Dave: A lot of the work that has been done on performance was not to do optimization but to check the inherent performance characteristics of the different elements of the architecture. These characteristics are equally important for testing the architecture. * Lixia: as we discussed during ICN16, ICN can effectively solve IoT, V2V, ad hoc, DTN problems -- these are low hanging fruits of ICN at the edges. ICN can make a fundamental impact at the edges where TCP/IP does not offer good solutions. * Lixia: We are pretty far from the point where we need optimized performance inside infrastructure. If we really want to make a big stride to move ICN forward we should really look at the low hanging fruits. * Marc: We need to be careful about protocol scaling problems. * Lixia: I agree, here are a group of protocol veterans with scars in protocol designs. we learned. * Dave: Jon Turner who worked with ATM figured out how to forward IP packets fast using hardware designed for ATM * Börje: I agree with both Lixia and Dave. We have to look at both sides, keeping the architecture open and performance characteristics. It is a difficult balance. * Dirk: Industry is waiting. * Lixia: down the road the Infrastructure will change. Proactive Content Caching Utilizing Transportation Systems and its Evaluation by Field Experiment - Yo Kakuhei (30 min) * Dirk: Can you say anything about the LTE utilization and load? * Yo: Yes it is in the slides. * Börje: How do you get data into the cache before any user requests it? What protocol do you use to put data in the cache? * Yo's colleague: We used MPEG-DASH and some scripts. And we use CCN. * Dirk: How CCN has actually helped you in this? Pre-fetching is their in current technologies too. It was not apparent what CCN brings to this. * Yo's colleague: With IP you need to build an application and a proxy, with our solution we use inherent caching of ICN. 15:00-15:30 Coffee Break 15:30-17:00 Session 4 Note taker: Jim Information Centric Networking for Disaster Information Sharing Service - Wen Zheng (20 min) * DaveO: Did you use ICN to do reverse geo-coordinate mapping? * Wen: No, it's a standard db with interface not ICN * DaveO: Seems it might have some interesting issues * Dirk: Any interest in participating in ICNRG disaster group, have you see the doc? * Wen: Yes, I've read that document * MarkM: With respect to using LatLong: LatLong is a point, not an area. There are other coordinate systems that represent areas and that could be encoded in the name, e.g. to scope to different granularity areas. * Wen: Yes, started with a system based on a single point, have some ideas about how to progress that. CCN aggregation scheme - Marc Mosko (20 min) * Borje/Dirk: What's the definition of "similar Interests"? * MarkM: depends on which protocol version. Currently is name,hash restriction,key restriction * DaveO: What about HopLimit: If the newer Interest's HopLimit is higher, naively you should forward it. * DaveO: What does "pass a ContentObject in flight" refer to? * MarkM: There's a weird race where Interest2 is sent up while ContentMsg is going down, and in that case the ContentMsg can get sent on a link twice. * DaveO: Maybe I'm quibbling with the words, but your description doesn't seem quite right. I'd say "You'll never get more Content than sent Interests. In the worst case, due to passing in transmission, can get as many Content objects back as Interests sent. * MarkM: Also, duplicate ContentObject will get killed off after traversing one link, since no PIT entry. * DaveO/MarkM: discussion of difference between cycles and spirals. MarkM asserts that can't have same cycle, but can have successively smaller cycles because TTL has been decremented. * JimG: what's a route with a 0 hop count. * MarkM: cost is 0. * DaveO: Cool feature but sounds like premature optimization. Adds requirements to routing protocol, special cases to traceroute, etc. * MarkM: concept is to be able to reduce Msg.HopCount by more than 1 at a hop to terminate cycles faster, especially given that we do not choke off looping Interests that arrive on same Interface -- we categorize them as retransmissions that should be forwarded. * DaveO: example routing protocol issue -- with a dv protocol, can't "find largest distance of all downstream routes" to make sure that the routing entry hop limit field is correct. * Lixia: Can this issue be solved by putting the Nonce back in? * MarkM: Nonce needs to be stored even if PIT entry got wiped out. * Lixia: Sure, but this will work most of the time. I had planned to finish a writeup talking the importance of nonce. As we want to forward Interests more liberally utilizing wireless channels, more chance of small loops, need nonce to break loops. TTL is ineffective in killing small loops as it counts into infinity. * MarkM: agreed that nonces are useful with "Information foraging environment" (lower-performance exploratory forwarding systems), but CCNx1.0 has HopLimit as the mandatory approach, Nonce is optional. * DaveO: MarkM and I have a deterministic loop suppression algorithm if we can store 2 64-bit values (128 bits total). * Lixia: not great for IoT * MarkM: sounds like the feedback is that HopLimit decrement is too complicated. * DaveO: off-the-cuff, seems it won't work * MarkM: Then need another mechanism if worried about the count-to-infinity problem. Highlights from Research (e.g., topics from conference or other activities) (30 min) * Borje: Any topics that ICNRG should add? * Dirk: Retransmissions :) * Borje: ICN-over-broadcast-media? * MarkM: Needs to consider Nack (or Success) storms. Either need to be prepared for many responses or a GOSSIP-type approach. * Lixia: work has already been done on these problems in other domains * MarkM: yes, but need to do that in ICN or else do OSPF-style approach, can't casually talk about broadcast and not think about this. * DaveO: IS-IS mechanism is much better than OSPF, which requires configuring for leader and backup * DaveO: Doesn't work well in 802.11, since multicast is unusable. * DaveO: Differentiation of services RG maintenance/admin (20 min) * Planning for future Interop / Hackathon * Terminology * IoT document * Planning for Seoul * Interim meeting on Sunday? * Joint meeting with T2TRG in Seoul? * Borje: Makes sense to me to talk to other RG, to avoid pointlessly diverging * Lixia: How about "slow start" :) 1/2 day joint work with T2TRG, 1/2 day work on own. * Borje: Should we meet on our own first or meeting with T2TRG first? * MarkM: Should we shoot for a draft-of-a-draft on harmonization? * Dirk: Doesn't need to be complete * MarkM: We could write up what we have now, which is a lot. * Borje: Sounds like there is interest from NDN/Lixia and CCNx/MarkM? [Yes -- make final decision on mailing list] * Lixia: need to confirm Sunday meeting, so we can make travel reservations * Borje: Okay, _yes_ to Sunday meeting, agreed here on the spot. [End]