Subject: [Sip] comments on sip-auth

From: "Bob Penfield" <[email-masked]>
Date: Tue, 19 Mar 2002 14:39:47 -0500

I have two comments on the sip-auth draft. I apologize if these issues have
already been raised.

Has the idea of qop value for authentication plus header integrity without
including the message body been considered? In situations where the request
must traverse a NATing SIP element which "fixes" the IP addresses and ports
in the SDP to enable the RTP media flows, the only alternative is plain
"auth" and no integrity at all.

Section 7.3 says:
   If a stateful proxy receives a 492 and determines that it contains a
   single UAS-Authenticate header targeted solely at itself, it MAY
   resubmit the request to the UAS with a UAS-Authorization header
   containing the credential as a separate branch.

I don't think this is possible because the Cseq number must be increased
(otherwise it will look like a re-transmission or merged request) and the
proxy does not own the CSeq. It would have to be a B2BUA and generate its
own Cseq (and possibly Call-Id).

cheers,
(-:bob

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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Jo Hornsby" <[email-masked]>
Date: Tue, 19 Mar 2002 21:56:20 -0000

> I don't think this is possible because the Cseq number must
> be increased (otherwise it will look like a re-transmission
> or merged request) and the proxy does not own the CSeq. It
> would have to be a B2BUA and generate its own Cseq (and
> possibly Call-Id).

Actually, I think this may be fine.  Section 8.2.2.2 of
RFC3261^H^H^H^H^H^H^Hbis-09 only puts a SHOULD strength
on a 482, and thus I see no reason for clever UAs to
not look out for resubmitted requests (i.e., those that
are only different based on the topmost-Via), such that
they can attempt to resatisfy the request based on
the condition that the previous N-instances of this
request were all treated to a non-2xx final.

I thought that there had been some mention of this in
Session Timer (because there are cases where a UAS
can receive a request N times; along (N - 1) paths the
refresh interval is too small, but along one path,
it is acceptable; if the acceptable path "arrives"
last, not treating it as a merge avoids RTTs in
negotiation, which may not even occur if UPDATE is
not supported).  But a quick skim failed to turn
anything up.  However, there was definitely a mailing-
list thread that ultimately produced the new merge
behaviour.

Furthermore, a similar approach is suggested in
update-01 Section 7, when a proxy does the
Require:update thing.  Now, I expect this to become
less common, based on the proposed resolution of
a UAS sending a 155 being SHOULD; however, it
does seem to me that it would be a shame to rule
it out, since I can see very little that's -ve
about it beyond a slight bit of extra logic in
the "UAS core".

 - Jo.