Subject: RE: [Sip] Re: issue with oubound and the used transport protocol

From: Jeroen Van Bemmel <[email-masked]>
Date: Thu, 30 Nov 2006 17:02:27 +0100

Having implemented STUN over TCP/TLS I can now say that it does add significant complexity while providing little benefit over CRLF

STUN allows one to detect NAT reboot, but a CRLF will also trigger a connection reset in such a case. STUN breaks framing in case the other side does not support it. It uses significantly more bandwidth than CRLF. It requires a lot of text to describe.

In summary, I support CRLF for TCP, and would suggest to do STUN only for UDP (i.e. its original purpose). STUN for TCP is a bad idea

Regards,
Jeroen

PS Edge proxy choosing the mechanism: not a good idea either, better to simply define 1 mechanism (STUN for UDP, CRLF for TCP)

-----Oorspronkelijk bericht -----
Van: "Christer Holmberg (JO/LMF)" <[email-masked]>
Aan: "Rohan Mahy" <[email-masked]>; [email-masked]
CC: [email-masked]; [email-masked]
Verzonden: 30-11-06 13:56
Onderwerp: RE: [Sip] Re: issue with oubound and the used transport protocol

Hi,

Why don't we let the edge proxy choose which keep-alive mechanism to
use?

The outbound spec should now say (I haven't had time to check, but I
hope me and Rohan agreed to add it :) that the edge proxy can insert the
keepalive parameter in the Path header.

So, we define a "CRLF" value for the parameter, and the edge proxy can
then use that value for TCP flows.

Of course, if the UA is not mandated to implement all kind of
keep-alives, it will also have to be able to indicate to the edge proxy
which keep-alive mechanisms it support.

Regards,

Christer

_______________________________________________
Sip mailing list  https://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: "Francois Audet" <[email-masked]>
Date: Thu, 30 Nov 2006 11:45:02 -0600

Didn't we agree way back NOT to use PING, CRLF, etc., and use STUN
instead?

Why is this debate being re-opened?

Remember: I favored the non-STUN TCP approach. However, if we can't
stick to a decision,
we'll debate this forever. It already feels like it.

> -----Original Message-----
> From: Jeroen Van Bemmel [mailto:[email-masked]] 
> Sent: Thursday, November 30, 2006 08:02
> To: Christer Holmberg (JO/LMF); Rohan Mahy; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Sip] Re: issue with oubound and the used 
> transport protocol
> 
> Having implemented STUN over TCP/TLS I can now say that it 
> does add significant complexity while providing little 
> benefit over CRLF
> 
> STUN allows one to detect NAT reboot, but a CRLF will also 
> trigger a connection reset in such a case. STUN breaks 
> framing in case the other side does not support it. It uses 
> significantly more bandwidth than CRLF. It requires a lot of 
> text to describe.
> 
> In summary, I support CRLF for TCP, and would suggest to do 
> STUN only for UDP (i.e. its original purpose). STUN for TCP 
> is a bad idea
> 
> Regards,
> Jeroen
> 
> PS Edge proxy choosing the mechanism: not a good idea either, 
> better to simply define 1 mechanism (STUN for UDP, CRLF for TCP)
> 
> Why don't we let the edge proxy choose which keep-alive 
> mechanism to use?
> 
> The outbound spec should now say (I haven't had time to 
> check, but I hope me and Rohan agreed to add it :) that the 
> edge proxy can insert the keepalive parameter in the Path header.
> 
> So, we define a "CRLF" value for the parameter, and the edge 
> proxy can then use that value for TCP flows.
> 
> keep-alives, it will also have to be able to indicate to the 
> edge proxy which keep-alive mechanisms it support.
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
>  
> 
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Fredrik Thulin <[email-masked]>
Date: Thu, 30 Nov 2006 19:21:27 +0100

> Why is this debate being re-opened?

Because it seems more and more (to me at least) that Outbound with UDP 
will just suck.

If Outbound UA's have to get their act together and implement TLS/TCP, 
then we can simplify Outbound even further by skipping the whole STUN 
keepalive thing, and go with CRLF over TLS/TCP.

I am very much in favor of cutting both UDP and STUN keepalives out of 
Outbound. I think that would lead to faster deployment, and also make 
the world a better place by eliminating some SIP over UDP.

/Fredrik

PS. By the way, when people say CRLF keepalives, do you mean CRLF sent 
only from the UA, or CRLF from UA to edge proxy followed by CRLF in the 
reverse direction too?

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 30 Nov 2006 13:37:40 -0600

Just to be clear what my opinion is...

I agree with you that using CRLF with TCP would
be a lot cleaner and easier to implement. It would really make
the UDP-with-STUN alternative a moot point.

That combined with people moving to TLS/TCP for security 
reasons in my opinion means that having focused our energies on
a solution optimized for UDP was a big mistake.

The consequence is the plethora of mechanisms that people are
using today: PING, OPTIONS, CRLF, REGISTER, etc.

But in my opinion, getting the document finalized should be the
ultimate priority.

