I can't help but think this is really a red herring. If you think about a PRACK as a glorified ACK, what value does challenging it really give? I mean you can't challenge an ACK, yet life seems ok. The dialog identifiers have to match anyway, and exactly how maliciously useful is it for a true MITM to fake PRACK a response?? Besides, the whole discussion of this is rather warped. The UAS is not in a position to decide whether to stop response re-transmissions, unless it actually *receives* the PRACK. So if a Proxy challenged it, there's no point in saying the UAS should or shouldn't retransmit responses - of course it will retransmit them, because it doesn't know any better. And if the PRACK was challenged, the UAC has to send it again with a challenge-response if it can. Am I missing something? -hadriel > -----Original Message----- > From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On Behalf > Of Paul Kyzivat > Sent: Tuesday, March 31, 2009 2:40 PM > > Christer Holmberg wrote: > > > > Hi, > > > > One of the PRACK related issues presented in SFO is whether a PRACK > > non-200 response would cease re-transmission of the assoicated reliable > > 18x response. > > > > Based on the mail discussions we've had I proposed that the non-200 > > response DOES NOT ceasee the re-transmission. However, some people > > seemed to have an issue with that, so I was asked to "take it to the > list". > > > > The main justification why a non-200 response would not cease the > > re-transmission is because an intermediate may reject the PRACK, in > > which case the UAS will never receive it (read: the UAS will continue to > > re-transmit the reliable 18x). So, when the UAC receives the PRACK > > non-200 response it should send a new PRACK, which hopefully will reach > > the UAS and trigger a 200 response. > > > > So, anyone who does not agree with the justification aboive, and thinks > > that a non-200 response DOES cease the re-transmission of the associated > > reliable 18x response, please indicate so. > > I agree with Christer here. Another scenario where this would be > important is: > > -> INVITE > <- 180rel > -> PRACK > <- 401 > > It this case it is essential to retry the PRACK with updated > credentials. Certainly the UAS doesn't want to consider the 180 to have > been acknowledged in this case, since it might have been from a MiTM. > > This could come about in the case of a reINVITE, where the nonce used in > the original INVITE finally becomes stale by the time the PRACK is > received. > > Thanks, > Paul > _______________________________________________ > Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip > Use sip@xxxxxxxx for new developments of core SIP _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
