Re: im2000 protocol base

Rickard Armiento <[email protected]>:

> You describe a very generic infrastructure for information transport
> and trust-handling between paticipating entities. Perhaps I have not
> completely grasped your underlying ideas, but my picture of the
> protocol you describe can be summarized as three simple points:
>   i) Information is transported between multiple connected nodes.
>   ii) All nodes are free to do anything with the information they
>      receive, but the idea is that they have some advertized role
>      (eg., "recoding") which eventually results in communication
>      with other nodes.
>   iii) A node who has sent information to a connected node
>      may investigate what actions the receiving node has taken on
>      that information. If the sender node is not satisfied, it may
>      terminate the connection to the other node.

actually, i'd like this to be more liberal.  it can also be one of
the receiving nodes that initiate or rather notify "rejection" or
"failure".  i just want to be very clear on this:  only nodes that
are specifically invoked by other nodes, thus learning the particular
path-ID/message-ID of a work packet, can ask their immediate
predeccessors or the intended recipient about a message.  this will
be part of the "builtin" encryption, see "chaffing and winnowing", and
part of the path-ID (the sequence number) could be used by connection
less protocols like UDP for housekeeping.

for chaffing and winnowing see
<URL:http://theory.lcs.mit.edu/~rivest/chaffing.txt>.  this is not
really encryption, but it will legally work even in countries were
encryption is outlawed.

> Given the level on which you have specified this protocol, I
> categorize all details about information content (eg. "headers",
> "path-id:s") and specifics about key handling/agents, as being part
> of the "implementation dependent" stuff you say are left for later
> specification.

i meant it the other way around:  this generic protocol shall be the
core of im2000 which every participant MUST implement, especially
headers and path-IDs.  more on this below.

> My only objection to the protocol itself is: doesn't this protocol
> only describe how to loose trust? how do you gain trust? In
> specific: how is a new node accepted into the network?

it advertises some service, just by mentioning it on DNS.  other
nodes or users can simply try it:  for this they have to instruct
their MTAs via their MUAs that they should get the public key of this
new service and sign it.  should communication with these new
services not be advantagous to users, they will eventually revoke
this signature.  thus the service looses "trust-value" and might
eventually go out of business.  note that a users signature for a
service can be viewed as a monetary value:  many signatures from
happy users draw business.  this is what i meant with "if you trust
me, you get a hug":  you give me value (trust) and get value in
return (some service).  the ideal behind this is at the same time
idealistic and cooperative, but also pragmatic and capitalistic.

>> what do you think, will my connected nodes be able to fulfill
>> [user] expectations?
>
> With a protocol specification this general, I'm sure it is
> *possible* to use it as a base for implementing im2000. However, I
> believe it is absolutely vital to look more at specific
> implementation issues before deciding if it is the best way; one may
> find another trust model to come more natural.

i think im2000 will be like SIP/SDP (see RFCs 3261 and 3264) plus a
trust-model which combines cooperation with value-addition.  when
andrew introduced me to SIP, i thought this was only for VoiceIP, but
it turns out VoiceIP has solved all im2000 protocol problems, and
even dipped into trust problems.  it's only missing more specific
voting and the explicit use of signatures and encryption everywhere.

