ICNRG, Wed, 20 March 2024

• Session Recording

1. ICNRG Chairs’ Presentation: Status, Updates Chairs 05 min

• Presentation Material

Today's meeting will focus on transactions

Four RFCs published since the last meeting. Thanks to the authors.

Active RG draft

To be completed soon.

• FLIC: File-like ICN collections

Related drafts

Related drafts. Brief presentation of what these are about.

Reflexive forwarding for modeling client-server interactions in which
sizeable parameters need to be passed. RG draft - update coming soon

Flow balance for congestion control addresses the issue that you cannot
simply count Interest packets to estimate how much data is coming back
in Data packets as the latter have a very large dynamic range (few-64K
bytes). (individual draft)

Microservices: currently being discussed how to best handle this. The
specification should go beyond a general architecture doc and look more
into a concrete specification. (individual draft)

2. ICN and Distributed Computing

Brief introduction by the chair. Overview of evolving shared state. (see
slides for details)

Transactions (with ACID properties) are easier to achieve in traditional
client-server systems.

Different ways to realize transactions: ICN as a network layer vs.
shared data structures.

Today, two ways discussed.

2a. Secure Web Objects and Transactions Dirk Kutscher 20 min

• Presentation material

Dirk Kutscher presents.

Original web design vs. today's (commercial) reality.

Data-oriented Web

Which ICN components do we need? Discussing real-time media (cf.
ROBUST), FLIC, and others.

