ICNRG Interim meeting London, UK, Sunday March 18, 2018 ¶ Note-takers: Bastiaan Wissingh (morning), Cedric Westphal (afternoon) 9:00 Meeting starts • Welcome, Agenda Bashing, Minutes taker, Bluesheets, Status - Chairs (10 min) • Hybrid ICN (hICN) - Luca Muscariello (25 min + questions) Dave; These IPv6 addresses you mention, are they intended to be topologically independant? E.g. treated as anycast addesses?enumeration Luca: Yes, that's the intention. Lixia: the routing system does not tell whether a prefix is unicast or anycast Dave: So the matching scheme in this case is CCN Exact matching, not NDN Longest Prefix matching? Luca: Yes Dave: In regular IPv4, ICMP does flow hashing. Here it does not make sense to do this flow hashing, right? Luca: Right Ravi: How is the ICN payload encapsulated here? Luca: There is no ICN encapsulation, it's called hICN. See slide with packet layout. ??: Do you consider NACK packets also? Luca: Yes, it implements the concept of ICN, so you can do that. Dave: the locator part can not be part of the signature? Luca: no, some fields have to be set to zero before calculating the signature Jan: how about opensource? Luca: everything is opensource in CICN, except for the hICN libraries. But they are available for use. • Map-Me: Managing Anchor-less Producer Mobility in Content-Centric Networks ( https://mapme-tnsm17.github.io/) - Giovanna Carofiglio (25 min + questions) Thomas: do I understand that for every update you flood the whole network?  Giovanna: No, you are following fib entries upstream Thomas: but then you have to flood all fib entries Dave: you flood the spanning three Jan: so what if the producer moves out of the spanning tree? Thomas: this is an Intra-domain protocol • Map-Me implementation in hICN and applications to next generation mobile networks - Jordan Augé (15 min + questions) No questions • FD.io/CICN open source project - update on the consumer/producer socket API and HTTP support - Mauro Sardara (15 min) Dirk: the way you deal with web traffic over ICN, would be very interesting for follow-up discussions. Mauro: yes, maybe for next time, when we have done some live distribution with hICN • PyCN-lite (for IoT, running MicroPython?), and PiCN (for NFN) - Christian Tschudin (15 min) Dirk: Any measurement data regarding throughput? Christian: Not yet, we first focus on functionality Thomas: As a remark on Python, IoT and RIOT. MicroPython is currently not ported to RIOT, but if it is done, it would rule out certain more limited boards. Christian: yes I agree with that Dave: anyone tried this in a unikernel? Christian: not yet Lixia: is the security layer still weakly implemented? Christian: yes, I think that is still true. Currently implemented signatures. 
• “Enabling Dynamic ICN Multicast in Cellular Radio Access” - Ravi Ravindran (15 min) Dirk: Interesting topic, maybe next meeting focus on key technical issues, and how ICN can really help there. • New draft: (based on Contrace): "CCNinfo: Discovering Content and Network Information in Content-Centric" : https://datatracker.ietf.org/doc/draft-asaeda-icnrg-ccninfo/ - Xun Shao (15 min) Dave: the reason you depend on the timeout rather than the response, is that a single request can have multiple responses right? Have you thought about how to allocate the link resources for these things? Dirk: you are ignoring flow balance here right? Xun: There is no flow balance. Dave: (chairhat off) indeed merging with traceroute won't work because they are quite different. Technical comment, since your planning on returning lot of information, channel allocation is made really difficult. Borje: How far are you planning to distribute these Interest messages? Xun: There are hop limit and timeout options Dave: I think we need a way to trade off the resource expanses on the exploding amount of data that might be returned. Eve: This problem of 'explosion' of returned data is applicable for more use cases, so it would be very interesting if some one can come up with a solution for it, not only in the case of CCNinfo, but in a more general way. 
• Demo: "Deployment of ICN stacks and NDN in particular by leveraging NFV" - Guillaume Doyen (20 min) [Demo introduction and demo. The demo will also be shown at the end of the lunch break and at the afternoon coffee break.] Dirk: for scaling monitoring, are you only monitoring PIT size, or more? Guillaume: only PIT size for the moment. Dirk: have you made any measurements to see how the system performs when under attack? Guillaume: that is something we are working on at the moment, to the amount of good versus bad content. 12:30-14:00 Lunch • New draft: "Requirements for Key Management in CCN/NDN” : https://datatracker.ietf.org/doc/draft-li-icnrg-km-reqs/ - Ruidong Li (15 min) Eve: Have you thought about fetching keys when connectivity is intermittent? Ruidong: We will consider it. Dirk: From chair's perspective, we avoid "requirements" and suggest "considerations". Eve: There are requirements for use cases. Borje: This has a lot of general requirements for all key management. We should focus on ICN-specific. Dave: We want long-lived content, but short-term keys. We'll want to iterate this question a lot. • New draft: "DABBER: Information-centric Routing for Opportunistic Wireless Networks" : ( https://datatracker.ietf.org/doc/draft-mendes-icnrg-dabber/) - Paulo Mendes (15 min) (No questions.) • New draft: "Architectural Considerations of ICN using NRS” : https://datatracker.ietf.org/doc/draft-hong-icnrg-icnnrs/ - Jungha Hong (15 min) Q: Is the resolution done by the consumer? Jungha: It's done in the application layer just like DNS lookup.  Dirk: I think this is a productive way to address NRS, so thank you. • Revised draft: "CCNx Extension for Name Resolution Service" : https://datatracker.ietf.org/doc/draft-hong-icnrg-ccnx-nrs/ - Jungha Hong (10 min) • Revised draft: "Requirements for Name Resolution Service in ICN" : https://datatracker.ietf.org/doc/draft-jhong-icnrg-nrs-requirements/ - Jungha Hong (10 min) Dave to the room: Please review the draft. It's been through a number of good revisions. • ICN control signaling - follow up from the Berlin meeting - Thomas C. Schmidt (15 min) Thomas to the room: So, should we introduce a 3rd packet type for control signaling, not Interest or Data? Christian: With RPC, I avoided introducing a 3rd packet type by allowing manipulating the PIT. Dave: We have to tease apart types of attacks. You can't necessarily prevent the attack by using a packet that doesn't keep state. Dave: What's the difference between a new protocol vs. Interest/Data exchange that only goes one hop? Thomas: I can use an Interest to trigger someone else to ask for something. Dave: If the trigger is for some third party to reply, then you could get redirection attacks. But between two parties I don't see a problem. You may be asking "how to do three-way information exchange" but it's not limited to control signaling. Lixia: The new NDN Interest format will have an Interest parameters field. So you should use use Interest/Data exchange unless it is proven infeasible. Börje to the room: Do people think that putting extra data in the Interest is a bad idea? Dave: If a larger Interest causes fragmentation, you should rethink. Also, everything in the Interest name needs to come back in the Data packet name. There could be cut and paste attacks. Finally, you want to avoid having to authenticate an Interest. Dirk: Currently we don't see anything that precludes using Interest/Data. Maybe there are other use cases. • Revised draft: "Publish-Subscribe Deployment Option for NDN in the Constrained Internet of Things" : https://datatracker.ietf.org/doc/draft-gundogan-icnrg-pub-iot/ - Cenk Gündoğan (10 min) Ravi: Did you consider the case for mission-critical low latency? Cenk: It's the same as Interest/Data exchange. Ravi: We've been calling for a push primitive. • Revised draft: "Design Considerations for Applying ICN to IoT" : https://datatracker.ietf.org/doc/draft-irtf-icnrg-icniot/ - Ravi Ravindran (10 min) (To save time, Ravi will summarize the changes on the mailing list.) • Revised draft: "Forwarding Label support in CCN Protocol" : https://datatracker.ietf.org/doc/draft-ravi-icnrg-ccn-forwarding-label/ - Ravi Ravindran (10 min) 
(No questions.) • Revised draft: "File-Like ICN Collection (FLIC)" : https://datatracker.ietf.org/doc/draft-irtf-icnrg-flic/ - Christopher A. Wood & Christian Tschudin (10 min) Dave: We should support some parts encrypted, some not. Christian: So maybe not encrypt the index table. Dave: Or different parts encrypted with different keys. Luca: Is there a way to rebuild the manifest efficiently? Christian: For me, the manifest exists persistently along with the data. But tell me if you know a use case to construct a manifest on the fly. Dave: If you can package the manifest and data in one object, you could make the manifest obligatory and get everything in one round trip. Dirk: FLIC is a potential core spec for the group. • Revised draft: "Network Coding for Content-Centric Networking / Named Data Networking: Requirements and Challenges" : https://datatracker.ietf.org/doc/draft-matsuzono-nwcrg-nwc-ccn-reqs/ - Cedric Westphal (10 min) Dirk: Experiments? Cedric: An implementation based on a student from University of Bern. (Further questions deferred to the NWCRG meeting.) 17:00 Meeting ends (the latest)