ipcd is a program to handle networking for all other software.

WARNING

Security is TBD. Currently, only TCPd is implemented, which means no communication security.

ipcd functionalities

firewall

ipcd has to filter the connections to local services.

WIP.

authentication

ipcd has to authenticate clients asking for a service.

WIP.

redirection

Central networking management allows for functionalities such as redirections. For example, a local client asking for the authentication can be authenticated with a distant authentication service.

encapsulation

TBD.  WIP.

Configuration

Configuration is yet to be defined.

• redirection
• firewall
• authentication

Usage

This program can be used as follow:

# with some static rules
ipcd --allow in authd tls:example.com --deny in * * --allow out pong tls:pong.example.com:9000
ipcd --redirect authd nextversion-authd

usage examples

ipcd is requested each time a client is launched when the right environment variable is used. For example, we want to connect to a distant authd service:

IPC_NETWORK="authd tls://user@passwd:example.com:9000/authd"

Currently, the ipcd only works with tcp and unix routes.

IPC_NETWORK="pongd tcp://example.com:9000/pongd"

Changelog

• v0.1: (current) ipcd (redirections), tcpd

  • ipcd understands URIs (tcp://example.com/service or unix:///service)
  • tcp scheme is understood: ipcd contacts the tcpd service
  • unix scheme is understood: ipcd performs a redirection

• v0.2: websocketd is up and running, some documentation is available

  • websocketd
    • IPC services are accessible via WebSockets
    • websocketc is an example of client for it, not requiring libipc
  • documentation
    • pongd is a service template, up and running,

Roadmap

• v0.3: websocket scheme for clients, transparently usable through ipcd
• v0.4: firewall + redirections
• v0.5: static configuration: default routes, authentication
• v0.6: tlsd built-in, pre-shared keys
• v0.7: udpd
• v1.0: TBD

ipcd explanations

1. client contacts ipcd

2. ipcd understand the request from the client then contacts the local service responsible for the communication protocol required

3. once the distant connection is established (between the two tlsd services for example) ipcd provides a file descriptor to the client

4. finally, the client can perform requests to the distant service transparently

   during the connection:

   client <-> ipcd <-> tlsd <=> tlsd <-> ipcd <-> service

   then:

   client <-> tlsd <=> tlsd <-> server