MinutesICNRG Interim meeting @ IETF 94, Yokohama, Japan, November 1, 2015
Agenda
- 09:00 Welcome, Agenda Bashing, Minutes taker, Bluesheets, Status [Chairs] -- 10 min
- 09:10 Discussion and decision on topics for group discussions, splitting into groups -- 20 min
- 09:30-11:00 Group discussions (including refreshment break) -- 90 min
- 11:00-12:30 Reports on group discussions and discussion -- 90 min
- 12:30-14:00 Lunch -- 90 min
- 14:00-15:30 Group discussions (including refreshment break) -- 90 min
- 15:30-17:00 Reports on group discussions and discussion -- 90 min
Proposed topics
- Naming (ID/locator separation, publisher mobility, link object, routing hints, nameless objects, etc.) If possible we should try to break this down into sub-topics.
- Privacy -- 10
- Net neutrality together with privacy.
- Reference implementation - 2
- Accounting, logging at content providers/CDNs and business models for ICN -- 5
Alex's Talk
- Nacho: how is that different to IP?
- Lixia: in IP, we specify attachment points, anycast and multicast are exceptions
- Nacho: can do same thing in IP
- Ralph: sometimes ICN names can be both (name and locator), you are sometimes using name as an indication to topological location
- Dave: in ICN: if you emit a name, there may be some information that helps the routing system to get a destination -- still this does not make it a locator
- Lixia: in IP, people started use IP addresses for other things than attachment points, changing semantics
- Lixia: in NDN, a name can represent anything -- endpoint, data chunk somewhere, a command etc.
- Ralph: if forwarding system can infer something about direction, that the identifier is a locator
- Lixia: only in IP. In ICN, we have state on forwarding plane, so it can be smart enough to decide differently. Forwarding strategy can take input from RIB, interface status, policy etc.. But yes, forwarding needs to know where to forward to
- Ravi: management of namespaces? Applications should be free to use any kind of names. Service providers should have different options
- Lixia: yes, need flexibility, but must not dictate engineering solutions
- Lixia: namespace is most important part of ICN research
- Ravi: but what: namespace of apps or of network infrastructure?
- Lixia: do not separate into two
- Ravi: disagree
- Nacho: what do we call the property that a name has once it's advertised by routing?
- Lixia: steering interest to go into a direction where NDO can be found
- Nacho: so, is it a locator or what?
- Lixia: it's just a name
- GQ: once you attach a name to the network, you assign some locator meaning
- Dave: two things being confounded:
- question of whether you are entitled to announce named data to the network (security question)
- distributing routing information to enable the network to get to an NDO
- Lixia: ownership of name
- Lixia: name propagation
- Lixia: LINK: addresses scalability -- for ICN NDO on a finer granularity
- Olov: whatat is an object, what is a name? (immutable object)
- Lixia: different links do not means that the objects become mutable
- Olav.: can objects have several names? Can names be published at several places?
- Lixia: yes to all
- Marc: as to what is a locator. name that is being routed on is the location you want to go to
- Lixia: comast as a link attached to an interest, can be a hint for where to find the content
- Marc: signed links != secure routing
- Lixia: in a future ICN routing system, routing updates will be ICN objects
- Marc: from having updates signed, you cannot assume the system will be secure
- Nacho: what is it that a "comcast" name makes it have location semantics?
- LINK object seems to be an engineering solution for scalability
- Dave: globally routable seems to be an adjective for a name. It's actually a property of the system to reach that name
- Lixia: "lixia.com" is not reachable is only a snapshot -- it make become globally reachable tomorrow
- Ralph: "comcast.com/index.html" identifies the object and helps me to find the object
- Börje: propsing term "routing hint"
- Marc: it depends on the intended use of the name
- Lixia: architecture vs engineering -- important to distinguish
- N2: real-life analogy. two levels of routing
- Lixia: how to build the system, efficiently and effective, is an open question
- Alex: difference between routing and forwarding.
- Nacho: next 5 year plan
- tying together applciation semantics, routing, security creates theses issues
- leads to manifests, link objects etc.
- Lixia: there are environments where you have to use names in that way (combine everything)
- Lixia: that's ICN advantage -- that you can use names this way
- Lixia: in global routing system, engineering solutions are required, but architecture should not remove this fundamental capability
- Lixia: need critical examination of current architecture and deficiencies
- Nacho: agreed that there are apps that benefit from tying theses 3 things together. Tying together may be useful for one purpose, but not in general
- Ravi: names carry semantics -- good for local communication. But infrastructure needs to be able to deal with that too
- Lixia: question: can you do a general arch that supports these different environments
Group works:
Group 1: (Notes: Dave Oran)
- Ionnis: Meeting point between architecture and engineering
- Tohru-san: just about naming. Surveillance is very important - communication secrecy is also very important. Routers have a lot of information that has privacy implications - if government insists, very difficult for providers to resist. Safer to just use the routing part of name.
- Ravi: independence of names and routing requirments - some IoT systems use self-certifying names.
- Nacho: should list what we are using names for
- ?: in thinking of data management, each router needs name - how to use names to organize and run the system itself.
- Tohru: in Japan lots of discussion of SDN for traffic engineering - DPI is prohibited for privacy reasons. - Some advantage of IP is that ou nly have IP address and port, not other information
- Acee: ICN has advantage that it does not have informaiton about the source. Can we get a refeence model for names - how consumer gets data from publisher
- DaveO: Start with three aspcts of names from Alex's slides - for application structuring data, for forwarding to the data, for making security & trust assertions that.
- Ravi: management of names is owned by the network.
- Lixia: clasirifaciton some names managed by operator. Ownership versus forwarding.
- Ravi: for purposes of making the network work, the application should not be forced to choose particular names.
- Lixia: whether namespace is centrally or distribured managed is separate from names themselves.
- Nacho: Ownership depends of what organization has authority for ownership.
- DaveO: making a separation between applications names and network management names seems to be a bad idea.
- Ravi: for some names do Name-based routing, for other do "locator based routing".
- DaveO: some architctural issues about whether the system allows applciations to discover things that allow them to choose forwarding-friendly names
- Lixia: wants architecture to define the minimal - make everything else engineering
- RavI but there are engineering limitations
- Lixia: as long as we have an engineering answer we're ok.
- DaveO: What about protocol architecture?
- DaveO: thinks the ability to learn name properties from the forwarders that can help applications choose forwarding-friendly names. Thinks this is architectural.
- Acee: need model of what things are done where
- Nacho: more uses of names:
- applications can use names to - identify something (separate from issue of mutability)
- appplications can use names to define structure (or context).
- Some things are structural but not application-specific (e.g. chunking)
- We use names for Routing (Lixia disagrees)...this is controversial - Routing protocols will use names and prefixes of names to tell other nodes about where to find those names.
- DaveO: restate: routing information is expressed in terms of names and name prefixes.
- RavI: ITU already has document defining difference between identifiers and names.
- Tohru: Has Jesus - but multiple sects - Protestant & Catholic. Huge discrepancy among groups. Example: mobile networks have to put service and management along the lines of how fixed line networks were done. How can you hiude one provider's information from leaking into another provider.
- Lixia:great example - in IP not enough semantcis to deal with this - having names allows this kind of expressiveness.
- Tohru: need some kind of "god" otherwise lots of vulnerabilities. Naming conventions need to think about all the kinds of malicious activities.
- Security
- Dave: Disentangle Privacy, Integrity, Confidentiality.
- Dave: Traffic analysis will reduce privacy. How far do you go in your protocol architecture in protecting privacy if an attacker will be able to learn a lot via simple analysis?
- Not everybody shares the concern that IP parity is essential
- We should have some way to provide that feature if needed
- Ravi: how would we provide network services if we have full privacy.
- You end up trusting Google or your government one way or another
- Kostas: Do you have to trust anybody to do networking?
- Tohru: There is a need for click-tracking
Group 2 (Notes: Dirk Kutscher)
- architecture should be engineerable
- privacy: correlating requests to what users actually get to see
- traceability
- network should be able correlate at some point
- requester anonymity
- better design space for providing adequate privacy
- "communication between endpoints" in ICN and accessing "named data"
- name "rewriting" concept, "routing hints"
- engineering solution
- producer hint: list of from where you can retrieve that data
- like Bittorrent tracker list
- link object
- how to gurantee reachability of producers in ICN
- different from IP?
- stateful forwarding
- naming scheme: DOI
- digital identifier for all objects
- database
- indirection concepts -- could still apply in ICN
- multiple naming layers -- would that be helpful
- nameless objects
- e.g., topology-relevant names
- application-relevant names
- manifests: hash-based names for chunks
- could be seen as a good middleground
- is that something that just applications use?
named could really represent devices, physical objects -- it's application-specific
multiple publishers publishers under same prefix
publishers moving around
state explosion
how to move forward
- good requirements/assumptions on we use networks in different environments, larger networks
- document current assumptions
- more experiments with actual applications
- list key issues
- where does the binding of three naming aspects does not work
-
larger testbeds
deployment in limited contexts (IoT) currently more promising than large-scale, core-network type deployments
fresh data vs immutable vs. version numbers
Routing/forwading hints
- seems to impy another naming layer
- does not have to be part of the architecture
- more like a engineering solution
- analogy of DNS in IP: lookup in first router
- routing links & security. should be authorized by publisher etc.
concerns
Group 3: (Notes Börje Ohlman)
Just saying a name is immutable does not make it immutable. There must be some cryptographic means to guarantee it. One way to do that is obviously to use the hash of the name. How about if you need to change the hash scheme? You could use ni names.
What about dynamic data? For live video you can do some type of forward chaining.
About the x thing. X is what you give to the network to help it route to a location that might have the data object that you are requesting. X can be a set of x's, e.g. a bluetooth mac address, an ip-adress or another name to be resolved by some indirection service.
In the original CCN/NDN id and locator was the same. In current versions
In CCN now they use named adress concept that can contain name, hash restriction and xxx, this is the identifier that needs to match to give you the object.
Every device that attach to the network need to have a name that serves as a locator. When publishing a data object it needs to be "attached" to the network.
Is there a NRS in CCN? There need to be a way to identify the signing key. A possibility is to have a key a resolution system that you trust. There definitely need to be a way to distribute trust anchors. You can submit a name to authorative source which can give you the x for the set of the replica servers, e.g. a set of signed links. Another way is to use a search service. Then when you use an untrusted such service there needs to be a chain of trust established.
If you gonna do signed updates to the routing tables when things are moving it is going to be challaging. For privacy you want an encrypted name with a routing hint in the clear. Does a routing hint have to be signed? If so is that a privacy problem? Assuming self-certifying objects the requestor should not have to sign the routing hint as he can verify the object coming back. There might be other reasons why they need to be signed, e.g. to prevent denial of service attacks.
The name will include a part that is not globally routable.
Identfier name: Used for matching content, could/should be encrypted
Locator name: Used as input to the routing system to find replicas of the content object
Locator part cannot be encrypted.
Rewriting names is complicated and a heavy operation adding a forwarding label is more lightweigt.
Is x a suggestion to the network or a requirement. We probably need both a routing hint and a routing pin
Afternoon discussion:
----------------------------
Privacy Group (notes Mark Mosco)
------------------
Privacy vs Net Neutrality
- both have to do with what is exposed and what the network can do
What is net neutrality?
- Differentiate between classes of traffic is ok
- Differentiate by providers or consumers is not ok
- “Treat equally” vs not differentiate. You can differentiate as well as all within that class get equivalent service.
How does net neutrality apply to ICN?
- If you have enough of the name exposed, then carriers can differentiate
AS anycast…
- ISP encrypts part of the name after its AS route, so its private to the outside world.
Caching encrypted content
- Broadcast encrypted ok
- session encryption not beneficial except for transmission errors
- Identity based encryption means request names could match and caching might be useful
- does leak correlation information
- You can correlate access to same server with IP, but maybe that’s less of a strong correlation?
Access Control
- related to publisher and consumer, not intermediate nodes?
Encryption and Privacy
- Inner-name vs outer-name. Inner is private between publisher and consumer. Outer has to have certain degree of exposure.
- “outer stuff” has some name and some metadata, flow type.
- Flow type should be standardized. Maps to a class of service.
- ICN every endpoint has its own cryptographic identity.
- That means intermediate systems would need the public keys
- and has to operate fast enough with public key operations
- Want to be able to tell network not to cache (e.g. on-line banking)
- For symmetric key negotiations, want to be able to pin to end node
How to differentiate flows without revealing identities?
- If someone really wants something and is willing to pay for it, what stops others from piggybacking on that via interest aggregation?
- Today, the producer sets the priority not the consumer.
- One option: producer assigns priority to a name and everyone who asks for that name gets that priority.
- If content owner isn’t paying the ISP, maybe the ISP doesn’t honor it.
- Different rate would use different names and fall under different priorities.
- Different names for different encodings
Ban the use of “priority”! It’s envy and jealousy.
In ICN, you don’t know where its coming from
- Caches and different routes.
- HTTP-based delivery has same problem. DASH can go in to complete congestion collapse.
Need definitions;
- communication secrecy
- Security exists only during the communications process.
- Session security.
- privacy is much more
- privacy of users.
- Exists before and after the communications.
- belongs to the information processing business.
- ICN might be better because
- no source address
- no destination location if name is not topological
- Break the end-to-end association because caching by the edge
Federated trust model
- subscriber to publisher
- subscriber and its local carrier
- publisher and its local carrier
- Is there a way to close the loop?
- Multi-access link and not knowing how many people are accessing it (in DOCSIS)
How the world has changed
- Now have TPMs
- A service provider could not rely on end user device keeping secure and accurate accounting information.
- Nowadays, end user devices could gather billing information securely with signed code that cannot lie.
- Pay per view rotated every 1.5 seconds (keys embedded in the stream)
- Other paid content less than a day, more than an hour
How to support an advertising model?
- Payment is based on how many people are viewing it.
- Distributed caches makes this very difficult.
- Maybe this is difficult to rely on the user device (is this different case than the TPM?)
- Cache operator and producer may need relationship for billing.
- CDNI group - would it have been easier with an ICN model?
Reference Implementation Group
----------------------------------------
Starting Point
- ICNRG in a not so bad position wrt to running code
- multiple implementations available (PARC ccnx, ccn-lite, NDN)
- PARC ccnx and ccn-lite implement the ICNRG ccnx specs and are interoperable
Problem Statemet
- No code base today is ccnx-spec-compatible, feature-complete, open source *and* open for contributions from a broader ICNRG community
- We believe that an open source "reference" implementation that could be used by everyone and that can accept improvements/changes from a larger community would be good for ICNRG
Reference Implementation Benefits
- Validation of the Spec: spec quality
- Platform for trying new ideas quickly: development agility
- Implementation that reflects the current spec and that can be tested against: interoperability
- Implementation that can be taken as a basis for more complete systems, applications, future products; sharing efforts for commodity platform
IPR and Licensing
- Open Source reference implementation would be affected by IPR as other implementations
- Licensing model should enable a broad range of contributors, including companies that may have IPR in the field
- Licensing model should enable users to adopt the software for commercial products
- Permissive license needed
- BSD license would provide that: https://en.wikipedia.org/wiki/BSD_licenses
Reference Implementation Candidates
- ccn-lite:light-weight, C-based, BSD license: Authors expressed interest to work with other interested parties
- PARC ccnx: wrong license -- not free for companies
- NDN: GPLv3 license, not compatible with spec at this point
Discussion
- Is reference implementation the right thing for an RG?
- A: other RGs have successfully worked with software that was used as reference implementation, e.g., (DTNRG)
- Future of ICN IPR unclear -- time will tell
Conclusion
- Try to move forward with reference implementation
- ccn-lite as a proposed base
- looking for interested developers, maintainers etc.