[OpenSER-Users] best response seems wrong.

[Klaus Darilion]

Iñaki Baz Castillo schrieb:
> On Thursday 17 January 2008 09:14:35 Klaus Darilion wrote:
> 
>> SIP is by design buggy: The SIP protocol tells us to save the contact 
>> during REGISTER and to use this contact for incoming calls to the 
>> respective user. But the contact is user provided
> 
> I understant what you mean, but sincerely, I can't imagine how a registrar 
> could validate user provided "Contact". Yes, it can forbid some IP's or 
> domains (see comment below anyway) but how a registrar can know that 
> the "Contact" header belongs or not to the device sending the REGISTER?

Yes. You can not validate every IP address - but you can deny known fake 
IP addresses (the IP addresses of internal components).

Further, you could use fix_nated_register for each clients (which of 
course breaks communication with asymmetric clients (Cisco phones+pix) 
but this is spoofable (unless src_IP will be used for nonce calculation.)

klaus

> 
> Another design option wolud be use internal and trusted data for the "Contact" 
> isntead of user provided, but how does it make sense?
> 
> The only solution I see could be forzing a convention for the "Contact" URI:
> 
>   AoR = user at domain.com  -->  Contact = user_domain.com at any_IP
> 
> So if the registrar receives a REGISTER for AoR "user at domain.com" containing 
> a "Contact" different that "user_domain.com at any_IP" it should reject it.
> 
> A convention with just username part:
>   AoR = user at domain.com  -->  Contact = user at any_IP
> wouldn't be so strong since it doesn't avoid flood in case of multidomain.
> 
> 
> But of course, forcing this convention should be done at RFC3261 (IMHO).
> 
> 
> 
> 
>> Further, I also screen the contact during registration (actually with
>> openser's blacklist feature this is not really needed anymore - but
>> often you have system with older openser versions and you might not
>> update) using the permissions module and forbid IP addresses of internal
>> components, the proxy itself and optional also domains.
> 
> In this point, remember that forbiding some IP addresses in "register.deny" is 
> not useful at all since a malicious user can set a public domain pointing to 
> that internal IP and set a "Contact: <sip:pstn_number at domain_hacker.com>".
> 
> As you said, a solution is forbidding domain names in "Contact" (but not very 
> RFC3261 compliant).
> 
> The best is reading the thread you pointed i nwhich you and others gave very 
> good solutions and explanations for this serious problem.
> 
> 
> Regards.
> 
> 
>