[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [SIP] DNS SRV and authentication challenges
Hello,
> > 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.
>
> I strongly disagree.
>
> One of the nice things about the current SRV mechanism is that its nicely
> layered. To properly implement it, I don't need to know the conditions under
> which the transaction is being initiated. If, all of a sudden, I need to
> know call level or header-level semantics in order to do the right thing
> with SRV, we get a code nightmare. Therefore, requiring that the request for
> the INVITE after a challenge result in the same SRV decision as the previous
> INVITE is a big mistake, IMHO.
I agree with you that the protocol should ONLY ensure that
1) retransmissions of a request
2) ACKs for non 2xx reponses
3) CANCELs
are sent to the same network address than the initial request.
Since a second INVITE with authentication stuff is not any of these 3
cases, we should use the randomization algorithm used for choosing one
network address among all the SRV records provided.
However, I do not agree that we run into a code nightmare. I believe
that the code would be even simpler. Right now, in order to send
retransmissions, CANCELs and ACKs to the same network address we
typically use a hash of some fields, such as To, From, the numeric part
of the Cseq and the Call-ID. If intead of using all these variables we
just use the Call-ID, all the requests within a call will be sent to the
same network address.
Folks might argue that we lose some randomization power by excluding the
From, To and Cseq fields in the hash calculation, but I do not think it
really matters. These variables provide randomization only within a
call. Randomization among different calls is equally acomplish by using
just the call-ID.
I also agree that mechanisms that send challenges back to the client
should be stateless, since otherwise the server will be an easy target
for a resource attack. But I can think of different scenarios where
sending requests with the same Call-ID to the same network address might
be useful. For example, a client that sends an INVITE and before the
callee picks up wants to terminate the call attempt. If this client
sends a BYE rather than a CANCEL, it would be nice if it arrives to the
same network address. Mainly if the callee is behind a gateway that was
located using SRV.
Best regards,
Gonzalo
> The real problem is this:
> > 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.
>
> There are at least two things wrong with this proxy. First, and foremost,
> since both proxies are the result of lookups for the given domain, they
> should be equivalent, in the sense that both have access to the users
> username and password, and both are similarly configured. The idea with SRV
> is to provide load balancing and failure recovery across a set of
> homogeneous servers for a specific domain. This means that when the new
> INVITE arrives with credentials, they should be valid at this proxy as well.
> The nonce computation will be identical in this proxy, if it follows the
> recommended mechanisms in rfc2617 and the two proxies have synced time
> (which you want for other reasons).
>
> The second problem is the 403. Why on earth would the proxy send this? The
> digest and basic authentication mechanisms are stateless. That is, the
> treatment of a request with an invalid Proxy-Authorization header is
> identical to the case where no Proxy-Authorization header is present. As a
> result of this, the proxy does not need to remember that it issued the
> challenge, in order to process the response in the next INVITE. If you have
> a proxy which creates state when it issues the challenges, and uses this for
> the next INVITE, well, time to throw that one out and buy a good one. This
> proxy is easily the subject of a massive DoS attack, since it creates state
> for unauthorized requests.
>
> So, in the worst case, the second proxy uses a different set of
> configuration params, and is not time-synchronized with the first. What
> happens here? This second proxy should have sent a 401, with its own realm
> and its own nonce. The UAC generates credentials for this challenge as well,
> and in the third INVITE, includes both sets of credentials. It hits one of
> the two servers, and since the request has credentials valid at both, it
> works just dandy.
>
> In a properly configured network with good proxies, the second transaction
> would succeed at the second proxy.
>
> -Jonathan R.
>
> ---
> Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave.
> Chief Scientist First Floor
> dynamicsoft East Hanover, NJ 07936
> jdrosen@dynamicsoft.com FAX: (973) 952-5050
> http://www.jdrosen.net PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>
> _______________________________________________
> Sip mailing list
> Sip@ietf.org
> http://www.ietf.org/mailman/listinfo/sip
--
Gonzalo Camarillo Phone : +1 212 939 71 71
Columbia University Mobile: +358 40 702 35 35
472 Computer Science Building Fax : +358 9 299 30 52
1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo
New York, NY 10027
USA Gonzalo.Camarillo@ericsson.com
_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip