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
"pool00011234pool00012345pool00013456pool00014567pool10000020pool10000021poo
l10000022pool10000023pool01100030pool01100031pool01100032pool01100033". 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

_______________________________________________
rserpool mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rserpool