Network Information V1.2, NIDB modifications - Specs and Design


$Id: nidb12.html,v 1.4 2000/08/02 15:31:45 louis Exp $
$Author: louis $
$Date: 2000/08/02 15:31:45 $

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:

The region string being limited to 16 caracters (the last one being the \0), there is no space left for separator caracters. Although this has no impact on the Freedom client, this leads to a format which is not very user-friendly for the server operator. The "User format" (see below) will therefore be used to provide a more readable format for the server operator using NIDBTOOL, and the NIDBTOOL will convert the User format to the database format before it is stored into the NIDB.

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:

Unfortunately, simply adding these elements to the FrEntIdType enumeration does NOT make the NI system support the corresponding new entities. There are many dependencies as stated in the following sections.
 

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:

Further investigation is required.
 

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:

Further investigation is required.
 
 

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
 


Copyright © 2000 Zero-Knowledge Systems Inc.
All Rights Reserved.