I think there is no single answer to your questions. The answer depends
on the circumstances of the environment you are operating within. If you
have all secure signaling then you probably won't bother challenging
in-dialog requests. If you have no secure signaling (e.g. sip over UDP)
then you should probably challenge *all* requests, whether in-dialog or not.
Note that after you have challenged once, the UA will hopefully be
preemptively including the same credentials in future requests. You
won't have to challenge again until the nonce expires. So the cost of
extra signaling need not be high.
Paul
SCG2 wrote:
> Sorry - I meant the question was asked of me in terms of how our proxy would
> behave - would it issue a challenge to the sendonly INVITE from Phone B vs.
> would it simply allow the routing to Phone A on the grounds that "we are in
> a dialog already". The grounds for their asking appear to be the network
> round trips not doing this might save when putting on hold for MOH etc.
>
> My view (which I think I'm still holding to based on what you all said) is
> that the proportion of INVITEs that are sendonly are so low that this:
>
> a) would not "save" anything significant in resource / processing terms
> along that portion of the signalling path
>
> b) could open up a large replay hole
>
> so today our proxy challenges all sendonly INVITEs which I hope is the "more
> correct answer".
>
> As Paul says this question could equally apply to several / many in dialog
> requests.
>
> Thanks for all your help.
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
> Sent: 28 January 2008 14:11
> To: Steve Langstaff
> Cc: SCG2; [email protected]
> Subject: Re: [Sip-implementors] Challenging a sendonly INVITE
>
> The question is a little too narrow. The same issues apply to any
> in-dialog request.
>
> Steve makes a good point. But practically speaking authentication is
> rarely done on in-dialog requests. Bypassing it assumes that the dialog
> id is only known to the parties on the signaling path, even though this
> might not be true.
>
> In most cases, in the original scenario here Phone A would not share a
> secret with Phone B that could be used for authentication. So if Phone A
> issues a challenge there is a strong likelihood that it will fail.
> This wouldn't necessarily cause the call to fail, but wouldn't help.
> BUT, if Phone A *does* issue a challenge like this, then of course Phone
> B should properly respond to it if it has the proper credentials to do so.
>
> Paul
>
> Steve Langstaff wrote:
>> How do you know it *really* is phone B that is asking for the HOLD?
>>
>>> From: [EMAIL PROTECTED]
>>> [mailto:[EMAIL PROTECTED] On
>>> Behalf Of SCG2
>>>
>>> Is there any circumstance at all where it makes sense to
>>> challenge an INVITE which is putting a call on hold?
>>>
>>> I can find nothing in 3264 that suggests it, but wondered if:
>>>
>>> Phone A -> Phone B (in doing so phone A may have been authenticated)
>>>
>>> Phone B later goes to put phone A on hold
>> _______________________________________________
>> Sip-implementors mailing list
>> [email protected]
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
