Signpost Architecture and Communications

sebastian edited this page Dec 13, 2011 · 9 revisions

Policy - > social net. Based on resources and identity

A policy checker runs alongside of each signpost.

So the policy checker will be running on each one of the signposts. - Manage users’ address book. - Extended to include affiliation, social nets and friend’s keys (Google docs’ CardDav or whatever else)

Policy maker stores the database. Signpost will request public keys from users. Signpost will be key-agnostic.

Data stored on signposts

Databases. (Is it possible to extend google calendar online?)

Each signpost stores a database with the following tables:

A) USERS TABLE (Extension Address Book) ID(Primary Key), Name, Fields (Address Book, from google?)

B) SIGNPOST_USER_IDS TABLE USER_ID, SIGNPOST_LIKE_NAME (Primary Key, String in the fashion twitter@narseo), KEY (Generated by the other users signpost), TIMESTAMP (Used to refresh keys)

C) POLICIES TABLE ID (primary key for the policy), Policy_data (needs to be defined. Policy language!)


Push keys?? At the moment we are only pulling stuff from the signpost. It might be possible to exploit channels to refresh your keys in your friends’ tables.

User tables and Policies are kept in sync between all of a users signposts. It will remain secure in your personal signpost network. The entries in the UsersIds table are only cached, but not replicated between signpsosts. If a key entry does not exist in a UserIds table on a signpost, it requests it from the clients signpost using an HTTP GET request (GET /keys/CONNECTING_DEVICE_ID)

Synchronise changes in address book between machines.

Communication between client resolver and signposts

All responses and payloads are in JSON.

Get a list of signposts

Request: GET /v1/signposts

Returns: [{'ip' = IP, 'port' = PORT},...]

A list of signposts objects (crotsos: How does a personal signpost, or a signpost server register in the system?)

Resources provided under a domain

Request: GET /v1/resources/DOMAIN

Returns: [{'resource_name'=RESOURCE_NAME, 'resource_id'=RESOURCE_ID, 'service'=SERVICE_PROVIDED},...]

A list of all the resources the client is allowed to see within a domain. The DOMAIN is either one of the domains under control of the signpost, or a remote domain, in which case the signpost proxies the request to the signpost responsible for the domain.

(crotsos: maybe need to add some information about the identity of the requester)

Resources provided by a particular device

Request: GET /v1/resources/domain/DEVICE

Returns: {'status' = "OK|FAILURE", ('message' = REASON_FOR_FAILURE | 'ip' = IP_TO_CONNECT_TO, 'port' = PORT_TO_CONNECT_TO)}

It returns a status of either OK or FAILURE. If OK is returned, an ip and port is returned alongside the response. If FAILURE is returned, a message describing the failure is returned as well.

Adding a new device to a signpost

Request: POST /v1/resources/DOMAIN

Payload: {'device-name'=NAME_OF_DEVICE, 'device-type'="AWARE|DUMB|ENABLED"}

Response: {'status' = "OK|FAILURE", ('message' = REASON_FOR_FAILURE | 'private-key'=NEW_DEVICE_PRIVATE_KEY)}

Upon approval from the user, the device is added to the signpost domain requested.

Updating the information for a device

Request: PUT /v1/resources/domain/DEVICE

Payload: {'accessible_through'= [{'ip'=IP, 'port'=PORT, 'process_name'=NAME_OF_LISTENING_PROCESS},...]}

Multicast DNS

Request: POST /v1/multicast/domain/device

Payload: [{'source_ip'=IP_OF_BROADCAST_SOURCE, 'port'=PORT_ON_LISTENING_DEVICE, 'service'=SERVICE_TYPE}, ...]

The services broadcasted by a device can be relayed to the signpost network and the other devices of the user.

Invalidated keys

Request: GET /v1/invalidated_keys[/UNIX_TIMESTAMP]

Returns: [{'device'=DEVICE_ID, status='INVALID|NEW','pub-key'=PUB_KEY},...]

Communication between signposts

A signpost of user A, needs the public-key of a DEVICE belonging to the signpost of user B.

Request from A to B: GET /v1/keys/DEVICE

Returns: {'device_id'=ID, 'key'=KEY_DATA} (crotsos: maybe suppress that by doing host authentication in SSL)


The sequence diagram accompanying the following sequence of steps can be found here: diagram with labels and diagram without labels.

  1. client application requests the IP of domain
  2. assuming no DNS cache, the resolving performs a DNS request
  3. the DNS server returns the signpost to the resolver
  4. the resolver asks its local signpost on the macbook to resolve
  5. the signpost on requests the resource from the signpost
  6. the signpost asks it’s policy checker if the request should be allowed
  7. if the public-key of is cached, a policy decision can be made directly and the reply returned to's signpost, otherwise:
  8. the policy checker does a DNS request for to find it's signpost
  9. the DNS server returns the signpost name
  10. the policy checker requests the public-key of from the signpost
  11. the key is returned to the policy checker which caches it
  12. the policy checker makes a decision based on social graph
  13. the decision is returned to the signpost
  14. the response is returned to

The following steps are taken depending on if the policy checker allows or denies a response to be generated (unfortunately the numbering is off. It should read 15-17(d - denied, a - accepted).

Scenario, connection denied:

  1. the signpost on returns that there is no response to the local client resolver
  2. the client resolver returns responds to the application DNS request that there is no match for

Scenario, connection accepted:

  1. the signpost on returns the ip and port number to connect to, to the client resolver
  2. the resolver returns a SRV record or an A record to the application
  3. the application connects to the application running on

Note: There is a process in on each users authoritative signpost that checks and updates a users social network data. Changes it detects are propagated to the other signposts of the user.

All data distribution between signpost instances (also including data for the policy manager) is handled by the signposts.