> From: Fredrik Thulin [mailto:[email-masked]] 
> Sent: Thursday, November 30, 2006 10:21
> To: Audet, Francois (SC100:3055)
> Subject: Re: [Sip] Re: issue with oubound and the used 
> transport protocol
> 
> Francois Audet wrote:
> Because it seems more and more (to me at least) that Outbound 
> with UDP will just suck.
> 
> If Outbound UA's have to get their act together and implement 
> TLS/TCP, then we can simplify Outbound even further by 
> skipping the whole STUN keepalive thing, and go with CRLF 
> over TLS/TCP.
> 
> I am very much in favor of cutting both UDP and STUN 
> keepalives out of Outbound. I think that would lead to faster 
> deployment, and also make the world a better place by 
> eliminating some SIP over UDP.
> 
> /Fredrik
> 
> PS. By the way, when people say CRLF keepalives, do you mean 
> CRLF sent only from the UA, or CRLF from UA to edge proxy 
> followed by CRLF in the reverse direction too?
> 
> 
>

---

From: "Frank W. Miller" <[email-masked]>
Date: Thu, 30 Nov 2006 13:41:20 -0700

As an aside, the draft draft-fwmiller-ping-03 has expired.  While the draft
is still available at http://www.cornfed.com/ping.html and
http://www.cornfed.com/ping.txt, the question is whether it should be
resubmitted?  If there is no interest in it, I'll let it die on the IETF
site.

Thanks,
FM

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 30 Nov 2006 22:06:04 +0100

Hi, 

>eliminating some SIP over UDP.

We have to remember that outbound can now also be used in no-NAT
scenarios, in order to support multiple simultanous registrations, in
which case keep-alives aren't needed in the first place.

Just to keep in mind.

Regards,

Christer

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 30 Nov 2006 22:22:05 +0100

Hi,

A question for clarification:

The STUN response provides the UA with certain useful information
(XOR-ADDRESS etc), which the UA can use to see whether a NAT has
rebooted etc. I assume that information is not needed when using TCP?

Regards,

Christer

> Sent: 30. marraskuuta 2006 19:45
> To: [email-masked]
> Cc: [email-masked]
> Didn't we agree way back NOT to use PING, CRLF, etc., and use 
> STUN instead?
> 
> Remember: I favored the non-STUN TCP approach. However, if we 
> can't stick to a decision, we'll debate this forever. It 
> already feels like it.
> 
> > Having implemented STUN over TCP/TLS I can now say that it does add 
> > significant complexity while providing little benefit over CRLF
> > 
> trigger a 
> > connection reset in such a case. STUN breaks framing in 
> case the other 
> > side does not support it. It uses significantly more bandwidth than 
> > CRLF. It requires a lot of text to describe.
> > 
> STUN only 
> > for UDP (i.e. its original purpose). STUN for TCP is a bad idea
> > 
> > Regards,
> > Jeroen
> > 
> > PS Edge proxy choosing the mechanism: not a good idea 
> either, better 
> > to simply define 1 mechanism (STUN for UDP, CRLF for TCP)
> > 
> mechanism to 
> check, but I 
> > hope me and Rohan agreed to add it :) that the edge proxy 
> can insert 
> > the keepalive parameter in the Path header.
> > 
> > keep-alives, it will also have to be able to indicate to the edge 
> > proxy which keep-alive mechanisms it support.
> > 
> > Regards,
> > 
> > Christer
> > 
> > 
> > 
> > 
> >  
> > 
> > 
> > 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> > 
>

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 30 Nov 2006 22:34:21 +0100

I still need to test this, but I suspect that the STUN response won't even 
arrive over TCP when the NAT has rebooted and uses a different source port 
for forwarding it. The server then cannot match it with an existing 5-tuple 
socket connection and will probably send a RST

Regards,
Jeroen

Christer Holmberg (JO/LMF) wrote:
>>> To: Christer Holmberg (JO/LMF); Rohan Mahy;
>>> [email-masked] Cc: [email-masked]; [email-masked]

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 30 Nov 2006 22:50:15 +0100

Hi, 

>I still need to test this, but I suspect that the STUN 
>response won't even arrive over TCP when the NAT has rebooted 
>and uses a different source port for forwarding it. The 
>server then cannot mng the 
> whole STUN 
> keepalives out of 
> > only from the UA, or CRLF from UA to edge proxy followed by CRLF in 
> > the reverse direction too?
> > 
> > 
> >

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 30 Nov 2006 22:50:15 +0100

Hi, 

>server then cannot match it with an existing 5-tuple socket 
>connection and will probably send a RST

Maybe I missunderstood, but won't the STUN request create a new binding,
in case the NAT has rebooted?

Regards,

Christer

> >> stick to a decision, we'll debate this forever. It already 
> feels like 
> >> it.
> >>
> >>> Onderwerp: RE: [Sip] Re: issue with oubound and the used 
> transport 
> >>> protocol
> >>>
> >>>
> >>> Hi,
> >>>
> >> [email-masked] for new devatch it with an existing 5-tuple socket 
>connection and will probably send a RST

Maybe I missunderstood, but won't the STUN request create a new binding,
in case the NAT has rebooted?

Regards,

Christer

> >> stick to a decision, we'll debate this forever. It already 
> feels like 
> >> it.
> >>
> >>> Onderwerp: RE: [Sip] Re: issue with oubound and the used 
> transport 
> >>> protocol
> >>>
> >>>
> >>> Hi,
> >>>

elopments on the application of sip

---

From: "Rohan Mahy" <[email-masked]>
Date: Thu, 30 Nov 2006 15:16:06 -0800

Hi Christer,

A NAT won't create a new TCP binding unless it sees a SYN.  If the NAT
reboots, the client will detect that the connection has died, and
won't be able to send any traffic (SIP or STUN) until it opens a new
connection explicitly.  An XOR-MAPPED-ADDRESS attribute over TCP is
completely useless.

thanks,
-rohan