[Sip-implementors] Hostnames vs IP Addresses

[James Cloos]

I've noticed that all of the fraud attempts which come to my advertized
SRV destinations use ip addresses for the To and From headers and for the
INVITE line.

My code to verify that INVITEd addresses are valid expects domain names
or hostnames, not ip addresses in those fields.

Do any legitimate sip connections, after looking up NAPTR and/or SRV
records, use the SRV destinations' addresses in the INVITE attempt?
Or always the string from the sip: uri?

As NAPTR-advertized SRV targets, they have to accept SIP from
everywhere, but like an MX only pass on legitimate-looking calls
and refuse the rest.

-JimC

[Paul Kyzivat]

Post by James Cloos
I've noticed that all of the fraud attempts which come to my advertized
SRV destinations use ip addresses for the To and From headers and for the
INVITE line.
My code to verify that INVITEd addresses are valid expects domain names
or hostnames, not ip addresses in those fields.
Do any legitimate sip connections, after looking up NAPTR and/or SRV
records, use the SRV destinations' addresses in the INVITE attempt?
Or always the string from the sip: uri?
As NAPTR-advertized SRV targets, they have to accept SIP from
everywhere, but like an MX only pass on legitimate-looking calls
and refuse the rest.

How are clients obtaining URIs that reference your destinations? In
principle, the URIs that identify your destinations are strictly your
business. If you give out only URIs with domain names, then that is what
clients should be using. Only servers that are "responsible for the
domain" are permitted to translate those URIs.

So, if you only hand out URIs with domain names, you should feel free to
reject requests where the R-URI has your IP address.

Do your URIs contain names, or phone numbers in the user part?

Common practice has developed that servers are free to manipulate any
URI that appears to include a phone number, replacing the domain name as
they see fit.

IMO this is *wrong*, but I haven't been able to convince anybody else of
that.

Thanks,
Paul

[James Cloos]

PK> If you give out only URIs with domain names, then that is what
PK> clients should be using.

PK> Only servers that are "responsible for the domain" are permitted to
PK> translate those URIs.

Thanks. That is what I expected when I wrote the validation code, but I
do not have access to enough different client software to be certain.

PK> Common practice has developed that servers are free to manipulate any
PK> URI that appears to include a phone number, replacing the domain name
PK> as they see fit.

PK> IMO this is *wrong*, but I haven't been able to convince anybody else
PK> of that.

So, if someone were to dial tel:[phone], and their client did
the NAPTR on e164.arpa and found sip:7472467264 at jhcloos.com, either
followed that by an NAPTR on jhcloos.com or directly looked for a sip
SRV there, then even though the invite to the proxy SHOULD be to
7472467264 at jhcloos.com it might end up being to 7472467264 at PROXY_NAME
or to 7472467264 at PROXY_IP? But sip:cloos at jhcloos.com always will
have that string in the invite?

-JimC

[Paul Kyzivat]

Post by James Cloos
PK> If you give out only URIs with domain names, then that is what
PK> clients should be using.
PK> Only servers that are "responsible for the domain" are permitted to
PK> translate those URIs.
Thanks. That is what I expected when I wrote the validation code, but I
do not have access to enough different client software to be certain.
PK> Common practice has developed that servers are free to manipulate any
PK> URI that appears to include a phone number, replacing the domain name
PK> as they see fit.
PK> IMO this is *wrong*, but I haven't been able to convince anybody else
PK> of that.
So, if someone were to dial tel:[phone], and their client did
the NAPTR on e164.arpa and found sip:7472467264 at jhcloos.com, either
followed that by an NAPTR on jhcloos.com or directly looked for a sip
SRV there, then even though the invite to the proxy SHOULD be to
7472467264 at jhcloos.com it might end up being to 7472467264 at PROXY_NAME
or to 7472467264 at PROXY_IP? But sip:cloos at jhcloos.com always will
have that string in the invite?

AFAIK that scenario is entirely hypothetical, because public enum has
been a failure. Carriers use enum, but they do so with private enum DBs
and peering relationships that determine how they interface with one
another.

That world is ruled by SBCs. For the most part they keep remapping
numbers, changing the domain name as the request moves from peer to peer.

But if you were in such a situation, then you probably would know the
rules they play by and wouldn't be surprised.

Thanks,
Paul

Thanks,
Paul

Thanks,
Paul