Subject: RE: [Sip] RE: [Sipping] RE: [Sip-implementors] 4xx by stateless p roxy

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 7 Nov 2001 15:46:48 -0500

> -----Original Message-----
> From: Vijay Gurbani [mailto:[email-masked]]
> Sent: Tuesday, November 06, 2001 10:22 AM
> To: Jonathan Rosenberg
> Cc: Dorgham Sisalem; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [Sip] RE: [Sipping] RE: [Sip-implementors] 4xx 
> by stateless
> proxy
> 
> > Thats true, but there are two ways to reliably send the 
> response. One is 
> > to retransmit it until ACK, and the other is to retransmit 
> the response on
> > retransmissions of the request. If a server does not send a 
> 1xx response 
> > to a request, the client will continue to retransmit the 
> request, and this 
> > can cause retransmissions of the response. In this case, 
> the ACK is not
> > critical, and a server that knows its always a redirect 
> server can "eat"
> > both the ACK and the CANCEL (of course it would need to 
> respond to the
> > CANCEL with a 2xx).
> 
> Jonathan:
> 
> I respectfully submit that this behavior will lead to 
> ambiguity and more 
> interop nightmares! 
> 
> Since the dawn of SIP time, connection-less transports have 
> had 2 ways to 
> deal with SIP response reliability: the INVITE way and the 
> non-INVITE way.  
> 
> As you are well aware, what you describe above is how 
> response reliability 
> is specified for non-INVITE methods (basically, resend final 
> response every 
> time the request arrives).  To now say that for redirection, 
> responses to 
> the INVITE should have the same behavior as those for 
> non-INVITEs will open 
> up a can of worms.

No, thats not what I'm saying. I am saying that it is possible, without any
change to the protocols and without knowledge of the client transaction, for
a server to generate stateless responses. Something which works without
protocol changes and without knowledge of the peer is always possible
whether I specify it or not. Thus, this still remains the out-of-the-box
INVITE transaction as far as the client is concerned, and we have total
interoperability. 

The issue here is that the spec ALREADY talks about statelessly responding,
as a means to avoid DoS attacks. So, we can either leave it at that, or
provide more details on an implementation mechanism that I think is quite
helpful.

> 
> > THe notion of a "stateless uas", which is what this is, is not well
> > documented in bis-05. I am not sure how much we want to say 
> about it, as 
> > it is effectively an implementation decision that can be 
> made, rather than 
> > a new protocol element. However, since doing stateless 
> responding is 
> > important for security (and we do mention that), it might 
> be worth giving 
> > more guidance than is there now.
> 
> It is better to have a tacit understanding that redirect 
> servers may "eat"
> up the ACK -- even though I really do not like this behavior 
> -- so that from 
> a UAC's point of view, the INVITE/3xx/ACK completes a 
> transaction. 

That was my proposal. You always have to send the ACK, period.

 If 
> instead, you spell this behavior in the spec, we will run 
> into interop 
> nightmares because invariably there will be an UAC 
> implementation that deems 
> the ACK optional for 2xx responses as well.  

That is not what I am proposing. Since the client has no way to know whether
the next hop is statelessly or statefully responding (but suffering losses),
you have to send the ACK since you can't know whether it will work without
it.

Christer's proposal, however, is to make a protocol change to avoid the ACK.
That, to me, is a recipe for interop nightmares. I do not want another state
machine definition; I want to document an implementation improvement (which
is needed for UAS in general) within the scope of the defined INVITE
transactions.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  http://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: Christer Holmberg <[email-masked]>
Date: Thu, 08 Nov 2001 08:18:35 +0200

Hi,

>is needed for UAS in general) within the scope of the defined INVITE

Just to clarify: I do NOT want to make a protocol change.

What I said was that if this other stateless redirection proposal is
implemented there would be no need for the ACK, and that I see no reason
in having a protocol where you send useless messages that will simply be
"eaten". Then I wrote how the ACK change would affect the client state
machine - and compared it to how stateless redirection would affect the
server state machine.

My point was, that the ONLY case where the stateless redirection would
simplify the state machine is when the node ALWAYS send 3xx final
responses, and NEVER sends 1xx provisional responses. From my point of
view it was never about backward compability or interop problems -
simply about how much it would really gain the protocol.

Also, to my understanding the original idea of stateless final responses
was to prevent DoS attacks to allocate state/resources in a server.
However, since the INVITE can be authenticated, the stateless redirect
proposal doesn't affect that. OF COURSE, if you want to be able to send
3xx responess to non-INVITE requests we have another story, but I don't
think that's the reason for the change either, is it?

So, again: I am very happy with how INVITE transactions work today, and
I do NOT want to change those, since they work fine. For the moment I
think we should concentrate on what does NOT yet work (the bis is full
of open issues).

Regards,

Christer Holmberg
Ericsson Finland