Agenda: https://trac.tools.ietf.org/group/irtf/trac/wiki/icnrg Session 1 -- NDN architectural principles (Jeff Burke) https://www.ietf.org/proceedings/interim/2016/04/03/icnrg/slides/slides-interim-2016-icnrg-2-2.pdf Nacho Solis: Should we bring up issues from the mailing list here? Dave Oran: Yes, but the crowd here doesn't represent everyone on the list. Nacho: It is unclear that every principle applies equally to every part of the architecture Jeff: Yes, they highlight different parts/levels/layers in the architecture, and this could be made more clear later. Nacho: It would be helpful if we also discussed where each principle applies in the architecture. Jeff: They come from and focus on the NDN thin waist. DaveO: This can help discussion about what should or should not be in that waist. Nacho: Hard time treating the principles together (e.g., DTN-style communication in the Universality principle doesn't jive with the flow control principle) Jeff: Universality slide is intended to capture certain applications and how they depend on the network layer. Nacho: "What is it not?" If a principle means NDN is X, what is NDN *not* (or what does it lose)? DaveO: Packet format semantics need to be universal (not the encoding). IP had disparity between semantics and encoding -- it wasn't clear how encodings could change without affecting the semantics Jeff: In the IoT case, we aren't defining new semantics (universal). Nacho: How about non-bidirectional links? Jeff: Don't think those are ruled out. DaveO: Non-universal does presume bidirectional links Marc Mosko: Principles 2 and 3 have issues with bidirectional links Ralph Droms: Some problems with IP comes from trying to push IP functionality down (to be universal, e.g., to extend over L2). Can we write down the L2 properties that NDN depends on? Asymmetric links is one example of a property that L2 doesn't provide but NDN depends on. Dave: Second bullet slide 6 (r.e. protocol evolution) is a sufficient condition, not a necessary one. Nacho: What about push? Universality is about supporting different types of mechanisms. If push is needed (for some applications), why is it not included? Jeff: Is push-style communication the application the network requirement, or is it just how the application achieves some goal? Dave: Might not be necessary for all principles to be conflict-free -- some goals can be in conflict. e.g., push and flow balance are in conflict Jeff: Is the goal of universality to achieve *all* types of communication or application support (to resolve all mismatches), or to achieve those which NDN is designed for? Nacho: Do you think IP and CCN also have the universality principle? Jeff: Yes, it seems so. (Chris: maybe misunderstood) DaveO: Another goal is "fungability." Many things in IP were deprecated without killing the protocol The functionality was sufficiently encapsulated so that poor design decisions don't break the protocol. Marc: One could argue that IP is not universal -- take NAT and application proxies as an example. Dave: But those broke the IP principles Marc: Some people do NAT for address space problems (that seems to have broken the IP universality principle) and security Dave: If you use it for security you're wrong Dave: Can you elaborate on the second principle (only data in specific environments should go to the network adaptation layers)? Nacho: What does it rule out? Marc: If I have a public key in a packet, does it exist in the same "context" as the name? It won't be used at L3, only above. Jeff: Notion of data provenance is seen as a universal requirement. Nacho: What about the LINK object? Where does that fall here? Jeff: The LINK object is something that's part of the interest (it directs it somewhere). There's a separation between the notion of data and it's name (and signature). Nacho: (describes how LINKs are used) DaveO: A LINK object is a semantic that's defined above the base network protocol. Nacho: No, it can't be. You have to forward on a LINK object. DaveO: Name indirection is a fundamental element of the architecture (it isn't layered on top) - should this be part of the principles? Nacho: First bullet on slide 9 seems to be incorrect if you bring LINKs (indirection) into the protocol. DaveO: An alternative architecture that uses indirection would have included encapsulation as a principle. Jeff: I don't think encapsulation is ruled out -- need to chat with architecture folks Jeff: Data being defined independently of the communication environment and being the fundamental unit transferred in the network is the point here. Marc: Some aspects like "Content Type" are transport features. Those might be a better example of a public key since it's related to the data. Nacho: There's a max packet size? Jeff: Not by the architecture, but by the protocol DaveO: First bullet on slide 9 is false (there's lots in a packet that is unrelated to the data, e.g., nonce) Jeff: If the bullet said "data packet format" instead of "packet format" would you feel the same? DaveO: Yes. There are a number of fields that can be in packets that are unrelated to the data (e.g., "distance" from the consumer from which you fetched the data). Question: In the case of using ICN for IoT, you might have data that's used in specific environments (and not others). Jeff: (missed) Marc: New fields/TLVs are being made flat in the packet. With a layered approach, there are nested contexts in the packet. This is seems to be a dichotomy (packet flexibility vs keeping packet format minimal for L3). Nacho: Negative of the principle: NDN elements and packet format should not include information that is not data related. App data does not get modified or appended to by the network at all. InterestReturns and Interests are not related to the data. There is some part of a packet that the application owns. The app has to own some piece of data that is network interpretable (so the packet can be moved by forwarders) DaveO: Another level of nuance -- things that are end-to-end from the protocol vs things that are hop-by-hop The notion of having an adaptation layer has to have some notion of preserving end-to-end semantics Ralph: End-to-end semantics might extend above L3 (data distance could be useful at higher layers) DaveO: Be very careful of what portions of the protocol are hidden in a layer and not exposed and what portions/semantics that need to be exposed across the layer boundary Jeff: What is the layering strategy or approach? We would like input on the approach: Ravi: Two levels of management: (1) names, keys, etc. and (2) network management. If everything is in the application scope then how does a network entity use it? Jeff: It would be nice to see a design principle in terms of what falls into the "forwarder strategy" bucket. Missing things just haven't been articulated yet Marc: If one uses hash-based names in NDN/CCN, you can say it's immutable data. Otherwise, it's just convention that data is immutable. (Producer that has signed something won't or must not generate something with the same name and different data.) Jeff: Same with hash-based names? Marc: Not really -- immutable data is really being moved with hash-based names. Marc: Ramification of principle then the majority of packets must use hash-based names. DaveO: Problem: Producer publishes something with given name (it's assumed to be immutable). If someone requests it with the hash then it's immutable. If a producer publishes new data under the same name then the data is not immutable. Th Nacho: If you can get different data for the same request, then the data is not immutable (from the application's perspective). DaveO: Immutability is a result of hash-based requests. DaveO: Another weird example: at every hop, the router modified the data using the number of hops the data was away from the consumer. Consumer requests data by knowing this distance and generating the right "request." What exactly is immutable here (since the request is changing but the correct data was returned)? DaveO: What about "immune from undetected modification" instead of "immutability"? Marc: What about incomplete requests? Jeff: Response is not *not* immutable -- application needs to determine if that's the correct immutable thing DaveO: "NDN should be capable of fetching uniquely named immutable data packets" Nacho: Every piece of content has an immutable name that has to be somehow based. Both architectures let us retrieve the data using this immutable name (with hash) All agree that there's a unique way to name data (-> with a hash) Jeff: Name, data, and signature content is considered to be unique Marc: Maybe rename as "Data producers should uniquely rename their data so that they don't reuse names" and "you should be able to detect unintended modifications to the data." Jeff: The definition of immutability (as written) is for hash-based names and name+data+signature names/requests. Ralph: When producers use the same name, do producers include the hash in the name? Marc: "Should" on the slide that hash-based names are used predominately but that's not the case in NDN (unique produced names are what's used) Ralph: Second bullet seems to contradict the first on slide 10 DaveO: Slide 13 -- use integrity instead of security Jeff: There was a reason that we generalized it (maybe confidentiality properties are included as well) Ravi: What about flat names? Dave: Flat is a degenerate case of hierarchical names Ravi: But how do you route on flat names? Why not use something like "hybrid" to capture flat names as well? Jeff: A flat name is a single component Nacho: You're ruling out attribute-based naming DaveO: And DAG-based naming Jeff: You can do attribute-based naming with hierarchical DaveO: No, there's an order Nacho: You can do hierarchical names with attribute-based names Ralph: When you consider names with chunks, do they individually identify chunks or the big thing which is chunked? Marc: The name identifies the security context of the data. Taken as a whole, with name, hash, etc. is like a "named address." Ralph: (missed) Marc: Should have probably been principle 0 of "NDN uses a request/response paradigm for data" Jeff: Part of that was intended to be captured in the data centrality slide Nacho: Discovery has to exist somewhere. This principle is about network-layer discovery, but is that the right place for it? Unclear why it's a principle at this layer DaveO: It's an NDN principle -- should this be promoted to a general ICN principle? Jeff: If the disagreement is about performance we can stop there DaveO: There's also a privacy problem - consumers can explore caches Nacho: In-network discovery forces every node to do it. Otherwise it doesn't work. Jeff: Not sure that's the position or intention. Need to chat with arch folks. DaveO: If you don't do discovery, then the other principle about the network just working is violated. Jeff: The intention is not to solve discovery for all applications -- but that there's a way to ask the network for an incomplete name DaveO: You could also say that "every prefix of a valid name is a valid name," so there is no incomplete name (different from NDN) Jeff: Other mechanisms for discovery rely on services to answer questions (e.g., DNS). For some types of applications, the forwarder provides this discovery service. DaveO: This relies on something above L3 to be reachable. Nacho: Does this mean that any node that comes into the network can discovery any resource they desire? DaveO: First sub-bullet of slide 20 should read "all non-attack interests will..." Ralph: Unless we restrict or specify what's allowed in a query (or incomplete request), then we open the door to possibly many, unrestricted queries. That's possibly a dangerous architecture principle. Nacho: The same functionality can be provided as a service (without forcing it on every node) DaveO: The consequence of this principle is that discovery can always happen. Dirk: shouldn't the principle should just be that interests can have incomplete names? (Instead of in-network discovery) Ravi: Anyone who wants to write an application that wants to do discovery correctly would likely do this at the service layer. This means that the usefulness of the principle is questionable. Jeff: Good question -- it's not clear how much you can really achieve here vs what you can do at higher service layers. Nacho: If it's not a principle, then an application cannot opt out. And anyone can discover traffic (this is bad even if it's encrypted). Jeff: With exact-matching this can still happen (if the suffix can be guessed). It depends on the adversary. Not sure about the security problem with traffic discovery. Nacho: Given that discovery already happens everywhere, why not just make it a service? Jeff: Might be good to ask on the mailing list DaveO: Architectural consequence: you need to violate layers if the discovery service needs to look into a cache or repository. If there's a data structure that is used by two layers, then we have a violation. DaveO: If GB MTUs are allowed, hop-by-hop flow balance is broken. Marc: If response sizes can vary greatly, then flow balance is hard to do well (to allocate receive buffers, e.g.) Nacho: In old CCN, broadcast interests could result in multiple replies and we chose one at random DaveO: Each interest packet should bring back no more than one data packet, but there might be more than one instance of that data packet Marc: Not true if you use incomplete names Jeff: Maybe an articulation issue with the principle. Could replace "link" with "at every hop" (to handle the broadcast problem above) Jeff: This is motivating the idea that "one interest results in one response" Nacho: Maybe the inverse should be said "if you receive one interest then you'll reply with one response." Jeff: The principle of flow-balance in multi-party setting is not realistic. DaveO: We have the sketch of a proof that single congestion control algorithm can’t get both fairness and max network utilization if you do both multi-path and multi-destination delivery DaveO: Nuance: flow-balance is neither a necessary or sufficient condition for doing better whats in slide 24. Hop-by-hop congestion control is necessary. Marc: Right now the amount of data in a data object is controlled by the producer, and an interest has no information about that, so routers can't pre-allocate buffers and whatnot DaveO: "There is in my scheme" (N.B. this is Note Well disclosure of possible IPR) Nacho: Router cannot predict anything at all Marc: Router can't commit bandwidth for a response unless the request conveys this information DaveO: Cisco submitted a patent on a scheme that includes this information (response size) Session 2 -- CCNx Simulator Announcement (Marc Mosko) Working on ns3 module for CCNx Will be released under the same license as C code on Github Users will download ns3, download the module, run a patch, and then be good to go. Session 2 -- CCNx Software Distribution Overview (Nacho Solis) Note: Metis is deprecated in favor Athena (Went through code, compilation, and unit test workflow setup from Github) Session 2 -- TLV Compression (Marc Mosko) https://www.ietf.org/proceedings/interim/2016/04/03/icnrg/slides/slides-interim-2016-icnrg-2-7.pdf Dirk: Have you looked into ROHC Marc: Doesn't exactly fit with ICN-like exchange -- ROHC is very general for what header compressors can do. We wanted ICN-specific compression on the air interface. Dirk: In ROHC you have to specify the compression scheme. Marc: Even if we're running ICN over UDP (as LTE does it) you could use a custom compressor for distinct ports. Session 2 -- Name Resolution (Jungha Hong) https://www.ietf.org/proceedings/interim/2016/04/03/icnrg/slides/slides-interim-2016-icnrg-2-6.pdf Nacho: Do you consider DNS to be an overlay on IP? Jungha: No Nacho: Why is NRS considered to be an overlay? Jungha: Overlay here means above the network layer Borje Ohlman: This appears to be a service Dirk: Overlay implies that there is a network graph that you can embed into the network, but that's not what you describe Jungha: That's right Jungha: Data has the same name wherever it is cached, and so a name can be mapped to different locators (based on where its cached). If you get multiple locators back from the NRS then the object must be cached somewhere in the network. Nacho; Slide 7 is trying to describe a use case, right? Is this that the caches register with the NRS? Jungha: Caches register locators with NRS Nacho: For every object, a cache has to tell the NRS that the cache is located at that location DaveO: Does the word "cache" mean an alternative authoritative place to store data (replica) or any intermediate router that can store data. Jungha: The second one (opportunistic caching) DaveO: If you have a network with many routers, they all have to report to the NRS Jungha: Essentially, yes. Nacho: Would Google be an "NRS"? Marc: Google is much more general than NRS Borje: Caches were controlled in Netinf (missed rest of the comment) Nacho: If objects are packets (small size), then this doesn't scale. Maybe it would work if this was for the whole object. Borje: Netinf registering involved manifests, not chunks of a manifest Jungha: Nacho's question(s) might be out of scope -- this is just about the motivation for the NRS Nacho: Just trying to understand the use case to motivate the NRS properly Jungha: NDN and CCN are not representative of all ICNs -- some ICNs use NRS Nacho: A lot of ICN work uses NDN/CCN. These two might still need functionality like NRS. Unclear about what the motivation of the NRS is (the need for something like a NRS or a specific type of NRS?) Borje: Some kind of name resolution or redirection service would be needed for ICN for publisher mobility (among other reasons), and she is trying to motivate people to work on that problem Ravi: One good use case is in Jeff's slides -- the admittance of flat names Ravi: You can run without a NRS, but some applications might need one. DaveO: Name to name is a good use case. Two things considered here. Is the purpose of the NRS to convert non-topological names in a namespace to topological names in the same namespace? Or is it to convert those to topological names for data that can be located elsewhere? Nacho: Some namespaces are managed (due to topological nature), others are not. Can the NRS map to both? Nacho/Dave: Resolving to names which are not under control can be avoided if the mapping scheme is more well defined. Nacho: (r.e. name to IP address): some people believe that DNS can solve everything. Can't the NRS just be solved by the DNS right now? Marc: DNS query inputs are limited (e.g., bytes per segment) -- authorities are input, not generic URLs Ravi: Might need a more distribtued resolution system to handle mobility Dirk: Using DNS as a protocol vs using DNS as part of the ICN infrastructure -- two important differences. Borje: Thinks DNS could be reused, but the details must still be worked out. That could be one possible outcome of work in this area. Dirk: We want to discuss how we should continue this discussion. Borje: Might be advantageous to write up a draft that discusses the design and implementation issues. Comment: Maybe the document should include the assumptions, motivations, and limitations of using DNS. Session 3 - Privacy Intro (Dirk) have been discussing privacy over past couple meetings, consensus was that we needed to discuss more deeply seeing what is going on in IETF for privacy- more encryption in the network also some issues - privacy vs. optimizing network performance (tls & cdn) in ICN we have a more powerful forwarding layer and ways to correlate requests to responses Private Communication in ICN -- Chris Wood https://www.ietf.org/proceedings/interim/2016/04/03/icnrg/slides/slides-interim-2016-icnrg-2-1.pdf state of privacy in ICN relative to maintaining parity with IP Table of options vs features DaveO- for case of group key - there is correlation within users in the group there is also correlation by users outside the group Jeff - for group key & forward secrecy - this assumes a particular use of group keys and assumes a session-based communication, that may or may not hold DaveO - the term "Session" is overloaded - most general: multiple exchanges use the same key; more specific implies ordering and more constraints DaveO - on private context claim - should also say "...or some necessary application feature." Nacho - why isn't private context the default and applications can opt out? Chris - applications should not be allowed to opt out Nacho - ??! DaveO - dangers of allowing app developers to screw things up is too great DaveO - some examples of "application feature" - by intl law, some money transfers need to be sent in the clear. But this isn't a "desire" it is a requirement. Jeff - private context means what? Chris - we generally mean one consumer and one or more affiliated producer instances Jeff - is the consumer aware of the multiple producers? DaveO - multiple producers would share the same key What does private mean? Stephen - do you include applications like payroll Chris - yes Dirk/Dave - not all applications need authentication Chris- we meant server authentication DaveO -OK Implications Stephen Farrell - what do you mean "DTLS-like"? Chris - use key exchange protocol, over connectionless transport Stephen - but it is not two party Marc - not necessarily, it could be two party for the exchange, but one party could then share the keys with replicas Dave/Chris - we've chosen DTLS-like, but it may not be the only solution that meets the requirements Borje - what is an endpoint? Chris - for an Interest, it is any of the set of hosts that can serve that prefix Outer and Inner Context Jeff -How much information is leaked by the outer context Dave- for parity, should leak no more than is leaked in tls - address and port number Nacho- QUIC hides even retransmissions, Marc - if retransmission re-sends same outer context, then there is leakage, but doesn't have to do it this way Nacho- what is the boundary between DaveO - another approach is to examine obfuscation by information theoretic approaches, these shouldn't be off the table Chris - similar to the paper at ICN last year? Dave- yes Chris - looking at that with Christian(?) paper coming soon O & I Context Implications DaveO - opportunistic caching can still provide temporal reuse (handle retransmission) Chris - unless you take the approach Marc mentioned (retransmission uses new outer envelope) Stephen - on public key usage - but you are still using public keys for the PKI? Chris - right, for the authentication, just not for the encryption Questions to Answer Chris - goal of this was to investigate what "parity" means and understand the implications DaveO - in ICN, can separate authentication from privacy MCTLS can kind of do this, but you'd have to jump through a lot of hoops Stephen - but you get rid of all of the caching benefits of ICN? DaveO - but there is still a lot of ICN goodness - the argument would be that an ICN router would be much cheaper than a CDN proxy DaveO - ICN approach could prevent the custodial transfer present in CDN Stephen - multiparty extension of DTLS needs a lot of examination Approaching Privacy over ICN: Values-in-Design Approach -- Jeff https://www.ietf.org/proceedings/interim/2016/04/03/icnrg/slides/slides-interim-2016-icnrg-2-9.pdf Critical misinterpretations/misconceptions about NDN DaveO - but you do need to assume that data is around forever More accurate.. DaveO - by cleartext, you don't only mean human readable Jeff - yes, any encoding that can be used to derive information about the comms Some proposed reframing Nacho - Is this about TLS or about private communications Jeff - private communication Use case #1 Jeff - Just having a secure connection to the service provider is not the end of the story Nacho - question should be: can ICN provide tools that could provide a better model than is possible in the current network architecture? ie. more than just protecting privacy of the connection to the service What if a core contribution...(use case #2) DaveO - this is an example of misalignment of interests between producer and consumer. there are cases where there is alignment and cases with misalignment Stephen - misalignment might be too strong DaveO - yes. "interests are different" Use case #3 Jeff- can we really make the statement that in these environments we require session-based privacy? Nacho - but you could support caching via an explicit proxy Jeff - so do we need to design a proxy service to enable this? This may not be the simplest solution to achieve the goals DaveO - what do you need to prevent cache pollution - it may be not much less than what you need to do session-based encryption Stephen - can't make the assumption that these users have no privacy concerns, or that their privacy concerns are less important than the bandwidth concern Nacho - another example might be better for this use case - a network in which a single entity controls all of the network and applications and users, they may be more concerned about network performance DaveO - the villagers example could be handled via group keying Use case #4 Stephen - Ubiquity is important for this case- if you want to solve it, you have to use the solution all of the time Opportunities Ravi - need to define what it is to be an ICN service provider. It may be very different than an ISP, and could involve examining requests and providing better services. DaveO- history has shown that people will give up their privacy in exchange for services, without really knowing what they've given up Marc - just because the communication between two peers is private doesn't mean that the peers have to be consumer and publisher, could be between consumer and ICN service provider. Service provider could provide caching service, etc. Onus is on application to understand/decide which sessions require privacy end-to-end vs ones for which the MIM can be trusted. Jeff - so the KE approach is just focused on providing a secure connection, not necessarily to the producer? Marc - yes Meaningful privacy protection in ICN -- Stephen Farrell https://www.ietf.org/proceedings/interim/2016/04/03/icnrg/slides/slides-interim-2016-icnrg-2-8.pdf Stephen - With untrusted caches, it doesn't appear that there is a solution with existing crypto (possibly homomorphic ciphers) DaveO- ICN doesn't have the same "hard edges" in privacy support that exist in the IP world. May not need to throw away the nuance that exists in ICN in the name of providing "parity" to IP. Nacho - where we usually end up in discussions is that the more privacy you want, the less you get out of caching Marc - with KE protocol, we wanted to try to solve the most common - easy use cases Stephen -did you look at Kerberos rather than DTLS? Marc/Chris - “No -- we focused on DTLS for the key exchange but used Kerberos for the MoveToken CCNx-KE vs (D)TLS -- Chris https://www.ietf.org/proceedings/interim/2016/04/03/icnrg/slides/slides-interim-2016-icnrg-2-3.pdf Chris gave an overview following the slide deck. No questions Move token - Chris Dirk - move token is another example of a host-based communication Session 4 -- draft-forwarding-label-ccn-02.txt (Ravi) https://www.ietf.org/proceedings/interim/2016/04/03/icnrg/slides/slides-interim-2016-icnrg-2-11.pdf Borje: Have you updated the slides? Ravi: No Nacho: First sub-bullet on slide "FL for manifests" -- what do you mean? Ravi: If you separate the locator from the name, then there is no ambiguity problem. A name is always a name. Nacho: Would a rename in the field be less confusing? What if ContentObjecthashId == ImplicitName? What if the Name was called the ForwardingName? (Without changing the functionality.) Nacho: We have no application names in CCN Ravi: That's not true. Manifests are created with application names. Nacho: Applications can't choose random names Ravi: It cannot but there might be semantics about how it's used. Applications decide what goes into a name (beyond locator). Nacho: Feels like this is adding more complexity into the interpretation of the name. Nacho: If I understand, you want to replace the Name with the Forwarding Label? Ravi: No, use the name as the forwarding label and keep the ContentId as it is today. Session 4 -- draft-ravi-ccn-notification-00.txt (Ravi) https://www.ietf.org/proceedings/interim/2016/04/03/icnrg/slides/slides-interim-2016-icnrg-2-10.pdf DaveO: Semantically, what is "all intended receivers"? Ravi: Parties that can get the data DaveO: How to identify without flooding? Ravi: Many ways, e.g., multicast ID DaveO: Multicast as a notification mechanism? Ravi: Assumes there are receivers subscribed (i.e., subscription is required). DaveO: Wasn't clear. DaveO: Does "forwarding support" imply that the communication pattern wanted to be used is embedded in the name Ravi: Yes DaveO: Something with the same name can't determine what type of communication (unicast vs multicast) to use. Seems to be similar to IP where portions of the namespace are reserved for different comm. paradigms. Is that considered to be a good idea in the IP world? Is this a good idea in ICN world? DaveO: This partition is generally considered to be a bad idea. So why adopt it here? Ravi: Two things: (1) are you saying that multicast is bad? DaveO: No -- I'm just saying that embedding the communication type in the name is considered to be a bad idea (from IP). Ravi: So we shouldn't have names that identify the type of communication? DaveO: Yes, that's right. Nacho: IP multicast relies on some partition as the namespace Ravi: Not sure how to make this distinction in a forwarder without putting it in the name Dirk: Why don't you just specify a complete pub-sub system? Ravi: Pub-sub is only one system you can build on this scheme. This is a new third primitive in the network layer.