Document: draft-sparks-sip-nit-problems-02.txt (reviewed in parallel with draft-sparks-sip-nit-actions-03.txt which proposes changes to RFC3261 to counter the problems identified). Trigger: IETF last call, 10 March 2005 Reviewer: Elwyn Davies AD: Allison Mankin Review Date: 17 March 2005 Intended status: Informational Summary: A good analysis of timing problems with the SIP non-INVITE transaction but not quite ready for RFC status due to: - Informal wording in various sections not bringing out the true problems to best effect (especially in s1.3 and maybe also in s1.6 - see meta-question below). A one sentence summary of the problem at the top of each problem section would also help the reader to see where the argument was going. - Mismatch between intentions expressed in Security Considerations (to highlight potential security vulnerabilities resulting from the problems) and a complete lack of such highlighting in the problem analysis. Meta-question: This draft addresses problems with non-INVITE transactions but notes in s1.6 that configuring nodes involved in other sorts of transaction with different values for the T1 and T2 timeouts can lead to (unspecified) problems: has this problem been addressed elsewhere? The implication of the final sentence of s1.6 is that using anything but the default values is inviting(sic) disaster for SIP! Is SIP *really* that unstable?? Review: The draft is a good analysis of a set of problems deriving from the fixed upper bound on the lifetime of SIP non-INVITE client transactions, and the corresponding (but not necessarily equal) bound on the lifetime of the matching server transaction. Network delays and unmatched configurations can lead to race conditions, especially when using unreliable transports. Consequently this material should IMO be published, but the current draft needs another round of polishing before publication, for the following reasons: - The wording in some of the analysis is rather informal (especially the discussion of 'miserable failure' in s1.3) which would make it difficult for non-English speakers to appreciate the real problems and actually makes it difficult to see what the actual problem is. S1.6 also has some draconian words that may need additional justification. - The Security Considerations (s2) assert that the draft 'mentions' potential security vulnerabilities. As far as I can see this is not currently the case, although thinking about the problems mentioned, it looks as if some security issues could well arise as a result of the problems (DoS attacks seem possible). Either the security considerations should be revised or the security vulnerabilities that actually arise or are exacerbated should be highlighted (clearly the latter is to be preferred). Also, section 1.6 (which discusses the effects of mismatched timer configurations) makes some assertions about the need for consistent configuration of timer values beyond possible exacerbation of the problems with non-INVITE (' There are many failure scenarios due to misconfiguration or misbehavior that the SIP specification does not discuss... ...exceptional care must be taken when deploying systems with non-defaults to ensure they will _never_ directly communicate with elements with default values.') These statements are fairly draconian and significantly extend the scope of the draft beyond its stated aims. I am not sure what is best to do about this.. if it is true and has not been mentioned elsewhere, it needs further discussion but maybe in a separate draft. If it isn't true then the section needs rewriting. There are also a number of nits and editorial corrections that should be fixed: - Understanding the draft needs knowledge of some items from the main SIP RFC3261. Words to the effect that definitions of terms can be found in RFC3261 would be useful. In particular it would be helpful to copy the definition of T1, since it is fundamental to the discussion, (T1 is an estimate of the round- trip time (RTT)) into the draft. Also various error/success messages are quoted by number or number range rather than title (as is all too common in SIP documents (grump)): It would help less savvy readers if these magic numbers were translated into near-English at least once, e.g.: - s1.4: 408 = Request Timeout - S1.5: 401 = Unauthorised - various places: 2xx - The Capitalization of Section Titles does Not Adhere to Convention especially in section 1. - In section 1, a one sentence outline of each problem (consonant with the title of the section) would help readers to see where the section is going. S1.1: I am not sure I like the phrase 'risk losing a race': The phrase has implications of 'race conditions' and whilst the problem has to with the order in which the client NIT transaction timeout and reception of server responses occur, it is not about them occurring at nearly the same instant. The problem is more to do with network delays and asynchronicity between client and server: there is no way to determine what is the latest time when the server can send a response that will be accepted by the client. Maybe 'NITs must complete immediately since Server cannot Compute Consistent Timeout' or just 'Impossibility of Achieving Consistent Timeouts for NITs on Client and Server'. S1.3: 2nd para (1st bullet): s/timeout will indicates/timeout will indicate/ S1.3: Use of 'miserable': The informal usage of 'fails miserably' conceals some sloppy drafting and does not bring out what is really going on. Non-mother tongue English speakers are likely to have difficulty understanding this usage. '... the intended availability mechanism fails miserably' could be better expressed as 'the intended resilience mechanism will be subverted', and further on 'Since miserable failure is not acceptable in deployed networks,...' would be better as 'This kind of deviation from the intended resilient functionality is extremely undesirable in practice, so...'. S1.4: '408 for non-INVITE is *not useful*': How is it not useful? This sort of title is not useful either! Also I suspect this is one of the sections that has a lurking security vulnerability to be documented. S1.5: 'forking' is a piece of jargon that probably needs to be explained for the less SIP-aware reader. Personally I thought the author was casting euphemistic nasturtiums on the whole concept of proxies! The use of 'doom' is also suitably apocalyptic, but the limits of the failure could be clarified a little. [Maybe the author of the draft has been reading 'Cold Comfort Farm' (Stella Gibbons) recently: 'Miserable sinners! Ye are all doomed!' - I just hope this isn't a commentary on SIP or IP in general! Maybe we should instigate an additional session on IETF Meeting Sundays - a meeting of the Church of the Quivering Brethren where drafts like this will be read out (in full)... sorry, got a little carried away there ;-)]