Barman, Sibon B (Sibon) wrote:
> Since the SBC is providing received and rport parameters in the Via
> header you can deduce the external address from that and co-relate that
> to the Contact header address. But is it a well known practice for UAs
> to do so to be interoperable with most servers out there. It seems that
> some other UAs actually can handle such registrations.
And this is a *good* thing???
If the SBC is going to translate the Contact in the request, then it
also ought to back translate the Contact in the response.
It is a bit much to expect UAs to implement workarounds MITM attacks by
SBCs.
Paul
> Sibon Barman| P2P Business Unit | Communication Appliances Division |
> Avaya Canada Corp. | 1135 Innovation Drive, Suite 100 | Ottawa, Ontario,
> Canada K2K 3G7 | phone: +1.613.592.4343 ext 248 | fax: +1.613.592.5262|
> [EMAIL PROTECTED]
>
>
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 14, 2007 11:44 AM
> To: Barman, Sibon B (Sibon)
> Cc: [email protected]
> Subject: Re: [Sip-implementors] Registration request with private
> address and response with public address
>
>
>
> Barman, Sibon B (Sibon) wrote:
>> When a user agent sends a REGISTER request with private address in
> the
>> Contact header, the session border element sends a response with the
>> UA's public IP address in the contact header as well as in the Via
>> header's rport and received parameters. Is that correct spec-wise ---
>> should the UA be able to handle this registration response and treat
> it
>> as its own contact? Or does the 3261 spec dictate that the response
>> should contain the same contact address as the request?
>
> This sounds bogus to me. But a registrar has a lot of lattitude. It is
> probably not technically illegal, but is behavior that should be
> expected to present problems for standard conforming UAs.
>
> The response to the REGISTER should contain the contacts that are in
> fact registered. If the contact was being registered with a non-zero
> expiration time, and was successful, then you would expect to see that
> same contact in the response. In principle the registrar is free to
> ignore the contact, or accept it but decide to expire it immediately, so
>
> that it doesn't show up in the response. But that would be bizarre.
>
> I think what you are implying is that an SBC is replacing the contact
> address in the REGISTER with another address and then passing the
> request on to the registrar. And when the response is returned, the SBC
> is *not* doing the inverse translation on contact in the response.
>
> Since there are no rules for SBCs, I guess we can't say for certain that
>
> the SBC is wrong to do this. But if it is attempting to be "transparent"
>
> so that a "normal" UA will work with it, then it is not doing a very
> good job.
>
> If the UA is expected to cope with this situation, *how* is it expected
> to do so? It must look at the response to discover the actual expiration
>
> time of its registration. If its own contact isn't there, how can it
> recognize which one applies to it and hence what the expiration time is?
>
> Paul
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
