Re: [Openh323gk-developer] Retransmitted ARQ results in second, identical RouteRequest on the Status
H.323 Gatekeeper for VoIP and videconferencing
Brought to you by:
willamowius
From: Zygmuntowicz M. <m.z...@on...> - 2005-10-26 08:27:26
|
Hi Frank, 1. Since retransmission opens only a small time window, there should be no security concern. Hijacking H.235 tokens is not a problem a they guarantee message integrity, so even if you hijack tokens, you will not be (in practice) able to send message with other data. Of course, retransmission problem is not solved. If the second message arrives after ACF is already sent, it's rejected. But this is not a big deal. Of course, a super intelligent stack could recreate tokens, but I doubt many stacks do so. 2. My personal opinion is that there is an ARQ misconcept in the gatekeeper. ARQ should not be connected with a call. It's only Admission ReQuest, nothing more - an endpoint can send a call after ACF or not. Also, there are many different scenarios, like pre-granted ARQs, which break usual GnuGk ARQ-call-DRQ scheme. The only reliable way should be to use an accounting module to signal call start/stop evens and use ARQ/RouteRequest to make routing decisions only. ----- Original Message ----- From: "Frank Fischer" <fra...@di...> Sent: Tuesday, October 25, 2005 4:45 PM > i think i found a critical aspect (wouldn't call it a bug, but close to) in > the handling of ARQs in 2.0.10 (don't know whether it's the same in 2.2.3). > Imagine an endpoint sends an ARQ, the ARQ is processed using VirtualQueue > and an ACF is sent back to the requesting endpoint. So far so good. > Unfortunately, as this may happen in the internet when using UDP, there is a > paket loss and the ACF never reaches the endpoint. Now, as this is foreseen > in the standards, after a certain timeout, the endpoint retransmits the SAME > ARQ again including the same timestamp and serial. IMHO this behaviour is > correct so far. > Now, as the second, indentical ARQ arrives at the Gatekeeper, the ARQ is > again issued as a RouteRequest on the StatusPort and an ACF sent back to the > endpoint. > > In my opinion the gatekeeper makes to wrong decisions in this case: > > (1) Since the second ARQ is a retransmission (ususlly sent by the underlying > stack), it has the same timestamp and random. For my understanding the > standard does not allow to confirm any kind of request when sent with a > random and timestamp that was used before. So, IMHO, the second ARQ would > have to rejected. Otherwise the security aspect of random and timestamp > would, at least partially, be treated ad absurdum. I fully understand, that > on the other hand side, the sense of retransmissions would be thrown into > question, too, if the gatekeeper would reject the ARQ. But the standard does > not specifiy that a retransmission would have to use the same random and > timestamp, so this would no break the standard. > > (2) Now, since the gatekeeper signales both RouteRequests and both ACFs on > the StatusPort, but only one call is actually created (the Gatekeeper > dispatches the second ARQ to the calltable entry that was created by the > first ARQ/ACR), any application listening on the StatusPort tracking calls > would, under normal circumstances, have no chance to realize that the first > and second ACF fit one single call (and not two). As a result the > application would remain waiting for a second ARQ/ACF, DRQ/DCF and CDR > message. In other words - for the external application there will remain one > call open. > IMHO, give the fact, that (1) would remain as it is right now, the > gatekeeper would have to introduce some kind of signaling on the Status Port > to indicate that a second ARQ/RouteRequest is mapped to the same calltable > entry because it was identified as a retransmission. > > What do you think about this? > > Greetings, > Frank |