Network Information V1.2, NIDB modifications - Specs and Design
1. Introduction
The V1.2 release of the Network Information (NI) servers is required to support the V2.0 clients. The current document describes the specifications and design for the modifications to the Network Information Database (NIDB) that are required for this release of the NI system. There are three main features that are added to the NI layer in V1.2:
2. NIDB support for latitude/longitude
2.1 Overview
The new version of the Freedom client needs the servers host latitude/longitude
information. This information will be entered by the server operator into
the NIDB (HOST database) using the NIDBTOOL and will be retrieved by the
client via the Network Information Query Server (NIQS).
2.2 Description
Issue
Adding a new entry into the HOST DBO requires considerable changes because
there are many dependencies on the DBO (Database Objects) data structures.
Solution
A simple solution to this is to add the latitude/longitude information into an existing entry in the NIDB. In HOST DB, there is string containing the 4-caracter region code. The size of this string is limited to 16 caracters by Freedom Database Object (FRDBO), although the T_FrDBOTypeNtdbHost data structure allows 64 caracters. The latitude/longitude information will be added to the end of this string and parsed by the new Freedom clients.
Note that a minimum of 15 caracters are needed to store:
In order to do add this information to this region string in the HOST DB, the NIDBTOOL needs to be modified:
User format (17 caracters)
This format is used by the server operator, so the client is not concerned with it. The User string format is a "user friendly" format for the operator to enter the information into the NIDB using NIDBTOOL. The NIDBTOOL will automatically convert this format into the "Database Format" before storing it into the NIDB. The user format is "RRRR:ddmmD/dddmmD" (Ex. "CA10:3025N/12030E"), where:
Database format (15 caracters) - CLIENT API
The string retrieved by the client from the NIQS cannot be longer than 15 caracters (limited by FRDBO). The format of the region string that is stored in the database will therefore be "RRRRddmmDdddmmD" (Ex. "CA103025N12030E"), where:
NIDBTOOL impact
There are two ways of entering information into the region string (HOST DB):
The main function of the NIDBTOOL adds the cmdEntity() function
by calling the zkShellAddCommand() function. The cmdEntity() then calls:
cmdEntityAddHost() does not call any methods from the NIDB API.
It calls directly zkDBStore() instead to add the new entry into the NIDB.
Since the NIDBTOOL needs to do the User-to-Database-format conversion and
the validation for both the UPDATE and the ADD commands, this process should
be done in the **cmdEntity()** function.
The NIDBTOOL command to add/update a host in the NIDB are respectively:
entity add host <host-entity-name> <hostname> <ipaddr>
<region> <servoperator> <policy>
entity update host <ent-name> <var-to-update> <newval>
For example:
entity add host host8 thierry.dev.freedom.net 10.16.128.136 CA10
"Zero-Knowledge Systems [100]" 1
entity update host host8 region CA11
The new format with the latitude/longitude information would require
the following:
entity add host host8 thierry.dev.freedom.net 10.16.128.136 CA10:7823N/10035W
"Zero-Knowledge Systems [100]" 1
entity update host host8 region CA10:7823N/10035W
2.3 Freedom client backward compatibility
Fortunately, the "old" version of the clients uses the region code by
extracting the first 4 caracters of the region code string.
Adding more information at the end of this string should therefore
not create any problem.
3 NIDB support for new entity types
3.1 Overview
The NIDB needs to support the following new entities:
3.2 Requirements
POP, NMTA and IMEP
The needs for the POP, NMTA and IMEP are to be able to:
COREAIP
The COREAIPS are identical to the AIPs (neighbours, ...), except that
they need to be a distinct type.
As such, we could list them independently from the AIPs.
3.3 New Messaging server types
Overview
The new Messaging server types (POP, NMTA and IMEP) should provide the same functionality as (and be equivalent to) the existing FMG type. All current entity types are defined in an enumeration called "FrEntIdType" in the frent library. As such, we need to add the following types to this enumeration:
Dependencies on the frent library
entTypeMap, as defined in ent.c, maps each entity type to its parent
(with respect to key signing and revocation) and to its name (string).
Each messaging type should be mapped to "FRENT_TYPE_FREEDOM_MONTH" and
to its respective name. The 3 new messaging entity type elements should
also be added to the FrEntIdType enumeration.
Dependencies in NIDBTOOL
There is a switch case in the cmdEntityDelete() function (in nidbtool_ce_delete.c) that will not process if the type is unknown. Because these are new entity types, they need to be added to this switch case to be processed similarly to any other node.
IMPORTANT - The HELP menu and man page should be updated accordingly.
Dependencies on NIDB
The NIDB layer also needs to be modified:
Dependencies on the frNetInfo library
The frNetInfo library will not populate properly if it does not know
about the new entity types. In fact, it queries for all entities that if
knows about, as defined in a table named "hostEnt". The 3 new entity types
need to be added to this table, which is the list of entity types that
frNetInfo is querying for.
Dependencies on the NISS
There are not many dependencies on the NISS. There is only a debugging
function that may need to be modified.
Possible dependencies with other componenents of the Freedom network
These new entity types may conflict with or new features should be added to the following components:
3.4 NIDB support for COREAIP entity type
Overview
The new COREAIP entity type has the same caracteristics as the AIP entity
type. It can therefore be the end of a link. This has many dependencies
on other modules.
Dependencies on the frent library
entTypeMap, as defined in ent.c, maps each entity type to its parent
(with respect to key signing and revocation) and to its name (string).
The COREAIP entity type should be mapped to "FRENT_TYPE_FREEDOM_MONTH"
and to "coreaip" as its name. The FRENT_TYPE_COREAIP element should also
be added to the FrEntIdType enumeration.
Dependencies on the nidbtool utility
Many commands of the NIDBTOOL must be modified:
Dependencies on NIDB
In many NIDB routines:
Dependencies on NISS
Some modifications are required for the NISS:
Dependencies on AIP *NIQS/NIDB patch
required*
The current system considers the AIP entity type as the only possible type for the end of a link. Unfortunately, this has been "hardcoded" in many places. The AIP keeps a local list of its neighbours: when it gets a list of its neighbours from the NIQS, it first deletes all neighbours of its own list that does not match with the ones in the NIQS list, and then stores every neighbour of the NIQS list into its own as AIPs.
The first time it goes up, its own list is empty, so all elements of the NIQS list is stored into its own list as AIPs (although there may now be COREAIPs). This does not create any problem till the next time it queries NIQS for its neighbour list again. If the AIP currently has a link to a COREAIP (which it sees as an AIP from its own list), the NIQS returns a list containing this neighbour as a COREAIP. Since this does NOT match with its own list, it will first delete the link with the COREAIP. It will re-create this link afterwards, but all existing routes on that particular link will be destroyed.
A NIQS patch can solve this problem by sending all AIP neighbours as
"AIPs", no matter if the neighbour is an AIP or a COREAIP. The AIP does
NOT need to make a distinction between the AIP and the COREAIP (only the
client does).
Possible dependencies with other componenents of the Freedom network
These new entity types may conflict with or new features should be added to the following components:
4 Acronyms
AIP
Anonymous Internet Proxy
DB
Database
DBO
Database Object
FMG
Freedom Messaging Gateway
FRDBO
Freedom Database Object
IMEP
Internet Mail Encryption Proxy
MAIP
Messaging Anonymous Internet Proxy
NI
Network Information
NIDB
Network Information Database
NISS
Network Information Stat Server
NIQS
Network Information Query Server
NMTA
Nym Mail Transfer Agent
POP
Post Office Protocol