Subject: [Sip] Outbound Issues: slides 3 and 4

From: Rohan Mahy <[email-masked]>
Date: Tue, 8 Aug 2006 07:38:52 -0700

We had a very long discussion in Montreal about discovery and 
validation of a SIP outbound proxy server's ability to receive STUN 
requests.  While the vast majority of the room was comfortable that 
"keepalive=stun" in a URI was a sufficient indicator that an outbound 
proxy supports SIP and STUN over the same port, a small but extremely 
vocal minority had significant problems with this assumption.  After a 
discussion with Dean, I am willing to try a validation proposal which 
adds no extra round trips if the SIP UA was indeed correctly 
configured.

The specific proposal works like this.  A UAC which has an outbound URI 
indicating with ;keepalive=stun that the next hop can support STUN 
messages on the SIP port, needs to verify the first hop supports STUN 
before sending any STUN messages. The UAC sends its first SIP message 
to the next hop with a Proxy-Require: sip-stun.  If the URI was correct 
(STUN was supported), and the first-hop is an intermediary, the 
first-hop removes the Proxy-Require and forwards the SIP request 
(probably a REGISTER request) along adding no additional delay.  A 
positive response to a REGISTER or OPTIONS with Supported: outbound and 
no error counts as positive confirmation that either the registrar 
supports STUN or expects to never receive a request without getting it 
from an outbound proxy which did not complain about the Proxy-Require 
[1]. If the UAC was misconfigured (the first-hop intermediary does not 
support STUN keepalives), either the first hop will reject the SIP 
request (if it is an intermediary), or the registrar will not include 
an indicator that it supports outbound (if the first hop was the 
registrar).

Note that this proposal is not a full *discovery* mechanism, just a 
verification mechanism.  For example, if the registrar doesn't support 
outbound, but the first-hop does, there is no way described here to 
discover that the first-hop can accept STUN keepalives.  Do not confuse 
support of STUN with support of outbound.  Supported: outbound implies 
that the registrar supports STUN or is configured to use an outbound 
proxy that does.  The sip-stun option tag only means that you can send 
and receive STUN requests on your SIP port. While outbound requires 
STUN, STUN does not require outbound.

[1] Also Note that there is a caveat that you can still shoot yourself 
in the foot if you allow messages to come straight to your registrar 
that does not support STUN.  I think we agreed that we are not going to 
enumerate all the ways you can subtly break things in SIP though.

thanks,
-rohan

_______________________________________________
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: Tue, 8 Aug 2006 13:46:33 -0500

Rohan,

I really like the idea of decoupling sip-stun support, versus
outbound support.

But I'm findind the description quite complicated...

I'm also wondering if the ";keep-alive=stun" is still useful with the 
addition of the Proxy-Require: sip-stun. It doesn't seem 
to me that it is, except as an automatic configuration option for the
UAC.
Since the UAC certainly requires much more configuration options (with 
config-framework, or config files or whatever), I'm not sure it is worth
the
effort. I don't see why this one in particular is more important than
any other.

Let me try to paraphrase what you are saying, to make sure I understood
it properly:

- "Proxy-require: sip-stun" means that the outbound proxy is required to
support
   sip-stun, i.e., the procedures of section 3.5. A consequence of this
is that
   it precludes deployments where the sip-stun is supported not in the
first hop,
   but later (e.g., the Registrar), but with some other intermedia proxy
between.

- "Supported: outbound" means that the Registrar supports the procedures
of the
  draft that are not related to sip-stun.

- ";keep-alive=stun" is an indication for the UAC that stun-in-sip is
supported
  by the network. Essentially an autoconfiguration option.

We have been using terms like "edge proxy", "outbound proxy" now "first
hop", 
and "intermediary".

To me, it seems that there are only two entities that are relevant here:

1 - The outbound proxy. This is where all requests are sent, and the
entity that
    terminates sip-in-stun.

2 - The Registrar. Also the entity that supports the "Outbound"
procedures (excluding
    stun-in-sip).

A very common scenario is where 1 & 2 are co-located. In this case the
Registrar is
the oubound-proxy and it does terminate sip-stun.

Also, I don't understand why your point [1] is a problem. Wouldn't a
Registrar
that doesn't support stun-sip, but which is accesses directly (i.e., as
an outbound
proxy) just reject the REGISTER because it contained "Proxy-Require:
stun-sip" with 
420 with "Unsupported: stun-sip"?

Are you worried that such a REGISTRAR may not believe the Proxy-Require
was intended for
itself?

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]] 
> Sent: Tuesday, August 08, 2006 7:39 AM
> To: IETF SIP List
> Cc: Rohan Mahy
> Subject: [Sip] Outbound Issues: slides 3 and 4
> 
> 
> validation of a SIP outbound proxy server's ability to 
> receive STUN requests.  While the vast majority of the room 
> was comfortable that "keepalive=stun" in a URI was a 
> sufficient indicator that an outbound proxy supports SIP and 
> STUN over the same port, a small but extremely vocal minority 
> had significant problems with this assumption.  After a 
> discussion with Dean, I am willing to try a validation 
> proposal which adds no extra round trips if the SIP UA was 
> indeed correctly configured.
> 
> The specific proposal works like this.  A UAC which has an 
> outbound URI indicating with ;keepalive=stun that the next 
> hop can support STUN messages on the SIP port, needs to 
> verify the first hop supports STUN before sending any STUN 
> messages. The UAC sends its first SIP message to the next hop 
> with a Proxy-Require: sip-stun.  If the URI was correct (STUN 
> was supported), and the first-hop is an intermediary, the 
> first-hop removes the Proxy-Require and forwards the SIP 
> request (probably a REGISTER request) along adding no 
> additional delay.  A positive response to a REGISTER or 
> OPTIONS with Supported: outbound and no error counts as 
> positive confirmation that either the registrar supports STUN 
> or expects to never receive a request without getting it from 
> an outbound proxy which did not complain about the 
> Proxy-Require [1]. If the UAC was misconfigured (the 
> first-hop intermediary does not support STUN keepalives), 
> either the first hop will reject the SIP request (if it is an 
> intermediary), or the registrar will not include an indicator 
> that it supports outbound (if the first hop was the registrar).
> 
> Note that this proposal is not a full *discovery* mechanism, 
> just a verification mechanism.  For example, if the registrar 
> doesn't support outbound, but the first-hop does, there is no 
> way described here to discover that the first-hop can accept 
> STUN keepalives.  Do not confuse support of STUN with support 
> of outbound.  Supported: outbound implies that the registrar 
> supports STUN or is configured to use an outbound proxy that 
> does.  The sip-stun option tag only means that you can send 
> and receive STUN requests on your SIP port. While outbound 
> requires STUN, STUN does not require outbound.
> 
> [1] Also Note that there is a caveat that you can still shoot 
> yourself in the foot if you allow messages to come straight 
> to your registrar that does not support STUN.  I think we 
> agreed that we are not going to enumerate all the ways you 
> can subtly break things in SIP though.
> 
> thanks,
> -rohan
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Dean Willis <[email-masked]>
Date: Tue, 8 Aug 2006 15:02:50 -0500

On Aug 8, 2006, at 9:38 AM, Rohan Mahy wrote:

>
> The specific proposal works like this.  A UAC which has an outbound  
> URI indicating with ;keepalive=stun that the next hop can support  
> STUN messages on the SIP port, needs to verify the first hop  
> supports STUN before sending any STUN messages. The UAC sends its  
> first SIP message to the next hop with a Proxy-Require: sip-stun.   
> If the URI was correct (STUN was supported), and the first-hop is  
> an intermediary, the first-hop removes the Proxy-Require and  
> forwards the SIP request (probably a REGISTER request) along adding  
> no additional delay.  A positive response to a REGISTER or OPTIONS  
> with Supported: outbound and no error counts as positive  
> confirmation that either the registrar supports STUN or expects to  
> never receive a request without getting it from an outbound proxy  
> which did not complain about the Proxy-Require [1]. If the UAC was  
> misconfigured (the first-hop intermediary does not support STUN  
> keepalives), either the first hop will reject the SIP request (if  
> it is an intermediary), or the registrar will not include an  
> indicator that it supports outbound (if the first hop was the  
> registrar).
>

Cullen suggested an alternate possibility that might work.

I'll try and paraphrase:

A UAC which has an outbound URI indicating with ;keepalive=stun that  
the next hop can support STUN messages on the SIP port needs to  
verify the first hop supports STUN before repeatedly sending STUN  
messages.  The UAC may initially try sending STUN messages to the SIP  
port of the first hop node. If the UAC does not receive a correct  
STUN response (within some timer?)  then it must assume that this  
mode does not support STUN, and proceed without using STUN until it  
has some evidence that the first-hop node might have changed, in  
which case it retries the STUN requests as per the initial attempt.

I think it's probably okay to stun a server a few times before  
deciding it doesn't like being stunned -- after all, the primary risk  
is one of slowing down service for the user doing the stunning, not  
shutting down the server being stunned. What I object to is a  
specification that says you go on stunning it indefinitely, perhaps  
millions of times over the course of an association, with no way to  
discover that you really shouldn't be stunning it.

Set phasers on "stun", Mr. Sulu!

--
Dean

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 9 Aug 2006 00:06:45 +0200

Dean,

see inline

Regards,

Jeroen

>> before sending any STUN messages. The UAC sends its  first SIP message to 
>> the next hop with a Proxy-Require: sip-stun.   If the URI was correct 
>> request (if  it is an intermediary), or the registrar will not include an 

Are you suggesting an alternative because there is something wrong with the 
proposal from Rohan above?

For outbound purposes, the UAC won't have a need to send a STUN request 
until it has established a flow (ie upon 200 OK to REGISTER), and then only 
after the interval timer expires (I believe it was something like 24 secs 
minimum for UDP, more for TCP)

Perhaps the case is different for non-outbound STUNning, but if the REGISTER 
OK provides information to determine support, I don't see a need to poke the 
proxy.

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 8 Aug 2006 18:55:05 -0400

Setting phaser to "kill" ;)

Seriously, If the first thing a non-STUN-supporting proxy sees for a new 
connection is a STUN message, It may see it as an attack and tear down the 
connection and possibly black-list the UA.

IMO, the requirement is that the UA be able to verify that the proxy 
supports STUN before it sends a STUN packet.

I am happy with Rohan's proposal.

Now, if I were implementing a UA, I would certainly have it stop STUNing if 
it never saw a STUN response. Maybe the draft should say such to handle the 
case where a UA ends up connecting directly to a non-STUN-supporting 
registrar that thinks it has outbound proxies to handle the STUNing.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
71 Third Avenue
Burlington, MA 01803
[email-masked]

----- Original Message ----- 
From: "Dean Willis" <[email-masked]>
To: "Rohan Mahy" <[email-masked]>
Cc: "IETF SIP List" <[email-masked]>
Sent: Tuesday, August 08, 2006 4:02 PM
Subject: Re: [Sip] Outbound Issues: slides 3 and 4

> A UAC which has an outbound URI indicating with ;keepalive=stun that  the 
> next hop can support STUN messages on the SIP port needs to  verify the 
> first hop supports STUN before repeatedly sending STUN  messages.  The UAC 
> may initially try sending STUN messages to the SIP  port of the first hop 
> node. If the UAC does not receive a correct  STUN response (within some 
> timer?)  then it must assume that this  mode does not support STUN, and 
> proceed without using STUN until it  has some evidence that the first-hop 
> node might have changed, in  which case it retries the STUN requests as 
> per the initial attempt.
>
> I think it's probably okay to stun a server a few times before  deciding 
> it doesn't like being stunned -- after all, the primary risk  is one of 
> slowing down service for the user doing the stunning, not  shutting down 
> the server being stunned. What I object to is a  specification that says 
> you go on stunning it indefinitely, perhaps  millions of times over the 
> course of an association, with no way to  discover that you really 
> shouldn't be stunning it.
>

---

From: Dean Willis <[email-masked]>
Date: Tue, 08 Aug 2006 18:32:07 -0500

Jeroen van Bemmel wrote:

> Are you suggesting an alternative because there is something wrong with 
> the proposal from Rohan above?

The only thing I have seen in Rohan's proposal that makes people queazy 
is the handling of the proxy-require -- that is, removing it in the 
first hop proxy.

To quote a few IETF's back, "That doesn't bother me at all".

But it seems to bother Cullen and a few others, even if I did borrow his 
words to say I'm ok with it.

--
Dean

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 08 Aug 2006 22:19:52 -0400

Personally, I read this as the ";keep-alive=stun" parameter appears 
in the list of outbound prixes.  it needs to be a URI parameter 
because the contents of that list are URIs.
There is no need for that parameter to actually appear in the 
request.  Instead, proxy-require: sip-stun appears, and is removed by 
the first proxy after it determines that it understands and supports 
that.  And if it supports it, then it will know to remove the line, 
so there is no hole where the proxy-require can leak.

Yours,
Joel

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 8 Aug 2006 21:57:52 -0700

>   by the network. Essentially an autoconfiguration option.

yes

> Are you worried that such a REGISTRAR may not believe the Proxy-Require

Exactly.  Proxy-Require is generally supposed to be ignored by UAs.

thanks,
-rohan

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 8 Aug 2006 22:00:54 -0700

