Subject: [Sip] Fwd: I-D Action:draft-sparks-sip-invfix-03.txt

From: Robert Sparks <[email-masked]>
Date: Mon, 2 Mar 2009 14:20:08 -0600

This got a fairly big touch due to better handling of transport error  
conditions. Please review this carefully.

RjS

Begin forwarded message:

> From: [email-masked]
> Date: March 2, 2009 8:45:01 AM CST
> To: [email-masked]
> Subject: I-D Action:draft-sparks-sip-invfix-03.txt
> Reply-To: [email-masked]
>
> 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-masked]
> 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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 21 Mar 2009 10:59:17 -0400

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.

> 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.

> 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?

> 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...

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.

> 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.

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.

-Jonathan R.

Robert Sparks wrote:
>> *From: [email-masked] <mailto:[email-masked]>
>> *Date: *March 2, 2009 8:45:01 AM CST
>> *To: [email-masked] <mailto:[email-masked]>
>> *Subject: **I-D Action:draft-sparks-sip-invfix-03.txt *
>> *Reply-To: [email-masked] <mailto:[email-masked]>
>>
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------
> 
> Sip mailing list  https://www.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

-- 
Jonathan D. Rosenberg, Ph.D.                   111 Wood Avenue South
Cisco Fellow                                   Iselin, NJ 08830
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

---

From: Robert Sparks <[email-masked]>
Date: Sat, 21 Mar 2009 08:51:47 -0700

> describing this error is appropriate.

Edit-itis. I will add such a paragraph.
> should mention the consequences of not addressing this transport- 
> error issue in my comment above.

ok

> 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.

> 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?

> 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:
>>> *Reply-To: [email-masked] <mailto:[email-masked] 
>>> >
>>>
>>> Title           : Correct transaction handling for 200 responses  
>>> to Session Initiation Protocol INVITE requests
>>> Author(s)       : R. Sparks