Transactions (ref to reflexive forwarding and to "RESTful
Information-Centric Networking").

Shows how to do transactions with Reflexive Forwarding

Dave: lots of experience on distributed systems has it that transactions
or secure multi-interactions will generally require more than a single
two-way exchange.

Dirk: discussed a bit a NDNcom two weeks. [...]

Lixia: ICN and NDN has authentication carried out when the signed
interest arrives which directly proves authentication.

Dave: I disagree with this. Consider authorization. In chat Dave
commented that forcing a server to do signature verification on initial
request arrival ha been shown in prior systems (e.g. TCP+TLS) to
represent a seroous computational DOS attack risk.

Lixia: authorization is past authentication. So you can in fact do
authentication ahead of time and not in the authorization pahse.

Dirk: Here, the assumption is that you cannot fully rely on
pre-authentication, but you talk to your server and but the server
doesn't need to know ahead of time who you are; insgead you do
authenticatio and authorization as part of an initial exchange.
Application-layer semantics may require an additional step.

Mark: whenever a protocol does authentication. you need to analyze in
the context of specific examples to discuss, cannot only look at an
abstract level.

Lixia: tomorrow presentation at the DINRG meeting on NDN for distributed
"workspaces".

Wrapup: how to realize transactions in information-centric systems?

Next presentation will look at transactions with shared data strutures.

3. Transaction Manifests Marc Mosko 20 min

• Presentation material

Marc Mosko presenting.

Initial ideas of transaction manifests.
How would DLT-style distributed transaction map to ICNs?
We discuss a data object, the Transaction Manifest, as a concept.
FLIC: how to encode a single object.
TM: input state -> output state
only the input is relevant (and thus part of the transaction)
TMs need a set of bookkeepers
Bookkeeper job
TMs and Repos and Caches
Difference between Repo and Cache concerning TMs
Naming TMs
Distributed TMs

Dave: with multi-bookkeeper systems, you will have to deal with
livelocks and deadlocks. Often, total order is used for resolution. Can
we do this without total order?
Mark: transaction that goes in names the rows something is
preconditioned on. So, maybe? Unclear at this point. Needs to be looked
at.
Dave: multiple uncoordinated databases, maybe, not following this field.

Mark: TM doesn't require a read-ahead lock; TMs are lockless, things can
fail, there is potentially unfairness between nodes that have different
access latencies
Dave: Yes, this can cause Livelock starvation of some requesters. You
may be able to work without a total order if you have some menas to
provide fairness
Mark: not necessarily a desriable property; for a
bookkeeper-to-bookkeeper protocol, you may not want to address the
fairness issue the same way.

Next steps: sketch out protocols, analyze, prototype

4. Vanadium (V23) Discussion: Secure, Distributed Applications Mark 20 min

• Presentation material

Vanadium does distributed access control as presented at the NDNcom
meeting. Thought this would be interesting to introduce here.

What it is? secure, distributed RPC system
Why? Seems interesting for ICN
Quick intro to Vanadium, then discuss
Vanadium has two parts

1. Security: Principals and Blessings and Caveats
2. Object naming: RPC mount tables
   How ICN-ish is Vanadium?
   Exmaples from: vanadium.github.io/concepts/security.html
   Root of trust
   (revocation rather than short-lived authorization)
   Object naming
   Entity resolution: Mount tables work a bit like DNS; yields a
   recursive walk through mount tables for name resolution
   More on names
   Summary: permissioned RPC service
   What does it mean for ICN?
   • interesting security pieces: blessing and caveats
   • vanadium identity service
   • RPC piece needs a bit of finessing

Dave: would be interesting to do an apples-to-apples comparison to the
NDN trust schema; Vanadium's approach with the ability to create
blessings and caveats on demand seems to be much more granular and
dynamic.
Mark: I suspect you could. SDSI co-signing objects in CCN. but this
never got anywhere.
Dave: mentioned Dan Boneh's work on aggregate signatures. Does this
apply here?
Mark: Signature wrapping more than concurrent signatures.
Mark: Sync base application and a chat application on top. Interesting
to see how to map those to ICN. Interesting to see features to be usable
as takeaway

5. Global vs. Scopes Namespaces Marc Mosko 20 min

Mark: No slides prepared for this.
Mark: How do you know that the key you are looking at is the key that
you should be looking at. IPFS totally punts that, pushing to
out-of-band.
Mark: there is a little bit of trust in IPFS bt not much
CCNX: uses public keys scoped names; you can put a public key, publisher
ID, in an interest and say you only wanyt this name if signed with the
associated key.
Dave: autoconfiguring security is an oxymoron. You will need some trust
root established via a leap-of-faith outside the system to start of
with.
Dave: scoped vs non-scoped namespaces. something we did in the past may
be wortwhile looking at again. RPC system for the OSF distributed
computing environment. All namespaces were scoped nd start out as local.
Then you could "attach" a local namespace to a more global namespace via
an explicit graft operation. The key here was that the authoritative
pointers repreenting the namespace graph were from child to parent, as
opposed to parent to child as it is with systems like DNS.
Your local trust root identifier could become a name in a higher layer
space, yielding a trust root higher in the hierarchy tha could be used
instead of or in addition to your local trust root.
Doing this can create progressively more global name spaces out of local
ones
Mark: what their mount tables allow, is doing a relative naming scheme
Dave: in relative naming systems it's often not feasible to compare two
names and ascertain whether these are the the same thing; may be
computationally infeasible or require any comparion to knowa priori
where in the relative namespace each one came from (which then forces
you to have distinguished roots anyway)
Mark + Dave: That's the way that we structured flick manifests. You can
always write a new Root manifest that points to a previous manifest. And
you can give that root a new name. The operation of asking "are these
two things the same" is very simple it's still hierarchical and you're
growing from the top down. The assertion that some sub manifest as part
of this larger manifest is an assertion by the larger manifest. So the
the the in the interesting inversion here that may be worth looking at
through all these years. Is growing things from the bottom up with the
authoritative pointers being the child to parent pointers. Uh-huh.
Right. Right. So orphans have enough state to computationally find their
parent if the system gets disconnected.

6. Buffer, Wrap Up and Next Steps Chairs 05 min

ICNP soliciting ICN submissions
Future ICNRG meetings:

• possibly an interim around June after ICNP DL
• meet in Vancouver vs. chill and see :-)