[Rserpool] Query Regarding Auditing Mechanism used in RserPool.

Hello all,

This mail is regarding the auditing procedure as defined in RSerPool Draft (draft-ietf-rserpool-enrp-11.txt).

As per the auditing specifications defined in draft section 3.11.1, the auditing mechanism is based on the computing the PE checksum as defined in section 3.11.2 of the draft. The ADLER-32 checksum algorithm is to be used for computing the checksum over the byte block formed from combining the pool handle (padded to 32-bit word boundary) and the 32-bit PE Id. It appears the RSerPool group wanted a PE checksum that is "order independent" so incremental updates (adds/deletes) of the checksum could occur. The observation is that the ADLER-32 checksum is "order dependent", which can be illustrated by the following example.

Consider a system comprising of three enrp servers E1, E, and E3. Let "DatabaseEnrp1" be the database associated with the E1 for all Pool Elements Registered with E1. Consider the following DatabaseEnrp1 stored on E1.

"DatabaseEnrp1"

---------------------

pool0001 -> 1234, 2345, 3456, 4567

pool1000 -> 0020, 0021, 0022, 0023

pool0110 -> 0030, 0031, 0032, 0033

The data processed by the Adler-32 algorithm would be of the following format "pool00011234pool00012345pool00013456pool00014567pool10000020pool10000021pool10000022pool10000023pool01100030pool01100031pool01100032pool01100033". The data in the handlespaces of E2 and E3 would be the same for the PEs E1 owns.

Now consider a different ordering of the same data in E2 and E3 handlespaces.

"DatabaseEnrp2"

---------------------

pool0110 -> 0030, 0031, 0032, 0033

pool0001 -> 1234, 2345, 3456, 4567

pool1000 -> 0020, 0021, 0022, 0023

"DatabaseEnrp3"

---------------------

pool1000 -> 0020, 0021, 0022, 0023

pool0110 -> 0030, 0031, 0032, 0033

pool0001 -> 1234, 2345, 3456, 4567

The ADLER-32 checksum as per the procedure defined in Section 3.11.2 results in the following:

Label INPUT ADLER-32 Checksum

------- -------- ----------------------------

checksum1(pe.checksum.pr0) DatabaseEnrp1 4bf92729

checksum2(pe.checksum.prenrp1) DatabaseEnrp2 45992729

checksum3(pe.checksum.prenrp1) DatabaseEnrp3 3ab92729

Observe that the checksums are different, even though the "content" of the database corresponding to E1 is the same; it is just organized in a differently on E2 and E3.

Now, during the auditing phase, when E1 sends "checksum1" to E2 (in a Peer Presence message), E2 most likely will find a mismatch in the checksum, and hence send a request for the handlespace corresponding to E1.

Thus the conclusion is that a mismatch in checksum necessarily does not mean that there is a mismatch in the handlespace.

The following questions arise:

1. Based on the above mentioned observations, for the proposed auditing scheme to work, the handlespace has to be ordered in some way, and this ordering has to be consistent across all enrp servers. Do we want to do this? And if we do, how do we want to define the ordering? We assume ordering of the handlespace is not wanted by the RSerPool group.

2. If the database is indeed ordered, there will be an overhead in terms of performance of the protocol. (The checksum will need to be computed whenever a Peer Presence message is received). As of now, we do not know what impact this will have on the performance, however, database queries and re-organization of the data entries is a time consuming process. Also the question arises, should a Session Layer protocol define how a database should be organized or in what sequence should it be retrieved? Will this not be very a specific requirement on the part of RSerPool?

3. One of the solutions as suggested in the RSerPool drafts is to compute the checksum incrementally. But ADLER-32 does not appear to work incrementally for subtraction of an byte block from a previous checksum. So we still need to extract individual objects from the database, and re-compute the checksum.

4. Since the auditing mechanism in RSerPool is currently based on a checksum, what approach is the right approach for auditing? To use a different checksum that allows "order independence". An alternate approach would be periodically request for the handlespace, and there can be many more approaches, all with their respective advantages and disadvantages. At this point in time, is there a need to look at alternate approaches for auditing and/or just focus on alternate checksum mechanisms, and/or ordering the database mechanisms?

5. Also, another question that comes to mind, is auditing really required in the present form? The general thread that is followed in RSerPool protocol is its so called "loosely" coupled nature. Unless and until there is a Transport Failure, the HANDLE SPACE DOWNLOAD mechanisms along with the HANDLE SPACE UPDATE mechanism will more or less ensure that the handlespace is up to date. If it is not up to date, then it just offers services with whatever is currently stored in the handlespace. In the worst case, assuming that we do not have any auditing, a PU will not get a HANDLE RESOLUTION RESPONSE, and it will try with another Enrp server.

We will appreciate anyone views on this topic.

Thanks

Abhijit Lele

Motorola Labs