Re: RINA and capabilities

I agree with the general premise here, that networking is IPC. But I don't
see much value in the hierarchical organization of the network layer. RINA
seems to be using this hierarchy, and authentication, as the basis for
authority.

To the extent there is value in semi-hierarchical structure, I'd prefer to
model it using capabilities within the application directly - e.g. in terms
of publishing service caps to brokers at varying levels of public vs.
private.

I've been leaning more towards Chord or other DHTs as the basis for getting
involved with a network and bootstrapping the routing process. Every
vat/process can have a little bit of router. And we could have a hierarchy
of Chord 'rings' and indirect connectivity (connect to me through one of
these other processes) in order to model physical constraints. A process
would have a public key or a secure hash thereof as a unique identity on a
Chord network. Some processes may choose to partake of public services,
e.g. for anonymous communication, service registries, or cloud computing.

Though, my main motivation has been aimed more at ubiquitous systems,
resilience, anonymous communication, and decentralization of naming. RINA
seems to be more interested in utilization, network efficiency.



On Sat, Nov 9, 2013 at 4:46 AM, Guido Witmond <guido-EBfTt96odT/[email protected]> wrote:

> On 11/08/13 21:32, Will Pearson wrote:
> > I've just come across the idea of the Recursive Internetwork
> > Architecture and thought it had a number of properties that might
> > interest capability folk, if only for an idea to riff off of.
> >
> > To quote from here:
> > http://irati.eu/the-recursive-internetwork-architecture/
>
>
> > RINA takes as a point of departure the basic premise that “networking
> > is inter-process communication (IPC) and only IPC”. Networking
> > provides the means by which processes on separate computer systems
> > communicate, generalizing the model of local inter-process
> > communications.
>
> I've bought and read the book in one go. Mr Day really puts the finger
> on the sore spot of networking. His networking model to me is that of an
> idealized network. The current implementations of networks deviate and
> where these deviate, they create pain.
>
> In Day's model, I could start a service, give it a name and attach it to
> a DIF. The DIF assigns the address and provides a mapping from my name
> to the DIF-assigned address. Every other system in the DIF can query the
> name and retrieve the address. My service determines if that other party
> has authorization.
>
> Sytems outside the DIF have no way of querying the name of my server and
> hence cannot connect to my service at all.
>
> The current Internet, is one big DIF. Every VPN (closed network) on top
> of it could be seen as its own DIF.
>
> The ADSL-ATM connection between my modem and the ISP's head end could
> bee seen as a DIF underneath the Internet.
>
> It's a must read. It really opens your eyes on how clumsy the current
> internet protocols are. And where all the security and ddos-problems
> come from.
>
>
> > I find it a very nice model. It almost like objectifying the
> > network. The red light from from a capability based point of view
> > is "determining permissions". Now the security model isn't set, apart
> > from some form of authentication when joining a DIF. Is there an even
> > nicer model that uses capabilities to avoid confused deputy and other
> > such issues? And is anyone working on it?
>
> The thing to keep in mind is that RINA leaves the authentication and
> authorization to be defined by the DIF. Be it MAC, DAC or a hybrid.
>
> There is also the 'problem' of how to become part of a DIF so you can
> reach a service inside that DIF. This is where capabilities might shine.
>
>
> The riff to take home is that there is no important difference between
> IPC inside a local trusted domain (a single host/application/vat) and
> network(ing). Only the timing parameters change.
>
>
> Regards, Guido Witmond.
>
>
> _______________________________________________
> cap-talk mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/cap-talk
>
>

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk