Re: [SIP] DNS SRV and authentication challenges

["Bob Penfield" <bpenfield@acmepacket.com>]

----- Original Message -----
From: <adam.roach@ericsson.com>
To: "'Rich Schaaf'" <rschaaf@pingtel.com>; <sip@ietf.org>
Sent: Wednesday, June 13, 2001 4:35 PM
Subject: RE: [SIP] DNS SRV and authentication challenges


> > -----Original Message-----
> > From: Rich Schaaf [mailto:rschaaf@pingtel.com]
>
>   [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]
>
> > 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.
>
> 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 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
bpenfield@acmepacket.com


> (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
> Sip@ietf.org
> http://www.ietf.org/mailman/listinfo/sip
>


_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip