[OpenSER-Users] best response seems wrong.

[Iñaki Baz Castillo]

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?

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.



-- 
Iñaki Baz Castillo
ibc at in.ilimit.es