client
Click on the red underlined text to get to the source
... SIP) (RFC 3261prop [1]) is a client-
server protocol used for the initiation and management of
...
... Currently, use of TLS is defined for TCP only. Thus, clients need to
be able to automatically determine which transport protocols are
...
... throughout the processing of a call. In general, an element that
wishes to send a request (called a client) may need to perform DNS
processing to determine the IP address ...
... identity of the available server would ideally be cached for some
amount of time in order to reduce call setup delays of subsequent
calls. The client cannot query a failed server continuously to
determine when it becomes available again, since this does not scale.
...
... Client Usage ...
...
Usage of DNS differs for clients and for servers. This section
discusses client usage. We assume that the client ...
... DNS differs for clients and for servers. This section
discusses client usage. We assume that the client is stateful
(either a User Agent Client ...
... clients and for servers. This section
discusses client usage. We assume that the client is stateful
(either a User Agent Client (UAC ...
... client usage. We assume that the client is stateful
(either a User Agent Client (UAC) or a stateful proxy). Stateless ...
... proxies are discussed in Section 4.4.
The procedures here are invoked when a client needs to send a request
to a resource identified by a SIP or SIPS (secure SIP ...
...
First, the client selects a transport protocol.
...
... TARGET is not numeric, but an explicit port is provided, the
client SHOULD use UDP for a SIP URI, and TCP ...
... service value. As per RFC 2915(-> 3404prop | 3403prop | 3402prop | 3401) [3], the client
discards any records whose services fields are not applicable. For
...
... the purposes of this specification, several rules are defined.
First, a client resolving a SIPS URI MUST discard any services that
...
... do not contain "SIPS" as the protocol in the service field. The
converse is not true, however. A client resolving a SIP URI SHOULD
retain records with "SIPS" as the protocol, if the client ...
... client resolving a SIP URI SHOULD
retain records with "SIPS" as the protocol, if the client supports
TLS. Second, a client ...
... client supports
TLS. Second, a client MUST discard any service fields that identify
a resolution service ...
... service whose value is not "D2X", for values of X that
indicate transport protocols supported by the client. The NAPTR
processing as described in RFC 2915(-> 3404prop | 3403prop | 3402prop | 3401) ...
... the most preferred transport protocol of the server that is supported
by the client, as well as an SRV record for the server. It will also
allow the client ...
... by the client, as well as an SRV record for the server. It will also
allow the client to discover if TLS is available and its preference
for its usage.
...
... for its usage.
As an example, consider a client that wishes to resolve
sip:user@example.com. The client performs a NAPTR ...
... As an example, consider a client that wishes to resolve
sip:user@example.com. The client performs a NAPTR query for that
...
... DNS records to contain
replacement values in a different domain, and the client could not
validate that this was the desired behavior or the result of an
...
... transport is supported if the
query is successful. The client MAY use any transport protocol it
desires which is supported by the server ...
...
This is a change from RFC 2543(-> 3265prop | 3264prop | 3263prop | 3262prop | 3261prop). It specified that a client would
lookup SRV records ...
... port is present in
the URI, the client performs an A or AAAA record lookup of the domain
name ...
... transport protocol
determined previously. The client SHOULD try the first record. If
an attempt should fail, based on the definition of failure in Section
4.3, the next SHOULD be tried, and if that should fail, the next
...
... performed. If it was not, because a transport was specified
explicitly, the client performs an SRV query for that specific
...
... 2782prop spells out the details of how a set of SRV records are
sorted and then tried. However, it only states that the client
should "try to connect to the (protocol, address, service ...
... timer F in RFC 3261prop [1] fires). If a failure occurs, the client
SHOULD create a new request, which is identical to the previous, but
...
... 3261prop [1] defines procedures for sending responses from a server
back to the client. Typically, for unicast UDP requests, the
response is sent back to the source IP address ...
... connection the
request arrived on. However, it is important to provide failover
support when the client element fails between sending the request and
receiving ...
... TLS over TCP). As in
the client processing, the next entry in the list is tried if the one
before it results in a failure.
...
... DNS NAPTR records are used to allow a client to discover that the
server supports TLS. An attacker ...
... TLS. An attacker could potentially modify these
records, resulting in a client using a non-secure transport when TLS ...
...
The bid down attack can also be mitigated through caching. A client
which frequently contacts the same domain SHOULD cache ...
... queries cease to appear, it is a
sign of a potential attack. In this case, the client SHOULD generate
some kind of alert or alarm ...
... An additional problem is that proxies, which are intermediaries
between the users of the system, are frequently the clients that
perform the NAPTR queries ...
... security. There is very little that can be done to
prevent such attacks. Clients are simply dependent on proxy servers
for call completion, and must trust ...