Subject: [SIP] DNS SRV and authentication challenges

From: Rich Schaaf <[email-masked]>
Date: Wed, 13 Jun 2001 16:10:14 -0400

Hi all,

I'm having trouble figuring out the correct behavior for the following
situation involving DNS SRV and proxy authentication.  The scenario is:

   For a given domain name, DNS is configured with two SIP SRV
   records.  The SRV records for the two hosts (let's refer to
   them as HostA and HostB) have the same priority and weight
   (i.e., round robin behavior).

   Transaction #1:
     A SIP client sends an INVITE request.  A DNS SRV lookup is
     performed by the SIP client (which returns HostA) and the
     request is sent to the SIP proxy at HostA.

     The SIP proxy sends back a "407 Proxy Authentication Required"
     response.

     The SIP client sends an ACK to HostA.

   Transaction #2:
     The SIP client sends a new INVITE request that includes
     proxy authorization information.  Since this is a new
     transaction, a DNS SRV lookup is performed by the SIP client
     (which returns HostB) and the request is sent to the SIP
     proxy at HostB.

     The SIP proxy at HostB is not the proxy that issued the challenge
     to the SIP client so it sends back a "403 Non-Trusted Caller"
     response and the call fails.

Based on my reading of draft-ietf-sip-rfc2543bis-03.txt, I think the SIP
client is adhering to the spec.  The draft states:
  "Clients MUST determine the destination address once per
   transaction rather than for each request, i.e., requests
   within the same transaction MUST be sent to the same network
   address."

The draft also defines a transaction as follows:
  "(SIP) transaction: A SIP transaction occurs between a client
   and a server and comprises all messages from the first request
   sent from the client to the server up to a final (non-1xx)
   response sent from the server to the client.  A transaction is
   identified by the CSeq sequence number (Section 10.20) within a
   single call leg. The ACK request has the same CSeq number as
   the corresponding INVITE request, but comprises a transaction
   of its own."

So, if my reading of the spec is correct, the SIP client is behaving
correctly.  The SIP proxy behavior and DNS configuration also seem
reasonable.  However, the end result is that the call fails to get set
up.

Please let me know if my reasoning is correct and I welcome any
suggestions on what _should_ happen in this situation.

Cheers,
Rich Schaaf

======================================================================
Rich Schaaf                               Pingtel Corporation
Email: [email-masked]                Suite 2200
Voice: +1 (781) 938-5306 x112             400 West Cummings Park
Fax:   +1 (781) 938-9650                  Woburn, MA  01801
======================================================================

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: [email-masked]
Date: Wed, 13 Jun 2001 15:35:22 -0500

> -----Original Message-----
> From: Rich Schaaf [mailto:[email-masked]]

  [Description of problem deleted. Synopsis: DNS points to
   two servers with the same q-values; one issues a challenge
   and the other receives the response]
 
> suggestions on what _should_ happen in this situation.

I would contend that, in these cirucumstances, you would
need to have some sort of coordination between these
"equivalent" nodes. They can share a back-end database
or a deterministic algorithm for generating challenges
based on, say, a synchronized clock.

(I'm not a security expert, so you might want to run
the second idea past someone who has a better idea of
what the implications of a deterministic challenge
algorithm might be if you intend to use it).

/a

_______________________________________________
Sip mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/sip

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 15 Jun 2001 16:19:05 -0400

----- Original Message -----
From: <[email-masked]>
To: "'Rich Schaaf'" <[email-masked]>; <[email-masked]>
Sent: Wednesday, June 13, 2001 4:35 PM
Subject: RE: [SIP] DNS SRV and authentication challenges

> based on, say, a synchronized clock.

I think it is just as reasonable to allow (or maybe require) the client to
send the INVITE with authentication to the same network address as the
initially rejected request. It seems clear to me that the intention of the
referenced text (section 1.4.2 I believe) was to ensure that any request
that required state in the "next-hop" server created by a recent prior
request is sent to the same SIP server. Although technically, it is a new
transaction, it is still the same "transaction" (placing a call) from the
user's point of view.

In either case, we may want to add text to cover this scenario.

(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]