Problem with session resuming

[Sebastien Decugis]

Hello,

I am running in a problem with session resuming, I hope someone can
understand the source of the issue ^^. Please excuse the long mail...

I am setting multiple communication channels between two peers C
(client) and S (server) -- implemented using 3 SCTP streams s0,s1,s2. I
am doing a full handshake on the first channel, then I verify the
credentials. Once this is done, I would like to use session resuming
facility to handshake the other channels more quickly, and in parallel
(using multithreads). Unfortunately, the session resuming fails and it
ends doing a full handshake on all channels.

My understanding of the issue is that the server tries to resume a
session with a different ID than what was stored. Here is exactly the
sequence of events, I hope it clarifies.

C connects to S
C->S, s0: Client Hello, Session Id [0] (as reported by Wireshark)
S->C, s0: Server Hello, Session Id [F3CC1208 6C1657DF ... (32 bytes)]
The exchange continues and handshake succeeds.
On S: db_store_func is called with session id: [2E313400 6C1657DF ...
(32 bytes)]
Then, the resumed handshake is attempted on other streams:
C->S, s1: Client Hello, Session Id [F3CC1208 6C1657DF ... (32 bytes)]
C->S, s2: Client Hello, Session Id [F3CC1208 6C1657DF ... (32 bytes)]
on server: db_store_retrieve is called for session with id [2E313900
6C1657DF ... (32 bytes)] twice.

Since the Session Id is different between the store and retrieve
operations, my callback does not return the data and the server falls
back to full handshake. It is working, but less efficient than resuming
(especially when the number of streams increases...)

I would like to know:
- if it is normal that the first 32bits of the session Id is different
on the wire (captured with Wireshark) and in the db_func callbacks
(dumped from my callback). I suspect this is not the case, since except
for the first 4 bytes, the Id is exactly the same (not copied in the
mail for simplification).
- if you know what could cause these 4 bytes to change in the server
between what is received from the wire, the store, and retrieve operations ?

I can provide the wireshark capture and the logs from my daemons if it
helps.

By the way, I am using GNUTLS versions from my distributions : 2.8.3-2
on the client (Ubuntu) and 2.4.2-6+lenny2 on the server (debian). Please
let me know and pardon me if this is a known bug that has already been
fixed for a long time -- or if this bug is introduced by one of these
distributions. I could not find any "corrupted session id" bug anywhere,
and I am not too sure what else I can look for...

Thank you for any help you can provide, and sorry for the long mail!
Best regards,
Sebastien.

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)