On Aug 8, 2006, at 13:02, Dean Willis wrote:
>> STUN messages on the SIP port, needs to verify the first hop supports 
>> STUN before sending any STUN messages. The UAC sends its first SIP 
>> message to the next hop with a Proxy-Require: sip-stun.  If the URI 
>> was correct (STUN was supported), and the first-hop is an 
>> intermediary, the first-hop removes the Proxy-Require and forwards 
>> the SIP request (probably a REGISTER request) along adding no 
>> additional delay.  A positive response to a REGISTER or OPTIONS with 
>> Supported: outbound and no error counts as positive confirmation that 
>> either the registrar supports STUN or expects to never receive a 
>> request without getting it from an outbound proxy which did not 
>> complain about the Proxy-Require [1]. If the UAC was misconfigured 
>> (the first-hop intermediary does not support STUN keepalives), either 
>> the first hop will reject the SIP request (if it is an intermediary), 
>> or the registrar will not include an indicator that it supports 
>> outbound (if the first hop was the registrar).
>>
>
> the next hop can support STUN messages on the SIP port needs to verify 
> the first hop supports STUN before repeatedly sending STUN messages.  
> The UAC may initially try sending STUN messages to the SIP port of the 
> first hop node. If the UAC does not receive a correct STUN response 
> (within some timer?)  then it must assume that this mode does not 
> support STUN, and proceed without using STUN until it has some 
> evidence that the first-hop node might have changed, in which case it 
> retries the STUN requests as per the initial attempt.

I'm personally pretty happy with this, "if it ain't working, don't keep 
doing it approach."
Could others comment if they like the approach or not?

thanks,
-rohan

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 9 Aug 2006 08:35:18 +0200

> Exactly.  Proxy-Require is generally supposed to be ignored by UAs.

Just a note: if the outbound draft defines the 'sip-stun' option tag, it 
should also discuss what it means to add 'Require: sip-stun', and what 
behavior is expected from the UAS in such a case

In particular, I am thinking about non-outbound cases, where a UAC behind 
NAT wants to directly INVITE (or other dialog-creating request) another UA, 
without having a proxy in between. This is also relevant for the end-to-end 
security discussions (ie keeping the TLS connection alive)

Regards,

Jeroen

---

From: Fredrik Thulin <[email-masked]>
Date: Wed, 9 Aug 2006 10:36:43 +0200

On Wednesday 09 August 2006 07:00, Rohan Mahy wrote:
...
> I'm personally pretty happy with this, "if it ain't working, don't
> keep doing it approach."

I am in favor of it, because ultimately there is no way to _know_ that 
the first hop actually handles STUN requests without sending one.

The argument that a response containing something saying "I claim I can 
handle STUN requests you send me" is to be trusted, but configuration 
saying ";keepalive=stun" is not is flawed. The UA will still have to 
send a STUN request, and might or might not receive a response.

It might be worth writing down that if you send a STUN request over a 
TCP session, and don't receive a response then you should tear down the 
TCP session and open a new one in case your peer's framing is messed 
up. On this new TCP session you should of course not send any STUN 
requests.

I consider blacklisting an IP address that sends you one (1) packet you 
consider bad to be too aggressive. I wouldn't use a proxy that did 
that.

/Fredrik

---

From: Hisham Khartabil <[email-masked]>
Date: Wed, 9 Aug 2006 17:03:49 +0200

I don't like this proposal. I'm still with the camp that says: if 
configured, then it must be true.

My main objection is that in this proposal, you are required to send 
SIP messages before STUN messages. That's a mandate that I'm not 
comfortable with since I might want to send STUN first to discover my 
public IP/port to populate the contact header before I send the first 
REGISTER.

Hisham

On Aug 8, 2006, at 4:38 PM, Rohan Mahy wrote:

> URI indicating with ;keepalive=stun that the next hop can support STUN 
> to the next hop with a Proxy-Require: sip-stun.  If the URI was 
> correct (STUN was supported), and the first-hop is an intermediary, 
> the first-hop removes the Proxy-Require and forwards the SIP request 
> positive response to a REGISTER or OPTIONS with Supported: outbound 
> and no error counts as positive confirmation that either the registrar 
> discover that the first-hop can accept STUN keepalives.  Do not 
> confuse support of STUN with support of outbound.  Supported: outbound 
> implies that the registrar supports STUN or is configured to use an 
> outbound proxy that does.  The sip-stun option tag only means that you 
> can send and receive STUN requests on your SIP port. While outbound 
> that does not support STUN.  I think we agreed that we are not going 
> to enumerate all the ways you can subtly break things in SIP though.
>
> thanks,
> -rohan
>
>

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 9 Aug 2006 17:06:59 +0200

Hi, 

>My main objection is that in this proposal, you are required to send
SIP messages before STUN messages. That's a mandate 
>that I'm not comfortable with since I might want to send STUN first to
discover my public IP/port to populate the contact 
>header before I send the first REGISTER.

Is the public IP/port discovery part of the STUN usage for keep-alive?

Regards,

Christer

> [email-masked] for questions on current sip Use 
> [email-masked] for new developments on the application of sip
>

_______________________________________________
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: Hisham Khartabil <[email-masked]>
Date: Wed, 9 Aug 2006 17:09:14 +0200

> discover that you really shouldn't be stunning it.

This is ok. Nothing special here. This is default behaviour anyway even 
if you assume that ;keepalive=stun is true. You need some sort of 
recovery mechanism from misconfiguration. But I think this is an 
implementation issue and not anything normative.

Hisham

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 9 Aug 2006 08:42:23 -0700

Hi Christer,

I think your question is off topic for this thread.  Are you asking 
about "Outbound Issues: slide 7"?

I think the answer to your question is no, but I'm not 100% sure what 
you are asking.

thanks,
-rohan

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 9 Aug 2006 17:44:51 +0200

Hi Rohan,

Isn't STUN usage for IP port/discovery (as mentioned by Hisham) off
topic?

Regards,

Christer 

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]] 
Sent: 9. elokuuta 2006 18:42
To: Christer Holmberg (JO/LMF)
Cc: Hisham Khartabil; Rohan Mahy; IETF SIP List
Subject: Re: [Sip] Outbound Issues: slides 3 and 4 

Hi Christer,

thanks,
-rohan

>> STUN

>> yourself

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 9 Aug 2006 18:45:37 +0200

Hi,

If the UAC wants to make sure that the next-hop proxy (may or may not
support outbound, since STUN keep-alive is a separate function) supports
STUN keep-alive, it can insert a Proxy-Require option-tag.

But, why can't the next-hop proxy, if it supports STUN keep-alive,
insert a Path header with "keepalive=stun"? That would tell the UAC,
when it receives the REGISTER response (assuming it contains the Path
headers) that the proxy supports STUN keepalive. (This would of course
require that the proxy supports Path).

I also think we need to remember that, since STUN keep-alive is now
separated from outbound, the UAC may not have any outbound URIs (as
defined by the outbound draft).

Regards,

Christer

-----Original Message-----
From: Francois Audet [mailto:[email-masked]] 
Sent: 8. elokuuta 2006 21:47
To: Rohan Mahy; IETF SIP List
Subject: RE: [Sip] Outbound Issues: slides 3 and 4

Rohan,

I really like the idea of decoupling sip-stun support, versus outbound
support.

I'm also wondering if the ";keep-alive=stun" is still useful with the
addition of the Proxy-Require: sip-stun. It doesn't seem to me that it
is, except as an automatic configuration option for the UAC.
Since the UAC certainly requires much more configuration options (with
config-framework, or config files or whatever), I'm not sure it is worth
the effort. I don't see why this one in particular is more important
than any other.

We have been using terms like "edge proxy", "outbound proxy" now "first
hop", and "intermediary".

A very common scenario is where 1 & 2 are co-located. In this case the
Registrar is the oubound-proxy and it does terminate sip-stun.

Also, I don't understand why your point [1] is a problem. Wouldn't a
Registrar that doesn't support stun-sip, but which is accesses directly
(i.e., as an outbound
proxy) just reject the REGISTER because it contained "Proxy-Require:
stun-sip" with
420 with "Unsupported: stun-sip"?

was intended for itself?

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 9 Aug 2006 14:08:49 -0400

> From: Fredrik Thulin [mailto:[email-masked]]
> Sent: Wednesday, August 09, 2006 4:37 AM
> To: [email-masked]
> Cc: Rohan Mahy; Dean Willis
> saying ";keepalive=stun" is not is flawed. 

Au contraire.  I would argue fairly vehemently that a server explicitly
indicating it supports something is far more reliable than a UA believing
the server supports something based on a local config setting.  The former
is an explicit indication by the guy who's responsible for doing that
mechanism, whether he can do it or not; the latter is a guess by the client
as to the other side's capabilities.  Certainly the proxy can be wrong, but
that probability is miniscule to the odds that one UA out of a large
population will be wrong.

> The UA will still have to

It sure will.  But if the proxy indicated support for sip-stun, that failure
would only occur if the proxy implementation was broken.  It would not be
used as an active check mechanism.  If the proxy is broken, it's under the
power of the owner of the proxy to fix it.  If the UAs send STUN every-time
they boot-up or re-connect, it is not under the power of the owner of the
proxy to stop them if the proxy cannot explicitly indicate support/not.

> consider bad to be too aggressive. I wouldn't use a proxy that did

It won't be 1 packet.  The UAC will have to retransmit multiple times,
because as far as it knows packet loss happened. (btw, such proxies are
typically highly configurable in how they detect and handle such things)

-hadriel

---

From: "Bob Penfield" <[email-masked]>
Date: Wed, 9 Aug 2006 12:13:13 -0400

I don't think the verification should be required, I just want to have a 
method to verify. That way, a UA that does not have a means to learn the 
outbound proxy set thru auto-config or discovery mechanisms can try to use 
outbound w/STUN. I would make it a MAY for the UA. The procedures for 
handling sip-stun in Proxy-Require/Require would be required for the proxy 
and registrar.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
71 Third Avenue
Burlington, MA 01803
[email-masked]

----- Original Message ----- 
From: "Hisham Khartabil" <[email-masked]>
To: "Rohan Mahy" <[email-masked]>
Cc: "IETF SIP List" <[email-masked]>
Sent: Wednesday, August 09, 2006 11:03 AM
Subject: Re: [Sip] Outbound Issues: slides 3 and 4

> My main objection is that in this proposal, you are required to send SIP 
> messages before STUN messages. That's a mandate that I'm not comfortable 
> with since I might want to send STUN first to discover my public IP/port 
> to populate the contact header before I send the first REGISTER.
>
> Hisham
>
>> We had a very long discussion in Montreal about discovery and validation 
>> of a SIP outbound proxy server's ability to receive STUN requests.  While 
>> the vast majority of the room was comfortable that "keepalive=stun" in a 
>> URI was a sufficient indicator that an outbound proxy supports SIP and 
>> STUN over the same port, a small but extremely vocal minority had 
>> significant problems with this assumption.  After a discussion with Dean, 
>> I am willing to try a validation proposal which adds no extra round trips 
>> if the SIP UA was indeed correctly configured.
>>
>> (STUN was supported), and the first-hop is an intermediary, the first-hop 
>> removes the Proxy-Require and forwards the SIP request (probably a 
>> REGISTER request) along adding no additional delay.  A positive response 
>> to a REGISTER or OPTIONS with Supported: outbound and no error counts as 
>> positive confirmation that either the registrar supports STUN or expects 
>> to never receive a request without getting it from an outbound proxy 
>> keepalives), either the first hop will reject the SIP request (if it is 
>> an intermediary), or the registrar will not include an indicator that it 
>> supports outbound (if the first hop was the registrar).
>>
>> and receive STUN requests on your SIP port. While outbound requires STUN, 
>> STUN does not require outbound.
>>
>> [1] Also Note that there is a caveat that you can still shoot yourself in 
>> the foot if you allow messages to come straight to your registrar that 
>> does not support STUN.  I think we agreed that we are not going to

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 9 Aug 2006 11:49:45 -0700

> the registrar needs to check that the first hop after the UAC is  
> represented in the Path list (unless the registrar recognizes that  
> the first hop after the UAC is in the same domain and doesn't need  
> to include Path URIs with a flow token).  Note that this implies  
> that whatever the proxy puts in the Via (IP address or FQDN), it  
> must put the same hostname in the Path header (but there is no need  
> for a complete URI comparison).  If the first hop is not correctly  
> represented, the registrar ignores the reg-id parameter and does  
> not return Supported: outbound.
>
> The implication of this is that an outbound-proxy that supports  
> outbound needs to support Path and flow tokens for registrations to  
> all foreign domains.  Inside the same domain, the first-hop proxy  
> and the registrar can still use Path to communicate with each  
> other, but they can use some other private mechanism to  
> disaggregate this functionality.
>
> thanks,
> -rohan
>
>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 9 Aug 2006 11:49:45 -0700

On Aug 8, 2006, at 7:38 AM, Rohan Mahy wrote:

> "keepalive=stun" in a URI was a sufficient indicator that an  
> outbound proxy supports SIP and STUN over the same port, a small  
> but extremely vocal minority had significant problems with this  
> assumption.

Just so we are clear on the when this could be a problem....

For any UA that is automatically configured, this is unlikely to  
every be a problem. What we are talking about here is UA where some  
human types in the configuration information to the UA. Even though  
they were told to enter example.com as the outbound proxy, they  
decide to enter example.com;keep-alice=stun because perhaps they saw  
that in some other system. Their device sends a stun packet and gets  
black listed. Note that any services that blacklists after receiving  
a single STUN packet with a spoofed IP address is going to be trivial  
to totally DOS so I don't believe this sort of thing will deploy buts  
let continue down this case. So the user UA does not work. It also  
would not have worked if they typed in elpmaxe.com (example  
backwards). What do they do? read a web page, phone tech support, I  
have no idea but they do whatever they do when they configure the  
outbound proxy information correction. Eventually they find out to  
remove the keep-alive=stun and their phone starts working.

For these reasons, I don't think this whole problem is not a huge  
deal. However, if people do think it is a big deal, the obvious  
solution to it is send and OPTIONS message to find out if the server  
supports this.  Most people don't seem to think this is enough of a  
problem to warrant and additional RTT when a UA boots. We can come up  
with other possible solutions to this too (as there are at least  
three others on this same thread).

The meta question is simple - we had pretty strong consensus on this  
in the meeting. How long do we really want to spend delaying this  
draft to find alternative solutions to this problem. Clearly the  
answer different based on how serious a problem you think it is.

It would be really great if the authors, chairs, and people that feel  
strongly could have a conference call on this.

[email-masked]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

On Aug 8, 2006, at 7:38 AM, Rohan Mahy wrote:

> "keepalive=stun" in a URI was a sufficient indicator that an  
> outbound proxy supports SIP and STUN over the same port, a small  
> but extremely vocal minority had significant problems with this  
> assumption.

Just so we are clear on the when this could be a problem....

For any UA that is automatically configured, this is unlikely to  
every be a problem. What we are talking about here is UA where some  
human types in the configuration information to the UA. Even though  
they were told to enter example.com as the outbound proxy, they  
decide to enter example.com;keep-alice=stun because perhaps they saw  
that in some other system. Their device sends a stun packet and gets  
black listed. Note that any services that blacklists after receiving  
a single STUN packet with a spoofed IP address is going to be trivial  
to totally DOS so I don't believe this sort of thing will deploy buts  
let continue down this case. So the user UA does not work. It also  
would not have worked if they typed in elpmaxe.com (example  
backwards). What do they do? read a web page, phone tech support, I  
have no idea but they do whatever they do when they configure the  
outbound proxy information correction. Eventually they find out to  
remove the keep-alive=stun and their phone starts working.

For these reasons, I don't think this whole problem is not a huge  
deal. However, if people do think it is a big deal, the obvious  
solution to it is send and OPTIONS message to find out if the server  
supports this.  Most people don't seem to think this is enough of a  
problem to warrant and additional RTT when a UA boots. We can come up  
with other possible solutions to this too (as there are at least  
three others on this same thread).

The meta question is simple - we had pretty strong consensus on this  
in the meeting. How long do we really want to spend delaying this  
draft to find alternative solutions to this problem. Clearly the  
answer different based on how serious a problem you think it is.

It would be really great if the authors, chairs, and people that feel  
strongly could have a conference call on this.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 9 Aug 2006 11:50:03 -0700

Adding a bit more at bottom...

On Aug 8, 2006, at 1:02 PM, Dean Willis wrote:

>> outbound URI indicating with ;keepalive=stun that the next hop can  
>> support STUN messages on the SIP port, needs to verify the first  
>> hop supports STUN before sending any STUN messages. The UAC sends  
>> its first SIP message to the next hop with a Proxy-Require: sip- 
>> stun.  If the URI was correct (STUN was supported), and the first- 
>> hop is an intermediary, the first-hop removes the Proxy-Require  
>> and forwards the SIP request (probably a REGISTER request) along  
>> adding no additional delay.  A positive response to a REGISTER or  
>> OPTIONS with Supported: outbound and no error counts as positive  
> A UAC which has an outbound URI indicating with ;keepalive=stun  
> that the next hop can support STUN messages on the SIP port needs  
> to verify the first hop supports STUN before repeatedly sending  
> STUN messages.  The UAC may initially try sending STUN messages to  
> the SIP port of the first hop node. If the UAC does not receive a  
> correct STUN response (within some timer?)  then it must assume  
> that this mode does not support STUN, and proceed without using  
> STUN until it has some evidence that the first-hop node might have  
> changed, in which case it retries the STUN requests as per the  
> initial attempt.
>
> deciding it doesn't like being stunned -- after all, the primary  
> risk is one of slowing down service for the user doing the  
> stunning, not shutting down the server being stunned. What I object  
> to is a specification that says you go on stunning it indefinitely,  
> perhaps millions of times over the course of an association, with  
> no way to discover that you really shouldn't be stunning it.
>

What I was trying to accomplish here was a solution that:

1) you don't send a STUN request until you receive a successful  
response to the register, this lets you know the device you are about  
to send a stun request to is "up"

2) you send a small number of stun requests and if you don't get any  
response, then you conclude that the server does not support stun and  
you stop stunning it

As I mention on another email in this thread, I don't think it will  
be practical to blacklist an IP after a single stun packet so I think  
this solution could probably work.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 9 Aug 2006 11:50:44 -0700

> indicator that it supports outbound (if the first hop was the  

If I am reading 3261 correctly, the proxy would no longer be a proxy  
but a B2BUA. I had proposed this a long time ago and several people  
were very concerned about proxies modifying Proxy-Require headers. By  
the time they were done with me, I shared their concerns about doing  
that. This is a very slippery slope to be diving down if we ever  
expect to have some level of integrity around the only mechanism  
available in SIP for negotiation future forward compatibility with  
proxies.  It would likely work with stuff that is deployed today but  
it is not backwards compatible with things we have specified today.  
An UAS that did AIB would be perfectly correct to reject a response  
that had proxy required where things had been removed.

People bring up some of the 3G security stuff as a example that this  
is ok -  but that was something that was intended for a specific and  
high controlled deployment model. It was also something that has had  
some difficulties so I would hardly use it as an example of why this  
is all alright.

As EKR would say, the important high oder bit here is, regardless of  
if we end up rewriting 3261 to make this change or not, the  
discussion to make the decision is probably not going to be short.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 9 Aug 2006 11:56:22 -0700

Hi Bob,

How about if we said something like

If the UA did not learn the outbound proxy set thru auto-config or  
discovery mechanisms, then it MUST do an OPTIONS message first and  
check for a sip-stun option tag. (clearly more wording needed but you  
know what I mean)

Would that work for you? I suspect it would work for most people. I'd  
certainly be in favor of that. I suspect for proxies with millions of  
users, they will use auto-config so this will not slow them down and  
for proxies with UA with manual config, it will not be enough UA to  
cause a huge performance impact. I don't know why I did not think  of  
this before.

Cullen

On Aug 9, 2006, at 9:13 AM, Bob Penfield wrote:

> I don't think the verification should be required, I just want to  
> have a method to verify. That way, a UA that does not have a means  
> to learn the outbound proxy set thru auto-config or discovery  
> mechanisms can try to use outbound w/STUN. I would make it a MAY  
> for the UA.

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 9 Aug 2006 20:57:09 +0200

Hi, 

>1) you don't send a STUN request until you receive a successful
response to the register, this lets you know the device 
>you are about to send a stun request to is "up"
>
response, then you conclude that the server does not 
>support stun and you stop stunning it
>
>As I mention on another email in this thread, I don't think it will be
practical to blacklist an IP after a single stun 
>packet so I think this solution could probably work.

Why can't the proxy, if it inserts a Path header, add keepalive=stun to
that Path header? Then the UAC does not need to send stun request in
order to figure out whether the proxy supports STUN keepalive or not.

(Of course, if the proxy does NOT support Path then the UAC may have to
figure out by sending STUN requests.)

Regards,

Christer

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 9 Aug 2006 21:07:53 +0200

Hi, 

>>vocal minority had significant problems with this assumption.
>>
>For any UA that is automatically configured, this is unlikely to every
be a problem. 

Assuming the UA is configured with a URI, yes. But, in case the UA only
gets the IP address of the proxy, you still have a problem.

Because, EVEN if you require configured URIs with outbound, you can use
STUN keepalive without outbound.

>What we are talking about here is UA where some human types in the
configuration information to the UA. Even though they 
>were told to enter example.com as the outbound proxy, they decide to
enter example.com;keep-alice=stun because perhaps 
>they saw that in some other system. Their device sends a stun packet
and gets black listed. Note that any services that 
>blacklists after receiving a single STUN packet with a spoofed IP
address is going to be trivial to totally DOS so I 
>don't believe this sort of thing will deploy buts let continue down
this case. So the user UA does not work. It also 
>would not have worked if they typed in elpmaxe.com (example backwards).
What do they do? read a web page, phone tech 
>support, I have no idea but they do whatever they do when they
configure the outbound proxy information correction. 
>Eventually they find out to remove the keep-alive=stun and their phone
starts working.
>
>For these reasons, I don't think this whole problem is not a huge deal.
However, if people do think it is a big deal, the 
>obvious solution to it is send and OPTIONS message to find out if the
server supports this.

If you want to know before you send the REGISTER request, you can do
that. But, again, I think the outbound proxy should be able to indicate
the support, e.g. by inserting keepalive=stun in the Path header. 

>Most people don't seem to think this is enough of a problem to warrant
and additional RTT when a UA boots. We can come up 
>with other possible solutions to this too (as there are at least three
others on this same thread).
>
>The meta question is simple - we had pretty strong consensus on this in
the meeting. How long do we really want to spend 
>delaying this draft to find alternative solutions to this problem.
Clearly the answer different based on how serious a 
>problem you think it is.

I have presented an alternative solution :) If it doesn't work, fine,
but as far as I remember nobody has yet told me it doesn't work.

Regards,

Christer

---

From: Fredrik Thulin <[email-masked]>
Date: Wed, 9 Aug 2006 21:05:14 +0200

On Wednesday 09 August 2006 20:08, Hadriel Kaplan wrote:
...
> > The argument that a response containing something saying "I claim I
> > can handle STUN requests you send me" is to be trusted, but
> > configuration saying ";keepalive=stun" is not is flawed.
>
> Au contraire.  I would argue fairly vehemently that a server
> explicitly indicating it supports something is far more reliable than
> a UA believing the server supports something based on a local config
> setting.  The former is an explicit indication by the guy who's
> responsible for doing that mechanism, whether he can do it or not;
> the latter is a guess by the client as to the other side's
> capabilities.  Certainly the proxy can be wrong, but that probability
> is miniscule to the odds that one UA out of a large population will
> be wrong.

UAs won't just dream up the ";keepalive=stun" - that would typically 
come from provisioning which is done by people who the proxy operator 
will have to talk to anyways.

Either way, the UAC's will _have to test_ if the proxy supports sip-stun 
or not.

> It sure will.  But if the proxy indicated support for sip-stun, that
> failure would only occur if the proxy implementation was broken.

... and ";keepalive=stun" would only fail if the provisioning was 
broken. The ONLY thing that will NEVER fail is testing before 
believing. Provisioned information indicating the server supports 
sip-stun is definitely a strong enough indication for the UAC to send a 
STUN request and see, IMO.

 (by the way, I'm not going to say the same thing again in a subsequent 
e-mail, this topic seems to have a built in merry-go-round).

/Fredrik

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 9 Aug 2006 21:39:19 +0200

Hi, 

>>responsible for doing that mechanism, whether he can do it or not; the

>>latter is a guess by the client as to the other side's capabilities.  
>>Certainly the proxy can be wrong, but that probability is miniscule to

>>the odds that one UA out of a large population will be wrong.
>>
come from provisioning which is done by people who 
>the proxy operator will have to talk to anyways.

If you are possible to provision that information, which may not always
be the case.

>Either way, the UAC's will _have to test_ if the proxy supports
sip-stun or not.

I think it's bad design if you need to send messages in order to find
out if the receiver supports the protocol in the first place...

Regards,

Christer

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 9 Aug 2006 13:02:11 -0700

On Aug 9, 2006, at 11:56 AM, Cullen Jennings wrote:

> check for a sip-stun option tag. (clearly more wording needed but  
> you know what I mean)
>

Just to update this slightly, the UA would *also* do the OPTIONS test  
if the auto-config of discovered proxy was only an IP address and not  
an URI

> Would that work for you? I suspect it would work for most people.  
> I'd certainly be in favor of that. I suspect for proxies with  
> millions of users, they will use auto-config so this will not slow  
> them down and for proxies with UA with manual config, it will not  
> be enough UA to cause a huge performance impact. I don't know why I  
> did not think  of this before.
>
> Cullen
>
>

---

From: "Bob Penfield" <[email-masked]>
Date: Wed, 9 Aug 2006 15:56:41 -0400

inline
----- Original Message ----- 
From: "Cullen Jennings" <[email-masked]>
Sent: Wednesday, August 09, 2006 2:50 PM
Subject: Re: [Sip] Outbound Issues: slides 3 and 4 - B2BUA Proposal

>>
> If I am reading 3261 correctly, the proxy would no longer be
> a proxy but a B2BUA. I had proposed this a long time ago and several 
> people were very concerned about proxies
> modifying Proxy-Require headers. By the time they were
> done with me, I shared their concerns about doing that.
> This is a very slippery slope to be diving down if we
> ever expect to have some level of integrity around the
> only mechanism available in SIP for negotiation future
> forward compatibility with proxies.  It would likely
> work with stuff that is deployed today but it is not
> backwards compatible with things we have specified
> today. An UAS that did AIB would be perfectly correct
> to reject a response  that had proxy required where
> things had been removed.

