On Mar 21, 2009, at 7:59 AM, Jonathan Rosenberg wrote:
Thanks, Robert. Comments below:
It modifies state transitions in the INVITE server state
machine to absorb retransmissions of the INVITE request after
encountering a unrecoverable transport error when sending a
response.
this little tidbit is not mentioned in section 3, whereas the other
parts of this section (section 4) are mentioned. I think a paragraph
describing this error is appropriate.
Edit-itis. I will add such a paragraph.
Implementations strictly conformant to [RFC3261] will process
retransmitted initial INVITE requests as new requests. Proxies may
forward them to different locations than the original. Proxies may
also be used as anonymizing forwarders of bulk traffic.
should mention the consequences of not addressing this transport-
error issue in my comment above.
ok
7.1. UAS Impacts
To allow a UAS to recognize retransmissions of an INVITE as
retransmissions instead of new requests, a new state, "Accepted",
is
added to the INVITE server transaction state machine.
this change is not JUST for a UAS - its also for proxies
implementing the server transaction machine, right? Is there a
reason this is worded for UAS?
Hmm. I'm going to have to go read this through fairly carefully again.
The change is to the client and server transaction state machines. It
may be that the
prose started to erroneously use UAC and UAS as synonyms for those
state machines. Let me look through it and propose correction.
Timer L reflects the amount of time the TU will wait to
receive an ACK for the 2xx it is emitting before considering the
transaction failed.
but an ACK-200 is not part of this transaction...
Right, the TU is tying those two transactions together. This is the
period of time that the mentioned TU can be handing down 200s for
retransmission.
Given your question, it looks like I should change this motivation
sentence to say that instead?
also, I think its worth at least noting that this change does not
100% solve the problem. If the UAC and any server transaction
between it, and the UAS, use a different value of T1, there can
still be a problem. In particular if the value of T1 at the UAC is
larger than the value at any of the downstream server transactions,
the server transaction may be destroyed while the UAC remains in the
calling state.
I agree (and think there are other places where we should more
strongly point out the pitfalls of changing T1 only in one part of a
system).
Could you propose text for this instance though?
UAC Impacts
In order to correctly distinguish retransmissions of 2xx responses
from stray 2xx responses, the INVITE client state machine is
modified
to not transition immediately to "Terminated" on receipt of a 2xx
response.
as above, this is not specific to UAC and covers proxy/b2b client
transactions too, no?
Proxy Considerations
A direct consequence of the change to the UAC state machine is
that a
transaction-stateful proxy will not foward any stray INVITE
responses.
It is not a consequence of the new state machines - but it is a
change in behavior we are making.
I understand your objection, and think this may be another aspect of
unintentional conflation of UAS/UAC with server and client state
machines. When I propose a correction as mentioned above, I'll capture
this.
Meta-comment: A drawback of this change is that proxies and b2bua
will now hold transaction state for 64*t1 seconds after the
transaction is done, even for calls that set up immediately. In some
implementations this may be a non-trivial increase in memory usage,
and there may be other impacts (for example if an implementation had
a non-optimized transaction matching mechanism which only worked
well with a small number of transaction machines e.g., a linear
search). I think this implication needs to be called out more
strongly. You mention it as a security vulnerability, but its not
just a security issue.
Where in the document would you think such a highlight would have the
best impact?
-Jonathan R.
Robert Sparks wrote:
This got a fairly big touch due to better handling of transport
error conditions. Please review this carefully.
RjS
Begin forwarded message:
*From: *[email protected] <mailto:[email protected]>
*Date: *March 2, 2009 8:45:01 AM CST
*To: *[email protected] <mailto:[email protected]>
*Subject: **I-D Action:draft-sparks-sip-invfix-03.txt *
*Reply-To: *[email protected] <mailto:[email protected]
>
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Correct transaction handling for 200 responses
to Session Initiation Protocol INVITE requests
Author(s) : R. Sparks
Filename : draft-sparks-sip-invfix-03.txt
Pages : 20
Date : 2009-03-02
This document normatively updates RFC 3261, the Session Initiation
Protocol (SIP), to address an error in the specified handling of
success (200 class) responses to INVITE requests. Elements
following
RFC 3261 exactly will misidentify retransmissions of the request
as a
new, unassociated, request. The correction involves modifying the
INVITE transaction state machines. The correction also changes the
way responses that cannot be matched to an existing transaction are
handled to address a security risk.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sparks-sip-invfix-03.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
------------------------------------------------------------------------
_______________________________________________
I-D-Announce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
------------------------------------------------------------------------
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip
--
Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South
Cisco Fellow Iselin, NJ 08830
Cisco, Voice Technology Group
[email protected]
http://www.jdrosen.net PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip
