RE: PE Checksum Computation

Johnson Walter-CWJ002 <[email protected]> Fri, 1 Jul 2005 09:48:41 -0500
Newsgroups gmane.ietf.rserpool
Message-ID <6F8DFFA2C996D711945800065BFC9E4A16048324@il02exm11>
I agree with your comment. 

But the ENRP draft already addresses this on page 35 by the defined byte block shown below. So you are guaranteed to align to a 32 bit boundary for the PH. So there is no problem as defined currently.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :  Pool handle string of the pool the PE belongs (padded with   :
      :  zeros to next 32-bit word boundary if needed)                :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        PE Id (4 octets)                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 



-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Thomas Dreibholz
Sent: Friday, July 01, 2005 9:18 AM
To: [email protected]
Subject: [Rserpool] PE Checksum Computation

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

For the case that a checksum algorithm with more than 8 bits is used, all 
fields over which the checksum is computed must be padded to the bit size of 
the checksum algorithm, i.e. 32 bits. Otherwise, bytes can be misinterpreted 
as the following example shows:

Example:
- - PE 0x12345678 in pool "Pool1"
- - PE 0x33445566 in pool "PoolX2"
=> Checksum over: Pool1(0x12345678)PoolX20x33445566
1. 32 bits: "Pool"
2. 32 bits: "1"0x123456
3. 32 bits: 0x78"Poo"
4. 32 bits: "lX2"0x33
5. 32 bits: 0x445566(0x00 Padding)

Here, the PH is not padded to 32 bits, so when you compute the checksum of the 
second PE alone:
1. 32 bits: "Pool"
2. 32 bits: "X2"0x3344
3. 32 bits: 0x5566(0x0000 Padding)

That is, the meaning of the first byte has shifted and checksum(Pool1
(0x12345678)PoolX20x33445566) != checksum(Pool1(0x12345678)) + 
checksum(PoolX20x33445566).

To avoid this problem, the draft should explicitly say that each field over 
which the checksum is computed - especially the PH, since it is 
variable-length - MUST be padded to full 32 bits before the checksum can be 
computed.


Best regards
- -- 
=======================================================================
 Dipl.-Inform. Thomas Dreibholz

 University of Essen,                            Room ES210
 Inst. for Experimental Mathematics              Ellernstraße 29
 Computer Networking Technology Group            D-45326 Essen/Germany
- -----------------------------------------------------------------------
 E-Mail:     [email protected]
 Homepage:   http://www.exp-math.uni-essen.de/~dreibh
=======================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCxVCl32BbsHYPLWURAli9AJ9N6KpxjO064O4EYRegDiuHRLBd5QCeIK8d
dCZMcKiNFaNAsLk2TY7tzZM=
=U5DJ
-----END PGP SIGNATURE-----

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