Then I guess we already have a problem. According to table 3 in RFC 3261, a 
proxy is allowed to add option tags to a Proxy-Require header. I am not 
aware of anything that does this today, but it is certainly legal. If a UAC 
includes Proxy-Require in any kind of signature, it will fail if it goes 
thru a proxy that adds a tag.

I checked AIB and did not see any reference to including Proxy-Require in a 
signed body.

There are at least two RFCs (3323 and 3329) that have MUST level 
requirements to remove option tags from the Proxy-Require header. I think 
that is a proxy performs all of the require functionality for a given option 
such that no downstream proxy needs to support the option, it can and should 
be removed. The privacy and sec-agree are two examples documented today, 
although 3323 does indicate that a privacy service is a B2BUA.

>
> People bring up some of the 3G security stuff as a example
> that this is ok -  but that was something that was intended
> for a specific and high controlled deployment model. It was
> also something that has had some difficulties so I would
> hardly use it as an example of why this is all alright.
>
> As EKR would say, the important high oder bit here is,
> regardless of if we end up rewriting 3261 to make this
> change or not, the discussion to make the decision is
> probably not going to be short.
>

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 9 Aug 2006 14:54:56 -0500

To me it seems natural that a Proxy would swallow the Proxy-Require for
cases where it determines that it is the only Proxy that is required to
support the capability, which is clearly the case here.

I don't believe there is anything contracticting this interpretation
in 3261.

If it is a feature that is supposed to be end-to-end accross all
proxies,
then you'd leave it alone. 

> From: Dean Willis [mailto:[email-masked]] 
> Sent: Tuesday, August 08, 2006 4:32 PM
> To: Jeroen van Bemmel
> Cc: IETF SIP List; Rohan Mahy
> > Are you suggesting an alternative because there is something wrong 
> > with the proposal from Rohan above?
> 
> The only thing I have seen in Rohan's proposal that makes 
> people queazy is the handling of the proxy-require -- that 
> is, removing it in the first hop proxy.
> 
> But it seems to bother Cullen and a few others, even if I did 
> borrow his words to say I'm ok with it.
> 
> --
> Dean
>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 9 Aug 2006 12:59:27 -0700

On Aug 9, 2006, at 11:57 AM, Christer Holmberg ((JO/LMF)) wrote:

>>> verify
>>> risk

This would work for some deployments but imagine a simple UA  
connecting directly to a single proxy / registrar. In this simple  
case there would be no path headers.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 9 Aug 2006 12:59:18 -0700

On Aug 9, 2006, at 12:07 PM, Christer Holmberg ((JO/LMF)) wrote:

>>> outbound
>> every

Yep - let me update my response to Bob with something to take this  
into account...

>> backwards).
>> deal.

Sure, I'm fine with the UA discovering URI via path or other  
mechanisms that have the flag then starting using it on connection to  
theses URI. But I think this is out of scope of this draft.

> but as far as I remember nobody has yet told me it doesn't work.

I will send email to that one too :-)

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 9 Aug 2006 13:16:55 -0700

Bob - I really think that your other proposal is sounding like a good  
way to go to me but few points inline here ...

On Aug 9, 2006, at 12:56 PM, Bob Penfield wrote:

> inline
> ----- Original Message ----- From: "Cullen Jennings"  
> <[email-masked]>
>> a proxy but a B2BUA. I had proposed this a long time ago and  
>> several people were very concerned about proxies
> Then I guess we already have a problem. According to table 3 in RFC  
> 3261, a proxy is allowed to add option tags to a Proxy-Require  
> header. I am not aware of anything that does this today, but it is  
> certainly legal. If a UAC includes Proxy-Require in any kind of  
> signature, it will fail if it goes thru a proxy that adds a tag.
>
> I checked AIB and did not see any reference to including Proxy- 
> Require in a signed body.
>
> requirements to remove option tags from the Proxy-Require header. I  
> think that is a proxy performs all of the require functionality for  
> a given option such that no downstream proxy needs to support the  
> option, it can and should be removed. The privacy and sec-agree are  
> two examples documented today, although 3323 does indicate that a  
> privacy service is a B2BUA.
>

True enough but I don't see a problem in that. I don't see a problem  
with 3261 having a proxy add things, it is the deleting or modifying  
that causes problems

3323 points out that
    In order to provide these functions the
    privacy service must frequently act as a transparent back-to-back
    user agent (B2BUA).
Privacy services by definition have very different security  
properties. It probably impossible to have both some form of strong  
end 2 end integrity coupled with anonymization. I don't think anyone  
is thrilled with the what is possible in this space - just we can't  
come up with anything better at that point.

As I mention below, 3329 is limited to environments where, quoting  
from the RFC
    Therefore, this extension
    should be used in environments where it is somehow ensured that  
every
    client implements this extension or is able to use TLS.

The or use TLS is somewhat dubious because there is a chicken and egg  
problem in for the UA know what to do but that's sort of irrelevant  
for this discussion.

---

From: "Bob Penfield" <[email-masked]>
Date: Wed, 9 Aug 2006 16:31:14 -0400

I suppose that would work, but to guarantee that the outbound proxy acted as 
the UAS, you'd have to make the Request-URI be the proxy's address.

Alternatively, you could include Proxy-Require: sip-stun and a Max-Forwards 
of 1. Or use Max-Forwards 0 and require the optional proxy behavior 
specified on page 95 of 3261.

   If the request contains a Max-Forwards header field with a field
   value of zero (0), the element MUST NOT forward the request.  If
   the request was for OPTIONS, the element MAY act as the final
   recipient and respond per Section 11.  Otherwise, the element MUST
   return a 483 (Too many hops) response.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
71 Third Avenue
Burlington, MA 01803
[email-masked]

----- Original Message ----- 
From: "Cullen Jennings" <[email-masked]>
To: "Bob Penfield" <[email-masked]>
Cc: "Hisham Khartabil" <[email-masked]>; "Rohan Mahy" 
<[email-masked]>; "IETF SIP List" <[email-masked]>
Sent: Wednesday, August 09, 2006 2:56 PM
Subject: Re: [Sip] Outbound Issues: slides 3 and 4

> discovery mechanisms, then it MUST do an OPTIONS message first and  check 
> for a sip-stun option tag. (clearly more wording needed but you  know what 
> I mean)
>
> users, they will use auto-config so this will not slow them down and  for 
> proxies with UA with manual config, it will not be enough UA to  cause a 
> huge performance impact. I don't know why I did not think  of  this 
> before.
>
> Cullen
>
>
>> outbound proxy set thru auto-config or discovery  mechanisms can try to 
>> use outbound w/STUN. I would make it a MAY  for the UA.
>

---

From: Dean Willis <[email-masked]>
Date: Wed, 9 Aug 2006 16:18:17 -0500

On Aug 9, 2006, at 1:49 PM, Cullen Jennings wrote:

> decide to enter example.com;keep-alice=stun because perhaps they  
> saw that in some other system. Their device sends a stun packet and  
> gets black listed. Note that any services that blacklists after  
> receiving a single STUN packet with a spoofed IP address is going  
> to be trivial to totally DOS so I don't believe this sort of thing  
> will deploy buts let continue down this case. So the user UA does  
> not work. It also would not have worked if they typed in  
> elpmaxe.com (example backwards). What do they do? read a web page,  
> phone tech support, I have no idea but they do whatever they do  
> when they configure the outbound proxy information correction.  
> Eventually they find out to remove the keep-alive=stun and their  
> phone starts working.
>

I'm more worried about the scenario where the UA doesn't get  
blacklisted, but just throws a monkeywrench in performance, and it  
sucks just enough that people don't fix it but complain anyhow.

> solution to it is send and OPTIONS message to find out if the  
> server supports this.  Most people don't seem to think this is  
> enough of a problem to warrant and additional RTT when a UA boots.  
> We can come up with other possible solutions to this too (as there  
> are at least three others on this same thread).

To recap:

Unacceptable: If you're configured to use STUN, just keep STUNning  
whether it works or not. You may be dead, but you're right, and  
that's the important part.

Alternatives:

1) Use an OPTIONS transaction before stunning to find out if the  
target supports STUN
2) Use any other SIP transaction (like REGISTER) to find out if the  
target supports STUN
	a) using a Proxy-Require
	b) Using some sort of Path: tagging
3) Just go ahead and STUN, and if it doesn't work, stop sending STUN.

I'd be happy with 1+3 or 2+3. I'd even be happy with 1+3 where 1 is a  
"SHOULD" strength, but 3 needs to be a MUST. It may be common sense,  
but it requires documentation, and people seem to need "common sense"  
to have a MUST priority on it or they pretend it isn't important.

If we go the 1-SHOULD+3-MUST route, we need to include the "Because  
the proxy might think your STUN is an attack or error condition and  
black-list you" as the explanation for the SHOULD.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 9 Aug 2006 16:22:23 -0500

On Aug 9, 2006, at 1:50 PM, Cullen Jennings wrote:

> response to the register, this lets you know the device you are  
> about to send a stun request to is "up"
>

Question inspired by Hisham: Aren't there address and port dependent  
mapping scenarios that seem to indicate that a UA should derive its  
effective contact address from doing a STUN to the SIP port of its  
proxy before registering? I thought that was one of the bonuses we  
got out of coaxial STUN and SIP.

--
Dean

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 9 Aug 2006 17:43:18 -0400

> From: Cullen Jennings [mailto:[email-masked]]
> 

It won't be one single stun, as the UAC has to resend several in case of
packet loss.  In my opinion blacklisting it may actually be the right thing
to do, oddly enough.  But that's not my concern.  

My concerns/issues are: 

(1) A way to let the operator of the proxy know something's amiss and
correct it. That is more likely with a proxy-require sip-stun option tag,
because a proxy which does not understand outbound would (hopefully) log
this required thing it doesn't support, and the operator can simply google
"sip-stun" and find this RFC. (I know, that's a simplistic view)

(2) this is a mechanism which REQUIRES a proxy to do something, to work
correctly, but doesn't want to use the SIP-defined mechanism to do so.  Why?
Every other extension has a ACK/NACK mechanism in SIP, except for the one
that is arguably one of the biggest changes.

(3) checking a server supports a malformed message by actually sending the
malformed message is, well, simply rude. :)  It makes this draft a new
torture test; as I said in Montreal I doubt any maker of SIP products on
this mailing list or WG would have a problem with stun messages. (though one
would have thought that back when Protos first came out, too)

-hadriel
p.s. Fredrik: yes, round and round we go.

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 9 Aug 2006 22:07:53 +0200

Hi, 

>>Why can't the proxy, if it inserts a Path header, add keepalive=stun 
>>to that Path header? Then the UAC does not need to send stun request 
>>in order to figure out whether the proxy supports STUN keepalive or 
>>not.
>>
>>(Of course, if the proxy does NOT support Path then the UAC may have 
>>to figure out by sending STUN requests.)
>>
>This would work for some deployments but imagine a simple UA connecting
directly to a single proxy / registrar. In this 
>simple case there would be no path headers.
>
In that case the proxy/registrar could insert an option-tag in the
Supported header, to indicate it supports STUN keepalive (similar to
outbound).

And, if we change "keepalive=stun" to something which also fits the
option-tag syntax we could use the same value in both 
the Path and Supported header.

Regards,

Christer

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Aug 2006 17:50:32 -0400

changing topics here.

Hisham - why would you want to do this? The whole idea of sip-outbound 
is to make the IP in the Contact irrelevant. It will be ignored anyway. 
Perhaps you are worried about an outbound proxy that supports stun but a 
  registrar that doesn't support sip-outbound?

There are some pretty sizeable security risks in doing this. In 
particular, as long as the client doesn't actually use the mapped 
address that comes back - but rather uses it as a hint to go do 
something else - you can get away without authenticating the stun 
transactions. If you actually use the mapped address from the stun 
response in the Contact, an attacker can send a spoofed stun response 
can incoming calls get routed to him instead. This is partly (and only 
partly) fixable if you authenticate stun responses. However, once you 
require stun authentication then the whole performance benefit of stun 
goes away.

Thanks,
Jonathan R.

Hisham Khartabil wrote:

>> adds no extra round trips if the SIP UA was indeed correctly configured.
>>

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 9 Aug 2006 14:52:11 -0700

On Aug 9, 2006, at 1:31 PM, Bob Penfield wrote:

> I suppose that would work, but to guarantee that the outbound proxy  
> acted as the UAS, you'd have to make the Request-URI be the proxy's  
> address.
>

Agreed - I think like this better than your next alternative since  
you have the the address but either could work

> Alternatively, you could include Proxy-Require: sip-stun and a Max- 
> Forwards of 1. Or use Max-Forwards 0 and require the optional proxy  
> behavior specified on page 95 of 3261.
>
>> discovery mechanisms, then it MUST do an OPTIONS message first  
>> and  check for a sip-stun option tag. (clearly more wording needed  
>> but you  know what I mean)
>>
>> be enough UA to  cause a huge performance impact. I don't know why  
>> I did not think  of  this before.
>>
>> Cullen
>>
>>
>>> I don't think the verification should be required, I just want  
>>> to  have a method to verify. That way, a UA that does not have a  
>>> means  to learn the outbound proxy set thru auto-config or  
>>> discovery  mechanisms can try to use outbound w/STUN. I would  
>>> make it a MAY  for the UA.
>
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Aug 2006 17:57:58 -0400

