I agree with your responses although it would be nice to have say a configuration option like "Replay Attack Protection" or similar which turned on/off the validation rules currently used. I guess it's just an issue I came across with two SIP UAs and a commercial SBC. My use of SIPXecs is atypical dealing more with service provider/consumer SIP implementations and requiring interoperability with a wide range of these types of devices, so I have no idea how big of an issue it is for normal users of SIPXecs (which I'd imagine would typically be business users with a far more static, closed set of requirements).
Of course if it's not a major issue for the rest of your users, then it's better to spend more time fixing other issues or developing new features. FYI Cisco released to me an engineering special image for the SBC on the ASR 1000 which resolved the issue - i.e. the SBC now maintains the same tag parameter in subsequent authentication retries...the formal release that will have this fix will be around May 2010...note that this is the Service Provider version of the SBC, not the Enterprise version (commonly referred to as CUBE) - I have no idea whether CUBE Enterprise has this same interoperability issue. On Wed, Jan 6, 2010 at 1:33 AM, Scott Lawrence <scottlawr...@avaya.com>wrote: > On Thu, 2009-12-10 at 13:11 +1300, Justin Menga wrote: > > > I've come across interop issues with various SIP UAs and now a > > commercial SBC (Cisco ASR 1000 Series SBC SP Edition) and SIPXecs, > > which stems from the SIPXecs use of the "Tag" parameter in the "From" > > Header for generating nonce values for SIP digest authentication. > > > > Basically the position of SIP Foundry is as follows (quoted from > > http://interop.sipxecs.org/): > > > > "The authentication nonces provided by sipX are specific to the > > from-tag in the request. Section 8.1.3.5 of RFC 3261 requires that a > > re-sent request has the same from-tag as the original request, so the > > nonce that sipX returns in a 401/407 response can always be used in a > > re-send of the request. However, some UAs will incorrectly use a > > different from-tag when resending a REGISTER. These UAs will not be > > able to register." > > > > This is what Section 8.3.1.5 of RFC actually states: > > > > "In all of the above cases, the request is retried by creating a new > > request with the appropriate modifications. This new request > > constitutes a new transaction and SHOULD have the same value of the > > Call-ID, To, and From of the previous request, but the CSeq should > > contain a new sequence number that is one higher than the previous." > > > > The key word above being "SHOULD" - i.e. it is not a requirement but a > > recommendation. > > That's not what SHOULD means when used in an RFC. RFC 2119 defines > SHOULD: > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. > > In this case, the full implications include the fact that it won't work > when the server is taking a conservative approach to protecting against > replay attacks. > > > Also, a relevant draft IETF report is located at > > > http://ietfreport.isoc.org/all-ids/draft-smith-sipping-auth-examples-01.txt-48149.txt- > in here Section 2.3 addresses specifically the issue of interoperability > failures related to nonce invalidation, although I'm not sure if SIP > registration is considered a dialog-creating request: > > SIP registration is explicitly not a dialog-creating request, but the > same rules for retries for authentication apply. > > That is a draft that expired almost 5 years ago. It never did have any > authority as a reference - see the boilerplate at the top of that (and > every other) I-D: > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > > >
_______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