>> reality will soon evoke hacked or malicious nodes that, for
>> example, keep sending failure notifications to degrade nodes under
>> attack and thereby mobbig or ousting them out of the 'net.  any
>> ideas on this?
>
> Still on a very general level: a node which can prove that another
> node is "hostile" (as per it's own definition) sends out this proof
> to other nodes. Nodes that agrees that this indeed proves "hostile"
> behavior will disconnect both the hostile node, and other nodes that
> refuse to act on the proof (and thus also being classified as
> hostile). The end result is a "network split" that separates the two
> kinds of nodes. Usually this should only mean that a smaller number
> of attacking nodes are disconnected (but other scenarios are of
> course possible). Allowing for a large-scale split of the network
> could seem drastic, but with only the very generic definition of
> information transfer above, it is needed to ensure compability
> between the nodes.

this description is nice!  i think in real world applications, where
you would have to deal with hostility in many different forms,
ranging from micro$ofts domination with inferior quality to hackers
and script kiddies, revokation of trust will turn out to be a voting
mechanism that should take care of the aggregation of cooperative
nodes.

> However, I belive a larger part of the trust problem is hiding
> inside the question above on how to accept new nodes; How do you
> avoid to re-accept a "hostile" node into the network again and
> again? In the context of spam, this is exactly the issue of: how do
> you prevent a blocked spammer from just creating a new identity? I
> don't think I have anything new to contribute to that discussion
> that has not already been discussed on this list; but it may mean
> that one can not trust new users more than ill-behaving old ones
> (which clearly is a problem with usual email black-lists).

good point.  so what happens if a spammer creates a new identity and
fools 10 of 10.000 people into downloading his "product info"?  (i)
the requesting users (or call them nodes) will have to sign his key
to make their MTA even talk to him, and these signatures will be
revoked rapidly as soon as the user is disappointed and presses the
"rejection" button.

this is why i want im2000 key servers to be special:  identities can
be created rapidly, but users can see how many good signatures and
how many revoked signatures they carry.  so they may specify rules
like:  "don't use services with only one signature, and don't use
sevices with more revokes then good sigs."

as to the algorithms and datastructures, i can be more specific:

- there will be im2000 headers and user headers.  user headers
  contain Subject: lines and point to URLs, but this is not part of
  the im2000 core.
- im2000 headers specify services and releases.  services are
  unresolved issues, whereas releases are the im2000 ingredient of
  notifications.
- a release is issued by nodes to tell participants that its backend
  successfully performed some operation that other nodes should know
  about.  every release has to result in a new path to the intended
  receiver to see if this particular result is already acceptable to
  him.
- backends may have to rely on other services, so they may add new
  headers (new requests) to the current message stream.  this is
  basically the mechanism used by end-users to subscribe to something.
  they will of course delete headers once they've done their work.

so what does an im2000 node do with a new message coming in?

- it checks the signatures of every header and tries to verify them as
  far as possible within some time limit or according to preferences.
  if the message already contains releases, it may choose to postpone
  working its backend on it pending acceptance by the intended
  receiver or cash expiry (which could be seen as successful
  completion of the communication).
- if the message has open headers, it will look for a match for its
  own backend.  the backend will have to inspect these headers
  immediately and return the ones it doesn't recognize.
- the "welcome" stage of the node should act on operators in the
  headers.  this will be a cheap mechanism to implement preferences as
  we can require every im2000 node to at least implement `!'
  (not), `>' (preceding) and `>' (successing) operators.  "not" means:
  "don't invoke this particular type of service".  headers with this
  operators MUST be copied over to the next node.  "preceding" means
  (depending on the type of data it's used on): "no earlier than" or
  "not less (quality) than" with "successing" beeing the logical
  opposite.  i can also imagine a combinatorial operator `?'
  ("perhaps") for situations where either nodes could elect to
  perform some expensive operation or maybe try to find out if a
  particular service is available at a later stage.
- unrecognized headers will have to be sent along, generating a new
  path-ID.  depending on the connectivity of the node, it may again
  postpone this action or even start new messages to several other
  nodes in parallel.  for the latter keys will have to be looked up
  and messages prepared, signed by its own key.
- eventually the backend returns a work packet.  headers for this
  backend will now turn into releases (closed headers).
- the result will have to be cached, and the cache decides for how
  long, depending on size and network conditions.  the work packets
  also gets its URI from the cache.
- now's the time for the release of that work packet.  a release will
  always consist of the path-ID, the IP of the preceding node and its
  own, a timestamp and a version.  versions are neccessary in case
  competing services issued several releases on the same original
  path-ID using their big pipes or other available resources.  _but_!
  whatever is released will have to be accepted in the end by the
  receiver.  depending on which of several encodings, recodings or
  whatever gets accepted, it may happen that the work was done in
  vain.  also, rejections could happen not only because of contra-
  productive or uncooperative behaviour (signature revokations!), but
  also simply because of preference issues.  since preferences can
  change dynamically (think well connected desktop versus handy) or
  even be unknown in a publish/subscribe system, the cache better be
  prepared to take note of the parts of the network it aquired
  knowledge of.
- once a release is prepared it's high time to make some kind of
  history entry.  we have the choice of documenting the history of a
  message in the headers of the various versions that may exist at a
  time, but we might also choose to at least propose a "history"
  service that keeps records on what happened to a message.  we need
  something like this in order to prove the consitency of the system.
  in a more practical sense, this may be needed to deface eg.
  spammers.

note that nodes only learn about communication failures when the end
user initiates a backtrace, eg. in case he revokes the signature on a
particular service which declines taking responsibility because it
can prove that the predeccessor changed the state of the message to
something it couldn't understand.  or it just forwarded the message
as a router or stored it as an insurer, which doesn't change message
contents.

unresolved headers causing lookup of the responsible services must be
forwarded with new path-IDs!  otherwise later actions might inquire
about the state of a message that isn't valid anymore, and it may
happen that old path-IDs aren't cached anymore.  we must insure that
at least the part of the network involved in a particular message
cannot go into an invalid state, which will also help the overall
robustness of the system.

i'm not sure yet how to treat the trust serving parties.  can't they
simply be voted on by the criteria of their contribution to overall
performance?  or do they need to be guarded against abusers?  given
the system i tried to depict above:  is voting by trust (using
signatures and their revokation) enough to have a stable, responsive
system?

as to "start new messages to several other nodes in parallel" i expect
opposition:  you may argue that bandwith can quickly grow
exponentially if we let nodes fire up a dozen unresolved headers at
the same time, and i say that bandwith will become less of in issue
in the future.  also, if we get im2000 features for maybe 1/3 total
bandwith overhead, we'll be fine  :)  also, see
<URL:http://netlab.caltech.edu/FAST/>.

  clemens

-----BEGIN PGP SIGNATURE-----

iD8DBQE+hvUepdlrZyFBkK8RAvWmAJ9bt5xTjUIGocDrvGVc7lv5Ad7nawCdFaja
0kvPvPVkFtO2pYfkLT9ttC0=
=Xx+s
-----END PGP SIGNATURE-----