inline.

Cullen Jennings wrote:

> Sure, I'm fine with the UA discovering URI via path or other  mechanisms 
> that have the flag then starting using it on connection to  theses URI. 
> But I think this is out of scope of this draft.

I agree its out of scope. But its relevant here as it comes back to 
problem statement.

The root issue here is that someone constructs a URI with keepalive=stun 
when it shouldn't have. There are two reasons we've been discussing why 
this might happen:

1. a user types in their outbound proxy and adds keepalive=stun when 
they shouldn't have
2. outbound proxy is discovered via DHCP, and since DHCP provides a 
hostname and not a URI, a UA constructs a URI, and since it supports the 
stun keepalive adds the parameter

Case #2 is a legitimate cause for concern. However if we had a mechanism 
for autodiscovery of outbound proxies, where a URI was provided by that 
proxy itself, then this use case goes away, and the need for some of 
these verification mechanisms goes away too.

So, I had proposed at the mike during ietf a mechanism for discovery 
using Service-Route (Path is the wrong direction), which would make sure 
that, even if a client discovers the proxy initially via DHCP, it 
quickly learns a URI from that proxy which would inform it about whether 
stun is supported. Draft coming soon on this...

If we had such a mechanism, then I dont think we need any of this mess. 
In particular, though I dont really see a lot of harm in Rohans 
Proxy-Require proposal, I think its unnecessary complexity if you have a 
proper discovery mechanim. Since we need a proper discovery mechanism 
regardless lets solve that problem and ditch the extra mechanism.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Aug 2006 17:59:40 -0400

Well, IMHO in this case it would simply use Path anyway, pointing to itself.

-Jonathan R.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 9 Aug 2006 14:59:35 -0700

On Aug 9, 2006, at 2:22 PM, Dean Willis wrote:

> Question inspired by Hisham: Aren't there address and port  
> dependent mapping scenarios that seem to indicate that a UA should  
> derive its effective contact address from doing a STUN to the SIP  
> port of its proxy before registering? I thought that was one of the  
> bonuses we got out of coaxial STUN and SIP.
>
> --
> Dean
>

If you are doing outbound, it does not matter what IP you put in the  
contact - presumably devices will use things like their private IP  
address. In the cases where you are not doing outbound, you need to  
be configured with a stun server if you want to use stun to find your  
public IP address, how a UA would check that the stun server it is  
configured to use is correct before sending it any stun messages is a  
problem I would like to keep out of scope of the outbound draft.  
Using the outbound proxy even if it did support stun would be pretty  
risky because it might be inside one of the NAT layers and not in an  
public IP space.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Aug 2006 17:59:40 -0400

-Jonathan R.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 9 Aug 2006 14:59:35 -0700

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 9 Aug 2006 15:12:53 -0700

I think Bob's proposal probably addresses your concerns and ends up  
being a better proposal than the one I made.

On Aug 9, 2006, at 2:43 PM, Hadriel Kaplan wrote:

> packet loss.

Yes - I put "a small number" you put "several". I expect that we  
agree that we are probably talking a number between 3 and 5.

>   In my opinion blacklisting it may actually be the right thing
This fits my mental model on how many voip networks are debugged :-)  
Many proxies also log that they received an malformed message too.

> would have thought that back when Protos first came out, too)

I don't think this is quite a fair characterization. If you set up  
your DNS such that the SIP SRV points at your imap server, you have  
the same problem. If I type the address and port of my web server in  
as the address of my sip server on my UA I have the same problem. In  
general the way nearly every IETF protocol in existence works is when  
it is given a servers address to connect to, it sends a message to it  
and sees if it works.

> p.s. Fredrik: yes, round and round we go.

I think Bob's proposal could get us all off this merry go round -  
have a look and see if you could "live with it" even if it was not  
your first choice.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 9 Aug 2006 15:14:47 -0700

> the Path and Supported header.

It used to be sip-stun but there was strong agreement in one of the  
WG meetings to change it to keepalive=stun. we could reopen that  
decision too if folks wanted :-)

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 9 Aug 2006 18:48:12 -0400

> Many proxies also log that they received an malformed message too.

Totally, but I would think it's a lot harder to know what it means when your
proxy says "I got a malformed message" or even if it gave you a copy of it,
since it and you don't know it's a stun message.  Now if they had only made
the STUN message format start with 0x5354554E, it would help.  ;-)

> it is given a servers address to connect to, it sends a message to it

Yes, but what IETF RFC would actually mandate you to send SIP to your IMAP
server, to see if the IMAP server also understands SIP?  A mis-configuration
or user error is a very different context, I think.  For example, in one you
blame the operator of the DNS, and in the other you blame the IETF.  

-hadriel

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 9 Aug 2006 15:56:41 -0700

Did you read the slides?  The topic of this thread is only slides 3 and 
4.

thanks,
-rohan

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 9 Aug 2006 19:21:53 -0400

> Sent: Wednesday, August 09, 2006 6:13 PM
> To: Hadriel Kaplan
> Cc: 'IETF SIP List'

I would if I knew which one it was.  :)

Is it:
(1) If auto-config or auto-discovery doesn't indicate the proxy supports
stun, then the UA MUST use Options, with the proxy's address as the
request-uri, to verify the proxy supports STUN by checking that the proxy
inserted a sip-stun option tag. (where would it stick this tag, BTW?)  
That's your proposal isn't it?

Or (2) If auto-config or auto-discovery doesn't indicate the proxy supports
stun, then the UA MUST verify the proxy supports stun by inserting a
proxy-require sip-stun option tag, which the proxy will remove and continue
to process if it supports stun, or respond negatively with a 420 Bad
Extension if it does not.

I am assuming here auto-config means any way of being configured EXCEPT
through a user interface?  And auto-discovery is Erkki's draft, or something
similar?

I _really_ prefer (2) because it's simpler, and I find simpler gets
implemented.  And tying the success/fail of a registration process to
Options seems bad to me, though I can't put my finger on why.  
But yeah I can live with it.

-hadriel

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 10 Aug 2006 05:54:05 +0200

Hi Rohan,

I agree it's out of scope - I was just replying to Hisham's comment.

Regards,

Christer 

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]] 
Sent: 10. elokuuta 2006 1:57
To: Christer Holmberg (JO/LMF)
Cc: Hisham Khartabil; Rohan Mahy; IETF SIP List
Subject: Re: [Sip] Outbound Issues: slides 3 and 4 

thanks,
-rohan

On Aug 9, 2006, at 8:44, Christer Holmberg ((JO/LMF)) wrote:
>>> vocal minority had significant problems with this assumption.  After

>>> a

---

From: Dean Willis <[email-masked]>
Date: Thu, 10 Aug 2006 00:56:01 -0500

Rohan Mahy wrote:
> Did you read the slides?  The topic of this thread is only slides 3 and 4.
> 

Dude, he's saying you should have yelled at Hisham for being off-topic.

Bad Hisham! No biscuit! None for me either!

--
Dean

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 10 Aug 2006 08:54:11 +0200

Hi, 

>I think Bob's proposal could get us all off this merry go round - have 
>a look and see if you could "live with it" even if it was not your 
>first choice.
>
>(1) If auto-config or auto-discovery doesn't indicate the proxy
supports stun, then the UA MUST use Options, with the 
>proxy's address as the request-uri, to verify the proxy supports STUN
by checking that the proxy inserted a sip-stun 
>option tag. (where would it stick this tag, BTW?) That's your proposal
isn't it?
>
>Or (2) If auto-config or auto-discovery doesn't indicate the proxy
supports stun, then the UA MUST verify the proxy 
>supports stun by inserting a proxy-require sip-stun option tag, which
the proxy will remove and continue to process if it 
>supports stun, or respond negatively with a 420 Bad Extension if it
does not.
>I am assuming here auto-config means any way of being configured EXCEPT
through a user interface?  And auto-discovery is 
>Erkki's draft, or something similar?
>
implemented.  And tying the success/fail of a 
>registration process to Options seems bad to me, though I can't put my
finger on why.  
>But yeah I can live with it.

I don't think the UAC shall be mandated to send OPTIONS. Yes, IF the UAC
wants to find out whether the outbound proxy supports STUN keep-alive
before sending the REGISTER it can send OPTIONS (or whatever mechanism
we'll end up with). 

But, as discussed in the "Re: [Sip] Outbound Issues: slides 3 and 4 -
using Path/Supported to indicate STUN keepalive support" thread, the UAC
may also find out about the support duing the registration process
itself.

ALSO, think the option tag value should be something like
"sip-stun-keepalive", because in future we MAY need option tags for
other STUN usages in SIP. Please note that we are only talking about a
single STUN usage here, which does NOT require the parties to have FULL
STUN support.

Regards,

Christer

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 10 Aug 2006 09:26:26 +0200

Hi, 

>>>that. But, again, I think the outbound proxy should be able to  
>>>indicate the support, e.g. by inserting keepalive=stun in the Path
header.
>>mechanisms that have the flag then starting using it on connection to
theses URI.
problem statement.

I am not sure I agree its out of scope. The draft defines the STUN
keepalive usage for SIP, and as part of that we define option tags, and
how SIP entities may use them.

Please note that my proposal is not really a outbound proxy discovery
mechanism, because when the REGISTER is sent some kind of "discovery"
has already been done. My proposal simply allows a proxy to indicate
that it supports STUN keepalive.

Anyway, if you DO agree that it's relevant we don't need to argue
whether it's in the scope or not :)

>The root issue here is that someone constructs a URI with
keepalive=stun when it shouldn't have. There are two reasons 
>we've been discussing why this might happen:
>
they shouldn't have 2. outbound proxy is discovered 
>via DHCP, and since DHCP provides a hostname and not a URI, a UA
constructs a URI, and since it supports the stun 
>keepalive adds the parameter
>
>Case #2 is a legitimate cause for concern. However if we had a
mechanism for autodiscovery of outbound proxies, where a 
>URI was provided by that proxy itself, then this use case goes away,
and the need for some of these verification 
>mechanisms goes away too.

One issue I have with the URI parameter is that we use the URI as some
kind of "configuration file". What about other (current of future) proxy
capabilities? Should we be able to indicate those in the URI too? Maybe
we for example want to indicate that the outbound proxy supports
session-timer (maybe a bad example, but anyway)... 

Sip:[email-masked];keepalive=stun;session-timer=yes;capability-x=y
yy;capability-y=zzz...

Also, EVEN if we DO use the URI to provide the information, I see no
reason why all this information then should be sent to the network (I
think someone else mentioned that also) in the SIP request(s) sent by
the UAC.

Anyway, that is out of the scope, so we don't need to discuss it as part
of this thread :)

>So, I had proposed at the mike during ietf a mechanism for discovery
using Service-Route (Path is the wrong direction),

Doesn't this mean that the outbound proxy would have to insert a
Service-Route header with the STUN keepalive indication? Or, would the
proxy insert the indication in the Path of the request, and the
registrar would then copy the indication into the Service-Route of the
response? Is this related to your route contstruct ideas?

>which would make sure that, even if a client discovers the proxy
initially via DHCP, it quickly learns a URI from that 
>proxy which would inform it about whether stun is supported. Draft
coming soon on this...

>In particular, though I dont really see a lot of harm in Rohans
Proxy-Require proposal, I think its unnecessary 
>complexity if you have a proper discovery mechanim. Since we need a
proper discovery mechanism regardless lets solve that 
>problem and ditch the extra mechanism.

If someone wants to use Proxy-Require he/she could of course be allowed
to do that, IF he/she wants to be sure the proxy supports STUN keepalive
before sending a REGISTER. 

BUT, again, I don't think one should be mandated to use Proxy-Require.
The UAC should be able to find out during the registration procedure,
and the UAC may then choose to continue the registration even if the
outbound proxy does not support STUN keepalive...

Regards,

Christer

---

From: Hisham Khartabil <[email-masked]>
Date: Thu, 10 Aug 2006 10:36:52 +0200

On Aug 9, 2006, at 8:08 PM, Hadriel Kaplan wrote:

>> .

Ok, so lets standardise a mechanism for servers to explicitly indicate 
that it supports the following, even if configured in the client:

- STUN
- loose-routing
- comp=sigcomp
- ...

Hisham

---

From: Hisham Khartabil <[email-masked]>
Date: Thu, 10 Aug 2006 10:39:09 +0200

On Aug 9, 2006, at 11:50 PM, Jonathan Rosenberg wrote:

> is to make the IP in the Contact irrelevant. It will be ignored 
> anyway. Perhaps you are worried about an outbound proxy that supports 
> stun but a  registrar that doesn't support sip-outbound?

We are looking into supporting stun keepalive first in our network. 
sip-outbound is not being considered to be deployed at the same time. 
If you remember, I did ask for these 2 things to be split into separate 
drafts.

Hisham

