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(a)domain.com --> Contact = user_domain.com@any_IP
So if the registrar receives a REGISTER for AoR "user(a)domain.com" containing
a "Contact" different that "user_domain.com@any_IP" it should reject
it.
A convention with just username part:
AoR = user(a)domain.com --> Contact = user@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@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(a)in.ilimit.es