>>> outbound proxy supports SIP and STUN over the same port, a small but 
>>> extremely vocal minority had significant problems with this 
>>> assumption.  After a discussion with Dean, I am willing to try a 
>>> validation proposal which adds no extra round trips if the SIP UA 
>>> was indeed correctly configured.
>>>
>>> If the URI was correct (STUN was supported), and the first-hop is an 
>>> Supported: outbound and no error counts as positive confirmation 
>>> that either the registrar supports STUN or expects to never receive 
>>> a request without getting it from an outbound proxy which did not 
>>> (the first-hop intermediary does not support STUN keepalives), 
>>> intermediary), or the registrar will not include an indicator that 
>>> it supports outbound (if the first hop was the registrar).
>>>
>>> verification mechanism.  For example, if the registrar doesn't 
>>> support outbound, but the first-hop does, there is no way described 
>>> here to discover that the first-hop can accept STUN keepalives.  Do 
>>> not confuse support of STUN with support of outbound.  Supported: 
>>> outbound implies that the registrar supports STUN or is configured 
>>> to use an outbound proxy that does.  The sip-stun option tag only 
>>> means that you can send and receive STUN requests on your SIP port. 
>>> While outbound requires STUN, STUN does not require outbound.
>>>
>>> yourself in the foot if you allow messages to come straight to your 
>>> registrar that does not support STUN.  I think we agreed that we are 
>>> not going to enumerate all the ways you can subtly break things in 
>>> SIP though.
>>>
>>> thanks,
>>> -rohan
>>>
>>>

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 10 Aug 2006 11:56:12 +0200

Hi, 

drafts.

I asked for it also. And, I think the decission was that the 2 things
WILL be split, even if they will still be described in the same physical
draft.

But, still, the STUN keepalive usage has nothing to do with STUN IP
address discovery usage. Those are two completely separate STUN usages.
Of course, you can use them together, but you can also use STUN
keepalive without STUN IP discovery - even if you do NOT use outbound.

Regards,

Christer

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 10 Aug 2006 12:10:39 +0200

Also, if you want to use STUN for IP discovery, how you get the address
of the STUN server is out of the scope. 

I don't think you can assume that the address of the STUN server and the
outbound server will be the same in that case - you may not even have an
outbound server (Read: SIP entity with STUN support). The address MAY of
course be the same, but I don't think we can make that assumption. 

Because, in some cases I don't think you would like to send your STUN
requests to the outbound proxy, e.g. if you want to use STUN relay for
your media.

Also, the outbound proxy is only required to have STUN functionlity in
order to support STUN keepalive (that may be enough also for STUN IP
discovery in some cases, though)
 
Regards,

Christer

-----Original Message-----
From: Christer Holmberg (JO/LMF) [mailto:[email-masked]]

Sent: 10. elokuuta 2006 12:56
To: Hisham Khartabil; Jonathan Rosenberg
Cc: IETF SIP List; Rohan Mahy
Subject: RE: using mapped addresses from stun in sip-outbound,was: Re:
[Sip] Outbound Issues: slides 3 and 4

Hi, 

drafts.

Regards,

Christer

---

From: <[email-masked]>
Date: Fri, 11 Aug 2006 11:48:29 +0300

Hi, 

> Concern that the mailing list combatants on these issues are not 
> present in the room; this will have to go to the mailing list.

Being one of those "extremely vocal combatants not present in Montreal"
it is now time for myself to express my opinion about proposed solutions
and the related discussions I could recap from the IETF SIP WG meeting
minutes and the emails on this subject prior to and after the meeting.

First of all I was very delighted to see that one of the authors
of SIP Outbound finally took this issue up and proposed a solution
for it, to be added to the Outbound draft:

>I am willing to try a validation proposal which 
>hop can support STUN messages on the SIP port, needs to verify 
>the first hop supports STUN before sending any STUN messages. 
>The UAC sends its first SIP message to the next hop with a 
Proxy-Require: sip-stun.  If the URI was correct 
>positive response to a REGISTER or OPTIONS with Supported: 
>outbound and no error counts as positive confirmation that either 
>the registrar supports STUN or expects to never receive a request 
>without getting it from an outbound proxy which did not complain 
>about the Proxy-Require [1]. If the UAC was misconfigured 
>intermediary), or the registrar will not include 

I find this solution perfect: it is simple, complete, lightweight, 
proven to work in other contexts, it solves the problem neatly. 
I would say: "Just do it and let the Outbound draft converge".

But it seems to be not that easy after all. Let me recap the
current situation with this proposal.

>From the raw WG notes and emails about the subject after the 
meeting I was able to gather the following summary for this
proposal. Please tell if I have misinterpreted your statement 
in the mailing list and counted you into a wrong camp:

A. GO:

	10 WG members have expressed that they understand the 
	Proxy-Require solution and do not see a problem
	with it:

		Rohan Mahy
		Robert Sparks
		Hadriel Kaplan
		Jeroen van Bemmel
		Bob Penfield
		Christer Holmberg
		Francois Audet
		Joel M. Halpern
		Dean Willis
		Erkki Koivusalo

B. No-GO

	4 WG members are opposing the Proxy-Require solution

		Cullen Jennings
		Jonathan Rosenberg
		Hisham Khartabil
		Fredrik Thulin

I would like to revisit the issues explicitely mentioned
in the mailing list against the Proxy-Require solution 
and my conclusions for each of those issues. Sorry that
this becomes long story, but I just could not help it:

1. Is there a real problem to be solved ?

Cullen Jennings
>in some other system.

	Please note that user possibly does not need to type
	the ;keep-alive=stun. The UA might have a user interface
	with one button with text "Is the phone behind a NAT ?"
	and after selecting "Yes" the phone would add this URI
	parameter. Perhaps badly designed UA, but possible.

Christer Holmberg:
>Assuming the UA is configured with a URI, yes. But, in case the 
>UA only gets the IP address of the proxy, you still have a problem.

Jonathan Rosenberg:
>Case #2 is a legitimate cause for concern. 

Conclusion: it is a problem because of the following reasons:
	- UA might only have the IP address of the proxy available
	- UA might get the domain name from DHCP without URI params
	- UA might be configured by the user incorrectly

2. Is the solution in scope of SIP Outbound draft ?

Cullen Jennings:
>I think this is out of scope of this draft.

Jonathan Rosenberg:
> I agree its out of scope. 
>
>However if we had a mechanism 

>Since we need a proper discovery mechanism regardless lets solve that 

Christer Holmberg:
>Anyway, if you DO agree that it's relevant we don't need 
>to argue whether it's in the scope or not :)

Dean Willis:
> There have been several options mentioned to do this, a simple 
> way is to have the edge proxy insert a flag. Question is: why not?
>
>I find that I've developed a great deal of sympathy for the above 
>position. Discovery is indeed separable from error-detection (or 
>confirmation, detecting "absence of error").

Conclusion:
	- Since this draft creates such a problem it is in my 
	  understanding in the scope of this draft to fix it,
	  expecially when the means are already outlined and
	  seem to be well understood and widely accepted.
	- Moving the solution to another draft would mean that
	  we introduce the problem to the market when the draft
	  is approved as RFC but would postpone solving it to 
	  some undetermined date (if ever).

3. Does Proxy-Require technique work or is it too complex ? 

Jonathan Rosenberg:
>Proxy-Require proposal, I think its unnecessary complexity if 
>you have a proper discovery mechanim. 

	Is the proposal really so complex at all ? I propose
	the following text for the Outbound draft:

The UA SHOULD add a Proxy-Require header field with the 
value "sip-stun" to its REGISTER request. When the UA
receives 200 OK with Supported: Outbound it can be sure
that the next hop will support STUN keepalives.

The proxy MUST remove the "sip-stun" value from the 
Proxy-Require header field and then remove the header 
if no values remain before forwarding the request to
the next hop.

	If you have any doubts whether it works or not, please
	look into RFC 3329 from which I copied this text and 
	modified it to sip-stun purpose. It is proven and widely 
	deployed technique within Sec-Agree.

Dean Willis:
>The only thing I have seen in Rohan's proposal that makes people 
>queazy is the handling of the proxy-require -- that is, removing 
>it in the first hop proxy.
>

Conclusion:
	- As Proxy-Require is used in a similar way in RFC 3329
	  with wide deployment this concern can be ignored.

4. Can UA rely on the response from the proxy ?

Fredrik Thulin
>The argument that a response containing something saying 
>"I claim I can handle STUN requests you send me" is to be 
>trusted, but configuration saying ";keepalive=stun" is not 
>is flawed. 

Hadriel Kaplan
>I would argue fairly vehemently that a server explicitly
>indicating it supports something is far more reliable 
>than a UA believing the server supports something based 
>on a local config setting.

Conclusion:
	- As this is hardcoded information in the proxy
	  implementation, it is very probably reliable
	- It works in a similar way for Sec-Agree too

5. What if there is no proxy between UA and registrar ?

Rohan Mahy:
>>Francois: Are you worried that such a REGISTRAR may not believe 
>>the Proxy-Require was intended for itself?
>

Conclusion:
	- Not a problem since in this situation the UA can
	  infer from Supported: Outbound header of 200 OK
	  that the registrar also supports STUN keepalives.
	  Just like outlined in Rohan's proposal.

6. Mandating UA not to send STUN packets before it has
   sent a REGISTER with Proxy-Require towards the proxy ?

>There are some pretty sizeable security risks in doing this.

Conclusion:
	- Jonathan already rejected the idea Hisham had
	- On the other hand it is possible to specify that the
	  UA either SHOULD or MAY add Proxy-Require, instead of
	  mandating it, if this is still regarded as a problem

7. Is there any better solution available so that 
   Proxy-Require would not be needed ?

7.1 Sending OPTIONS before REGISTER

Cullen Jennings:
>certainly be in favor of that. 

Cullen Jennings
>three others on this same thread).

Conclusion:
	- Sending OPTION has the drawback of extra RTT
	- Further on in my understanding it is more complex solution
	  for both the UA and the proxy (more logic to be implemented
	  to both ends) compared to Proxy-Require solution
	- I am not in favour of OPTION for those reasons

7.2 Sending STUN packets and waiting for responses

Hadriel Kaplan:
> > (3) checking a server supports a malformed message by actually
> > sending the malformed message is, well, simply rude. :)  
> > It makes this draft a new torture test;

> but what IETF RFC would actually mandate you to send SIP to your IMAP

Conclusion:
	- I am in an agreement with Hadriel on this. Getting an
	  explicit information by a query is much cleaner solution
	  than rather guessing the result from sending an arbitary
	  number of STUN packets and checking if any responses are
	  received.

It is probably obvious that I am not convinced by any
of the raised issues that the proposed Proxy-Require
technique would not work or that it could not easily
be added into SIP Outbound draft. So I am clearly in
favour of it. Whether or not the UA is mandated to
add Proxy-Require header to REGISTER does not matter
so much to me but I would hope to be able to design 
UAs that have such a possibility.

Regards,

Erkki

---

From: Fredrik Thulin <[email-masked]>
Date: Fri, 11 Aug 2006 12:11:29 +0200

On Friday 11 August 2006 10:48, [email-masked] wrote:
...
> 	- It works in a similar way for Sec-Agree too

I feel kind of misinterpreted here. My point was that no matter how 
strong of an indication the UA receives that the first-hop proxy 
supports STUN-in-SIP, it must still _verify_ that it does, and stop 
sending STUN requests if the proxy in fact doesn't, even if it claims 
it does.

The proxy explicitly saying it supports STUN-in-SIP (through the 
Proxy-Require scheme, or some other) is doubtlessly a strong indicator 
but it doesn't _prove_ that the proxy supports STUN-in-SIP.

This leads me to my opinion that just about any indicator at all the UAC 
has that the first-hop proxy supports STUN-in-SIP is a good enough 
reason for the UAC to try and see if it actually does. I don't care 
what the indicator looks like, but I don't want the Outbound draft to 
be tied up in what I consider pointless discussions, and complex 
solutions.

I agree with those that wants to have _some_ kind of indicator of 
support, but I think most people are overstating the importance of not 
sending a few STUN-in-SIP packet to a proxy that doesn't support it. 
Local configuration in the UAC is a good enough indicator for me. I 
believe the blacklist argument to be FUD.

/Fredrik

---

From: Hisham Khartabil <[email-masked]>
Date: Fri, 11 Aug 2006 14:36:08 +0200

My point exactly, I tried to say the same thing in an earlier email. 
Fredrik explained it better.

Hisham

---

From: Hisham Khartabil <[email-masked]>
Date: Fri, 11 Aug 2006 14:42:13 +0200

I also want to ask the people concerned why they are concerned. I can 
DoS your proxy with other things than STUN. Any binary junk will do. 
Worried about the extra unnecessary round trip for STUN? Thats not a 
good argument. Rohan's proposal requires the extra SIP roundtrip where 
the outboound proxy rejects the SIP request. A round trip of STUN is 
much cheaper than a roundtrip of SIP.

Hisham

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 11 Aug 2006 15:02:30 +0200

Hi,

I am sure that there are cases where messages (STUN, or whatever) will
be sent to destinations that don't support them, e.g. due to bad
configuration.

MY problem is that I don't like to standardize behavior which is based
on sending something somewhere just to find out if the reciever supports
the protocol in the first place. That is the reason I want to be able to
get the information from the proxy before sending anything.

Now, assume that case where the UA assumes (either via configuration or
an indicator from the edge proxy) that the outbound proxy supports STUN,
starts sending STUN requests but doesn't receive anything back. Of
course it should stop sending STUN requests in that case.

It's the same with SIP. If you send your request towards a proxy, but
don't get anything back, sooner or later I assume you will stop sending
your SIP request - even if you have been told (by configuration or
something else) that the receiver supports SIP...

Regards,

Christer

-----Original Message-----
From: Hisham Khartabil [mailto:[email-masked]] 
Sent: 11. elokuuta 2006 15:42
To: Fredrik Thulin
Cc: [email-masked]; [email-masked]
Subject: Re: [Sip] Outbound Issues: slides 3 and 4

Hisham

On Aug 11, 2006, at 12:11 PM, Fredrik Thulin wrote:

>>> I would argue fairly vehemently that a server explicitly indicating 
>>> it supports something is far more reliable than a UA believing the 
>>> server supports something based on a local config setting.
>>
>> Conclusion:

> This leads me to my opinion that just about any indicator at all the 
> UAC has that the first-hop proxy supports STUN-in-SIP is a good enough

---

From: Hisham Khartabil <[email-masked]>
Date: Fri, 11 Aug 2006 15:50:44 +0200

> get the information from the proxy before sending anything.

Rohan's proposal is exactly what you dont want: sending something just 
to find out if the receiver supports the protocol.

My opinion is that NOTHING should be mentioned in the internet draft 
about this at all. Its an implementation issue, imo, how a 
misconfigured UA should behave.

Hisham

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Fri, 11 Aug 2006 12:34:26 -0400

I think I said why I'm concerned, but let me re-state.

It is NOT because proxies won't be able to handle it.  Despite the fact that
history shows otherwise, I would hope proxies would do fine with binary
junk.  I do have a suspicion that some proxy or other won't, but that's
probably good for my business.  There is a question of what "fine" means,
but that's a separate issue. (IMO, blacklisting is the right thing to do,
but that's a decision for the vendor/operator)

My primary concern is that the IETF is using a message, which does not
conform to rfc3261/2543 syntax, to see if a rfc3261/2543 device supports
this new syntax.  That is wholly bad protocol practice, in my book.  The SIP
protocol has a mechanism to determine future-compatibility, but we're not
using it.  Why?  It's not complicated, and doing this stun is really bad
precedence.  And the benefits of doing it the right way are that some
3261/2543 devices have logging mechanisms for the require check mechanism,
so the operator can debug/troubleshoot it (or even learn such a draft
exists).

In terms of round-trips, Rohan's proxy-require method only adds one for
negative results.  A negative result for a stun message check is not 1
round-trip - it's not a round-trip at all - it's multiple stun messages from
the UAC to the proxy.  A negative result for a require check is 1 round
trip.  Is there a performance difference?  I don't know; probably a nit. 
But round-trips are not my primary concern.  Nor should they be for you, I
would think.  If the UAC's configuration is correct, and the proxy does
support this, then there will be no round-trips.  It's only if the UAC's
config/discovery was wrong, and a round-trip is hardly a high price to pay
for that case.

The result of that require round-trip is an unambiguous negative
acknowledgement that the proxy really doesn't support stun.  Whereas a stun
check negative is an implicit assumption that the proxy doesn't - it could
very well be that the stun messages just got lost.  A UAC would have a tough
time figuring out the difference.  I don't know if the UAC would behave
differently, but making it ambiguous doesn't leave an option for this.

-hadriel

> Sent: Friday, August 11, 2006 8:42 AM
> To: Fredrik Thulin

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Fri, 11 Aug 2006 13:12:23 -0400

> to find out if the receiver supports the protocol.

On the contrary, Rohan's proposal uses the base protocol to find out if a
new protocol is supported.  That's a big difference from just trying the new
protocol and seeing what happens.  RFC 3261 has a defined syntax to discover
if the 3261-compliant device supports something new, if it must support the
new thing for it to work properly.  That is exactly the case here.  We
require the proxy to support stun.  

Why do we have Supported, Accept and Allow headers?  Just try whatever it is
and see if it works. (not exactly analogous, but you get the idea)

Don't get me wrong - I want to be VERY conservative with using proxy-require
and require headers.  But if anything qualifies for it, this case does IMO.

-hadriel

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Fri, 11 Aug 2006 13:36:48 -0400

> I don't care

I don't understand how a proxy-require option tag is considered complex,
when one has to implement the other changes in this draft.
I have a very strong suspicion the coding, testing, and documentation for it
would take less text and time than the emails generated thus far about it. 
:)

-hadriel

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 11 Aug 2006 22:01:04 -0700

> Bad Hisham! No biscuit! None for me either!

It's not a biscuit - we have cookies around here. Oops now I am off  
topic too - bad fluffy.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 11 Aug 2006 22:12:16 -0700

On Aug 11, 2006, at 6:02 AM, Christer Holmberg ((JO/LMF)) wrote:

> the protocol in the first place.

I will point out that when a UA is configured to send requests to  
sip:example.com:5060 the way we find out if that port on that machine  
supports SIP is by sending a SIP request to it. I'm not sure I fully  
grasp the difference here. However, have you thought about Bob's  
proposal - it seems like it might be the thing that everyone can live  
with.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 11 Aug 2006 22:10:07 -0700

> when one has to implement the other changes in this draft.

The problem is not the proxy-require. The problem is the proxy  
removing things from the proxy-require header.

Have you considered the solution that Bob proposed for this. It did  
not have this problem of modifying the proxy require and it seem to  
solve all of your concerns.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 11 Aug 2006 22:47:54 -0700

More inline but my meta level comment is, would the proposal Bob was  
talking about solve all the things you bring up here - I suspect it  
would.

> in the mailing list and counted you into a wrong camp:

Hmm, I think when you add in the people that gave their opinion in  
the WG meeting you add a few people who thought the draft need to be  
changed and a very large number of people who would rather see up  
leave the draft as is so we could get it done.

> 	parameter. Perhaps badly designed UA, but possible.

This was mention at at least two IETF meetings now and every time I  
have requested, as I will ask you now, please send text to add to the  
draft that tell UA implementors not to do that. I'm sure this sort of  
text would improve the draft.

> 	- UA might be configured by the user incorrectly

Bob's proposal nicely deals with all these issues.

> 	  with wide deployment this concern can be ignored.

I don't think this is the same deployment model as sec-agree and I  
don't think sec-agree works as well as you think it works. I think I  
outlined issues with this before so won't rehash. Various people have  
expressed concern that allowing deletion of things from proxy-require  
would make it harder to add in upward negotiation of security  
features. Now in an IMS system, sec-agree provides some alternative  
to do this so it mitigates the issue by providing an alternative way  
to accomplish some of the stuff that is lost when using it. The  
proposal here does not.

>> anyway.
>> Perhaps you are worried about an outbound proxy that supports stun  
>> but
> a

It seem to me that this will not happen in any practical deployment.  
It only has this limitation if the user types in the outbound proxy  
to the UA. Now perhaps this is the part I am not understanding - is  
there some deployment of lots of UAs where this is likely to happen  
and I am just not thinking of it?

> 	  to both ends) compared to Proxy-Require solution

I'm surprised at this conclusion but will listen to what folks say on  
this.

---

From: <[email-masked]>
Date: Sat, 12 Aug 2006 08:49:16 +0300

Hi Cullen,

Just have a look into my long email on the subject
and issue 4 within it. In my email I explained like
this that why I do not believe it is a huge problem 
or if it would be a problem at all:

Regards,

Erkki 

>From: ext Cullen Jennings [mailto:[email-masked]] 
>Sent: 12.August.2006 08:10
>To: Hadriel Kaplan
>Cc: SIP; Fredrik Thulin

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Sat, 12 Aug 2006 10:19:49 +0200

Hi, 

>Just have a look into my long email on the subject and issue 4 within
it. In my email I explained like this that why I do 
>not believe it is a huge problem or if it would be a problem at all:
>
>The UA SHOULD add a Proxy-Require header field with the value
"sip-stun" to its REGISTER request. When the UA receives 
>200 OK with Supported: Outbound it can be sure that the next hop will
support STUN keepalives.

Yes. But please remember that STUN keepalive can be used without
outbound. So, the outbound proxy may support STUN keepalive, but the
registrar does not support outbound. In that case you may still want to
use STUN keepalive, but you will not get Supported: Outbound in the
registration response.

My proposal is still that the outbound proxy should be able to insert an
indicator in the REGISTER request/response, indicating to the UAC that
it supports STUN keep-alive.

Now, in addition to that Proxy-Require could still be used, if the UAC
wants to make sure the REGISTER doesn't reach the registrar unless the
outbound proxy supports STUN keepalive.

Regards,

Christer

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 12 Aug 2006 10:12:28 -0700

> if no values remain before forwarding the request to

My mistake - it was some of the other stuff that was looking more  
complicated. I agree this is very easy implement. I also think Bob's  
proposal is very easy to implement - if the outbound proxy came from  
DHCP or was manually configured on the UA, then do an OPTIONS message  
first.

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 10 Aug 2006 09:10:59 +0200

>proxy to stop them if the proxy cannot explicitly indicate support/not.

So you are saying that if a server is not broken and it properly offers its
capabilities, it is then under its power to stop clients from doing silly
things?

Also, the extra STUN overhead caused on boot-ups and reconnects in addition
to registration oveFrom [email-masked] Sat Aug 12 13:56:47 2006
Date: Thu, 10 Aug 2006 09:10:59 +0200
To: "Hadriel Kaplan" <[email-masked]>,
	"'Fredrik Thulin'" <[email-masked]>, <[email-masked]>
From: Jiri Kuthan <[email-masked]>
Subject: RE: [Sip] Outbound Issues: slides 3 and 4
Cc: 'Rohan Mahy' <[email-masked]>, 'Dean Willis' <[email-masked]>

>proxy to stop them if the proxy cannot explicitly indicate support/not.

So you are saying that if a server is not broken and it properly offers its
capabilities, it is then under its power to stop clients from doing silly
things?

Also, the extra STUN overhead caused on boot-ups and reconnects in addition
to registration overhead -- could you quantify how much worse it gets during
stateless processing on top of the database-heavy registrations?

>typically highly configurable in how they detect and handle such things)

Why do you think this is a critical performance issue?

I somehow fail to see why we should build in extra negotiation complexity
when a client can just send a packet or few and see what happens. Servers
have to deal with load anyhow and the relative contribution of STUN to
the load appears rather marginal to me.

-jiri

--
Jiri Kuthan            http://iptel.org/~jiri/

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 10 Aug 2006 08:58:30 +0200

>sucks just enough that people don't fix it but complain anyhow.

well, I think we will be receiving useless traffic anyhow so addressing
one of endlessly many sources of useless traffic doesn't bring us much
further. With public SIP sites, we experience about 80% of "silly traffic"
(caused typically by client/server misconfigurations and/or broken
implementations). Folks who run national DNS servers shared with me
similar numbers for DNS. Implementations have to be ready to deal with
unwanted silly traffic.

>>server supports this.  Most people don't seem to think this is  rhead -- could you quantify how much worse it gets during

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 10 Aug 2006 08:58:30 +0200

>black-list you" as the explanation for the SHOULD.

I think we may have a general protocol design question whether to do 
some negotiation stuff or just try-and-error. I personally prefer the
latter for sake of simplicity. That means I agree totally on three and
I prefer not to do 1 or 2.

-jiri

>black-list you" as the explanation for the SHOULD.

I think we may have a general protocol design question whether to do 
some negotiation stuff or just try-and-error. I personally prefer the
latter for sake of simplicity. That means I agree totally on three and
I prefer not to do 1 or 2.

-jiri

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Sat, 12 Aug 2006 16:22:54 -0400

Hey Jiri, comments inline...

> From: Jiri Kuthan [mailto:[email-masked]]
>
> failure

I assume you mean if the server properly indicates it does not support stun,
can it then stop a UA from sending stun?   Of course not, if the UA is
broken.  Any proxy worth its salt has to be designed and implemented
defensively, IMO, and needs to handle that locally.  But that's not my
point.  My point is that what a non-stun proxy does in that case is
unknowable/undefined, but at least that case is one where a device (the UA)
is broken.  An IETF standard should account for that if possible, within
reason, but to make the "broken" case the default mechanism for checking
this is simply not the same thing.

When I say "it's under the power of the proxy owner to stop them", I mean
assuming the UA is NOT broken.  I would think a standard protocol would be
written for operation under the "it's not broken" pretense, else we'd go
nowhere.  If we make the stun checking the default check, then a non-broken
outbound UA checking a non-broken rfc 3261 proxy has undefined behavior, for
the proxy.  That is not the case for a proxy-require mechanism.

> stateless processing on top of the database-heavy registrations?

Of course not - that would be implementation dependent.  Nor did I say
performance was an issue I was concerned with. (others may have)  I said it
would not be explicitly stoppable by the proxy every time (again assuming a
non-broken UA), and by that I simply meant that this undefined behavior of a
3261-compliant proxy will happen more than once, whatever it may be. 

Maybe your point is that parsing a Register, detecting an unsupported
proxy-require, and generating a 420 response is heavier than receiving some
malformed messages and discarding them?  That's a fair argument, though
undoubtedly implementation dependent.  I (naively) assume some proxies check
the proxy-require before dipping a DB, but even then it's still probably
heavier.

You build stateless 3261-compliant proxies - is this performance issue the
case?  Is it enough of a performance issue that you care, considering this
only happens at UA reboot/reconnect in the normal case?  I am certain
stun-checking (using stuns) will be less performance impact on my product.
But I don't care - it won't outweigh the benefits of providing better
troubleshooting ability for my customers.  A proxy-require in a Register
provides a lot of valuable information - such as the AoR that tried this,
what it was requiring, etc. 

And it won't outweigh the benefits to SIP as a technology if we keep other
proxies from crashing or whatever.  I know you may not believe I have the
interests of SIP as a technology at heart ;), but the best assurance I can
give you of this is that every time a CERT gets issued, my company benefits.
It is in my best monetary interest to have that happen, so in my best
interest that we do no checking whatsoever.  But I don't want it to happen,
because SIP needs to be perceived by the general public and media as a sound
protocol. (And that's also in my monetary interest, so you can think of that
as my incentive if you wish)

> Why do you think this is a critical performance issue?

It's not - I'm not concerned with performance for this.  I was just pointing
out it would be more than 1 packet, because the previous statement said it
would be bad behavior to blacklist on "1" malformed packet.  I was just
being annoyingly specific really.  :)

-hadriel

---

From: Rohan Mahy <[email-masked]>
Date: Sat, 12 Aug 2006 16:23:05 -0700

> to find out if the receiver supports the protocol.

I am confused.  The proposal the started this thread was to *include* a 
Proxy-Require when the UAC sends its first message.  If the UAC was 
properly configured, this adds no additional overhead.

The proposal that Dean and Cullen made subsequently is "try it once and 
see".  Again, if the UAC is properly configured, there is no extra 
overhead.

What part of these two proposals is not OK for you?

thanks,
-rohan

---

From: Dean Willis <[email-masked]>
Date: Sat, 12 Aug 2006 20:04:20 -0500

> DHCP or was manually configured on the UA, then do an OPTIONS message 

Yay!

How about we say:

Either do 1 or 2 below, then always do 3:

1) Probe the proxy with OPTIONS to verify that it supports STUN

or

2) Use a Proxy-Require as above

and

3) if you don't get a STUN response, stop using STUN on this target (and 
I'd be happy to see this in STUN, not Outbound!)

--
Dean

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Sat, 12 Aug 2006 23:07:01 -0400

> I'd be happy to see this in STUN, not Outbound!)

Sounds great!
I assume (2) means in the first Register. 
For (3) you need to specify how many stun attempts before giving up. (3
tries?) 

-hadriel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 13 Aug 2006 02:25:57 -0400

I can live with that.
Joel

At 09:04 PM 8/12/2006, Dean Willis wrote:
>>complicated. I agree this is very easy implement. I also think 
>>Bob's proposal is very easy to implement - if the outbound proxy 
>>came from DHCP or was manually configured on the UA, then do an 
>>OPTIONS message first.
>
>
>Yay!
>
>
>How about we say:
>
>3) if you don't get a STUN response, stop using STUN on this target 
>(and I'd be happy to see this in STUN, not Outbound!)
>
>--
>Dean
>

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 13 Aug 2006 11:06:48 +0200

Slightly modified proposal:

1) UA MUST verify that the proxy supports STUN before sending it
2) UA MUST stop sending STUN if no response (with reasonable defined retry 
interval, perhaps next boot?)

For (1) we then have 2 defined alternatives:
1a) using OPTIONS
1b) using Proxy-Require

but in addition, we should allow for alternative indications/mechanisms that 
may be defined in future drafts (such as a flag in Service-Route)

Regards,

Jeroen

----- Original Message ----- 
From: "Joel M. Halpern" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, August 13, 2006 8:25 AM
Subject: Re: [Sip] Outbound Issues: slides 3 and 4

>>>proposal is very easy to implement - if the outbound proxy came from DHCP 
>>>or was manually configured on the UA, then do an OPTIONS message first.
>>
>>
>>Yay!
>>
>>
>>How about we say:
>>

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Sun, 13 Aug 2006 12:32:26 +0200

Hi, 

>>on sending something somewhere just to find out if the reciever 
>>supports the protocol in the first place.
>
sip:example.com:5060 the way we find out if that port 
>on that machine supports SIP is by sending a SIP request to it. I'm not
sure I fully grasp the difference here. 

The difference is the following: 

If your UA is configured with a SIP address, the UA assumes SIP is
supported.

But, if it is not possible to configure (e.g. If the UA only gets the IP
address of the outbound proxy) whether the outbound proxy supports STUN
or not, I think it's bad that the UA shall start sending STUN requests
in order to find out whether the outbound proxy supports STUN or not.

>However, have you thought about Bob's proposal - it seems like it might
be the thing that everyone can live with.

I'll comment that separately.

Regards,

Christer

---

From: Dean Willis <[email-masked]>
Date: Sun, 13 Aug 2006 11:17:30 -0500

Jeroen van Bemmel wrote:
> 2) UA MUST stop sending STUN if no response (with reasonable defined 
> retry interval, perhaps next boot?)
> 
> but in addition, we should allow for alternative indications/mechanisms 
> that may be defined in future drafts (such as a flag in Service-Route)
> 

works for me.

--
Dean

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 13 Aug 2006 16:03:28 -0700

> in order to find out whether the outbound proxy supports STUN or not.

100% agree - I don't think the draft suggest this. I would be happy  
to add explicit text to the draft to say don't even think of doing  
something like this if that is causing confusion for people.

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 14 Aug 2006 08:48:11 +0200

4) If you get an indication in the REGISTER response that STUN keepalive
is supported by the outbound proxy, you may start sending STUN requests.

Regards,

Christer

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: 13. elokuuta 2006 4:04
To: Cullen Jennings
Cc: [email-masked]; [email-masked]
Subject: Re: [Sip] Outbound Issues: slides 3 and 4

Cullen Jennings wrote:
>> "sip-stun" to its REGISTER request. When the UA receives 200 OK with 
>> Supported: Outbound it can be sure that the next hop will support 
>> STUN keepalives.
>>
>> The proxy MUST remove the "sip-stun" value from the Proxy-Require 
>> header field and then remove the header if no values remain before 
>> forwarding the request to the next hop.
> 

Yay!

How about we say:

or

and

--
Dean

---

From: Fredrik Thulin <[email-masked]>
Date: Mon, 14 Aug 2006 08:59:05 +0200

On Monday 14 August 2006 08:48, Christer Holmberg (JO/LMF) wrote:
> 4) If you get an indication in the REGISTER response that STUN
> keepalive is supported by the outbound proxy, you may start sending
> STUN requests.

You won't get any STUN responses (Dean's no. 3) unless you send STUN 
requests. 

Do you, by the above, mean that if you get an indication in the REGISTER 
response from the outbound proxy that it supports STUN, then it is 
_always_ OK to periodically send STUN requests, even if no STUN 
response is received?

This sounds odd, so please clarify. Did you perhaps mean to extend 
Dean's proposal into "do either 1, 2 or 4 and always do 3"?

/Fredrik

On Sunday 13 August 2006 03:04, Dean Willis wrote:
...

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 14 Aug 2006 09:04:05 +0200

Hi, 

requests. 

I don't think I've said that... I am talking about the SIP REGISTER
response.

>Do you, by the above, mean that if you get an indication in the
REGISTER response from the outbound proxy that it supports STUN, then it
is _always_ OK 
>to periodically send STUN requests, even if no STUN response is
received?

No, but if the UA gets an indication in the REGISTER response you can
assume the outbund proxy supports STUN keepalive, and can start sending
STUN towards the outbound proxy. But, of course, if it doesn't get a
STUN response, it STOPS.

Hopefully this clarifies.

Regards,

Christer

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 14 Aug 2006 09:42:14 +0200

Hi, 

>>But, if it is not possible to configure (e.g. If the UA only gets the 
>>IP address of the outbound proxy) whether the outbound proxy supports 
>>STUN or not, I think it's bad that the UA shall start sending STUN 
>>requests in order to find out whether the outbound proxy supports STUN

>>or not.
>>
>100% agree - I don't think the draft suggest this. I would be happy to
add explicit text to the draft to say don't even think of doing
something like 
>this if that is causing confusion for people.

I don't think the draft suggests it either, but I have heard proposals
like that.

Regards,

Christer

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 14 Aug 2006 11:23:32 +0200

>something like this if that is causing confusion for people.

why?

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 14 Aug 2006 11:23:32 +0200

why?

-jiri

---

From: Hisham Khartabil <[email-masked]>
Date: Mon, 14 Aug 2006 11:53:07 +0200

Why not just do 3? If 1 or 2 doesn't give you that guarantee and you 
still need to build into your client an error handling code, you might 
as well just do 3 by itself.

Hisham

---

From: Hisham Khartabil <[email-masked]>
Date: Mon, 14 Aug 2006 11:50:26 +0200

On Aug 13, 2006, at 1:23 AM, Rohan Mahy wrote:

>>> supports
>> Rohan's proposal is exactly what you dont want: sending something 
>> just to find out if the receiver supports the protocol.
>
> I am confused.  The proposal the started this thread was to *include* 
> a Proxy-Require when the UAC sends its first message.  If the UAC was 
> The proposal that Dean and Cullen made subsequently is "try it once 
> and see".  Again, if the UAC is properly configured, there is no extra 
> overhead.
>

I'm not OK with any proposal. As I said, I think this is an 
implementation issue and the draft should say nothing about it.

Hisham

---

From: <[email-masked]>
Date: Mon, 14 Aug 2006 15:38:58 +0300

Hi,

>I prefer not to do 1 or 2. 

I have a comment not directly related to those arguments you gave
but anyway an extra reason for the Outbound draft to provide a safe
and deterministic check if the proxy is compliant to the draft or not.
This reason is not mentioned in this thread but I would like to point
it out now.

Before the Montreal meeting Jonathan Rosenberg outlined an idea how
an UA could automatically discover servers supporting Outbound within
a domain. He described his idea in this email:

http://www1.ietf.org/mail-archive/web/sip/current/msg15155.html

Shortly the idea was that the home proxy of the domain would
redirect the REGISTER request towards proxies supporting 
Outbound, by sending a 305 response. Proxy would also use
Service-Route and Additional-Proxies headers to indicate
proxies that UA could use.

In my understanding, this solution would require the UA to 
be able to find out if the contacted Proxy supports or does
not support Outbound, just in the case where the proxy did not
return 305, but instead 200 OK:

- Was it so that the contacted proxy supports outbound and
  the network does not require the UA to contact any additional
  proxy, so that everything is fine when receiving 200 OK that 
  does not contain Additional-Proxies header ? In this case
  the UA can perfectly well start sending STUN keepalives
  towards the proxy.

- Or was it so that the proxy supports neither outbound
  nor this new optional draft and therefore did not return 305 
  or Additional-Proxies header ? In this case UA could
  make a false assumption and continue using outbound even if
  that would not work.

Thus to make this distinction the UA has to be able to do the
check, preferrably by using the Proxy-Required header as 
described earlier in this thread.

Regards,

Erkki

>From: ext Jiri Kuthan [mailto:[email-masked]] 
>Sent: 10.August.2006 09:59
>To: Dean Willis; Cullen Jennings
>Subject: Re: [Sip] Outbound Issues: slides 3 and 4 - the problem ...
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Aug 2006 09:42:55 -0400

> that may be defined in future drafts (such as a flag in Service-Route)

I gather that 1a, 1b, ... 1x *all* must be supported by the proxy?

If so, what is the advantage of having more than one way?

The Proxy-Require approach (1b) can be piggy backed on a message that 
was going to be sent anyway, eliminating extra messages. If no other 
message was going to be sent anyway, then it could be used with OPTIONS. 
I suppose sending an OPTIONS without the Proxy-Require would achieve the 
same result, and doesn't really require any different support in the 
proxy. But if that encourages some UAC implementors to use 1a when they 
could have used 1b, then it just puts a little bit of extra load on the 
proxy for no reason.

An advantage of Proxy-Require is that it can be used all the time. Thus, 
should a change occur in network connectivity that results in a 
different proxy instance being contacted, it too will be checked. While 
the likelihood is very small of such a change occurring and resulting in 
a difference in support of stun, it is still an advantage to keep checking.

	Paul

> Regards,
> 
> Jeroen
> 
> ----- Original Message ----- From: "Joel M. Halpern" 
> <[email-masked]>
> To: <[email-masked]>
>>>> DHCP or was manually configured on the UA, then do an OPTIONS 
>>>> message first.
>>>
>>>
>>> Yay!
>>>
>>>
>>> How about we say:
>>>

---

From: Hisham Khartabil <[email-masked]>
Date: Mon, 14 Aug 2006 17:58:49 +0200

Many, but why is this the special case? Do we want to specify ALL 
misconfigurations in the UA and standardise a mechanism for recovery?

Hisham

On Aug 14, 2006, at 4:58 PM, Dean Willis wrote:

>
> On Aug 14, 2006, at 4:50 AM, Hisham Khartabil wrote:
>
>
>>
> Hold on a sec, Hisham. How many times have "implementation issues" 
> that related to incompletely specified behavior in some RFC turned out 
> to be a problem for your real-world deployments? My hunch is that this 
> happens fairly often, given the questions I see coming back from 
> network operators.
>
> --
> Dean
>

---

From: Dean Willis <[email-masked]>
Date: Mon, 14 Aug 2006 09:58:19 -0500

Hold on a sec, Hisham. How many times have "implementation issues"  
that related to incompletely specified behavior in some RFC turned  
out to be a problem for your real-world deployments? My hunch is that  
this happens fairly often, given the questions I see coming back from  
network operators.

--
Dean