Subject: Re: [Sip] Ready for WGLC on Outbound?

From: Rohan Mahy <[email-masked]>
Date: Mon, 3 Jul 2006 17:09:54 -0700

Hi Erkki,

The only time a UAC sends a STUN request as directed by outbound -04 is 
when the URI in the outbound-proxy-set includes the keepalive=stun 
parameter.  This is 100% backwards safe.  We don't need any text to 
prevent existing implementations from getting a bunch of STUN requests.

That DHCP does not provide URI is a limitation of the SIP DHCP 
configuration mechanism, not outbound.  The same problem exists for the 
"comp" parameter for example.  If you want to write a draft on how to 
"shift-up" to using keepalives or using compression from some SIP or 
external stimulus, you can still do this.  No text in outbound prevents 
that from happening.

thanks,
-rohan

On Jun 29, 2006, at 23:10, <[email-masked]> wrote:
>
> Hi Rohan,
>
>>> Also, the issue is that what may be configured (no matter how you
>>> configure it) may not be a URI. It may simply be an IP address/FQDN,
>>> which is then used to build a SIP-URI. I think we shall
>>> allow that, and make it more clear in the spec. [/CHH]
>>
>> the outbound spec defines a piece of configurable data (the
>> 'outbound-proxy-set'), which is a list of URIs.  This list of URIs may
>> never have a one-to-one correspondence to a user or administrator
>> manually configurable field.  That piece of configurable data may be
>> derived from several fields, manually configurable, discovered via
>> DHCP, DNS, the config package, P-Whatchamacallit headers, HTTP
>> download, or via a random character generator seeded by the phase of
>> the moon.
>>
>> The outbound-proxy-set was defined as a list of URIs because the UA
>> acts on each item in the list, because each URI is expected to be
>> places in a Route header, and because each URI is expected to
>> typically have a keepalive URI parameter in it.
>
> Like mentioned in other recent emails the problem is that if the UA
> derives the proxy URI(s) from DHCP SIP server option or e.g. the AOR
> of the user, in those cases the derived URI will NOT contain the
> keepalive URI parameter in it. DHCP just returns IP addresses or
> domain names instead of URIs with parameters.
>
> Thus in those cases it would be critical for the UA to be able
> to ensure in REGISTER - 200 OK sequence that the contacted proxy
> supports Outbound and can handle STUN requests sent to its SIP
> port (not to cause any damage to an uncompliant proxy). I fully
> agree with this proposal from Jeroen:
>
> --
> The text should then say "the UAC MUST wait for a 200 OK to REGISTER
> before
> it starts sending STUN packets. If the last Path header of the 200 OK
> does
> not contain keepalive=stun, the UAC MUST NOT use STUN towards this URI.
> If
> there are no Path headers and no "Supported: outbound", the UAC also
> MUST
> NOT use STUN towards the registrar.". It could still use TCP keepalive
> if it
> supports that
> --
>
> Please excuse me if I am just repeating myself and what e.g. Jeroen
> has said but I believe the importance of this issue justifies some
> redundancy :-)
>
> Regards,
>
> Erkki

_______________________________________________
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: <[email-masked]>
Date: Tue, 4 Jul 2006 13:50:19 +0300

Hi Rohan,

Sorry to be persistent with this issue, but what you say
seems to conflict with what was discussed in March.

> The only time a UAC sends a STUN request as directed by 
> outbound -04 is when the URI in the outbound-proxy-set 
> includes the keepalive=stun parameter. That DHCP does not 
> provide URI is a limitation of the SIP DHCP configuration 
> mechanism, not outbound. If you want to write a draft on 
> how to "shift-up" to using keepalives from some SIP or 
> external stimulus, you can still do this.

What you say seems to suggest that you agree there is a problem
when using DHCP SIP server option (as it is currently defined)
for finding out if the discovered proxy supports outbound and
STUN keepalives, but the solution is not in scope of Outbound
draft itself. 

However I came to a different understanding based on the emails
seen in the list earlier. For instance this email from Dean
Willis (SIP WG chair) seems to suggest that the problem should
be in scope of the outbound draft:
http://www1.ietf.org/mail-archive/web/sip/current/msg13667.html

"Ok, I think we've boiled this down to a new requirement:

for the "outbound" technique to work, we MUST have a means of 
discovering whether a proxy supports the extensions of outbound.

While we could do that by doing a REGISTER exchange that includes 
an appropriate option-tag in Require:, it would be more efficient 
if the proxy discovery mechanism informed us of this detail. So, 
we posit that the Outbound draft SHOULD select and discuss such a 
mechanism."

And in yet another email
http://www1.ietf.org/mail-archive/web/sip/current/msg13692.html
Dean tells this:

"There are two ways we can establish compatibility with an extensions:

1) By foreknowledge
2) By experimentation -- try it and see if it works.

Both have limitations:

In the case of #1, we might have incorrect knowledge. So we'll probably
end up testing anyhow . . .

In the case of #2, the experiment might cause a meltdown. So the "probe
for discovery" must be made completely safe. Also, we can eventually end
up with so many wierd hooks and idiosyncratic implementations that we
end up doing a BUNCH of probing before we do any real communicating. And
it's possible for the conditions to deteriorate so much that probes for
two different possible conditions are mutually exclusive -- if one
condition applies, the probe for another will cause a meltdown.

So what happens if we start STUN-probing a proxy on its SIP port and it
doesn't support STUN? My guess is, it's random. 

...

One approach to "forward compatibility" design is to make sure that we
can use both foreknowledge and experimentation -- the "trust but verify"
model.

...

While it's easy to decide whether a configured registrar URI has a
keepalive parameter, what happens to proxies we select based on
something besides direct configuration?

Specifically,

1) Can the DHCP option for default proxy present the keepalive
parameter?"
----

During these three months after seeing those comments in the list
I have been expecting the outbound draft to provide answer to
the question how UA could (within SIP signalling exchange)
safely to check whether or not a proxy supports STUN keepalive.
Two mechanims have been suggested how the UA could do this in
a simple way:

1. The UA to check that the Path header in 200 OK returned for
   REGISTER would contain keepalive=stun parameter for the proxy URI

2. The UA to add Proxy-Reequire: stun-keepalive parameter into
   the REGISTER request and the proxy to remove this tag from
   the request before forwarding it towards the registrar

For me, any of those mechanisms would sound feasible and for
safety reasons I would hope the draft to deny the UA for sending
STUN keepalives to the proxy which did not pass such a test.

> the same problem exists for the "comp" parameter for example. 

Yes but please bear in mind that for comp=sigcomp URI parameter
RFC 3486 Compressing SIP gives several solutions how the UA
would be able to check if the proxy supports SigComp while
outbound does not define any other than relying on configuration. 
A cite from RFC 3486:

4.1   Obtaining a SIP or SIPS URI with comp=sigcomp

   For requests within a dialog, a next-hop URI with the comp=sigcomp
   parameter is obtained from a Record-Route header field when the
   dialog is established.  A client sending a request outside a dialog
   can also obtain SIP URIs with comp=sigcomp in a Contact header field
   in a 3xx or 485 response to the request.

   However, clients establishing a session will not typically be willing
   to wait until the dialog is established in order to begin compressing
   messages.  One of the biggest gains that SigComp can bring to SIP is
   the ability to compress the initial INVITE of a dialog, when the user
   is waiting for the session to be established.  Therefore, clients
   need a means to obtain a comp=sigcomp URI from their outbound proxy
   before the user decides to establish a session.

   One solution to this problem is manual configuration.  However,
   sometimes it is necessary to have clients configured in an automatic
   fashion.  Unfortunately, current mechanisms for SIP client
   configuration (e.g., using DHCP [6]) do not allow to provide the
   client with URI parameters.  In this case, the client SHOULD send an
   uncompressed OPTIONS request to its outbound proxy.  The outbound
   proxy can provide an alternative SIP URI with the comp=sigcomp
   parameter in a Contact header field in a 200 OK response to the
   OPTIONS.  The client can use this URI for subsequent requests that
   are sent through the same outbound proxy using compression.

   RFC 3261 [1] does not define how a proxy should respond to an OPTIONS
   request addressed to itself.  It only describes how servers respond
   to OPTIONS addressed to a particular user.  Section 11.2 of RFC 3261
   says:

      Contact header fields MAY be present in a 200 (OK) response and
      have the same semantics as in a 3xx response.  That is, they may
      list a set of alternative names and methods of reaching the user.

   We extend this behavior to proxy servers responding to OPTIONS
   addressed to them.  They MAY list a set of alternative URIs to
   contact the proxy.

What has been called for is that outbound draft would also 
specify one solution how the UA could check the STUN keepalive
support of a proxy. In my opinion good proposals seem
to exist how to do it in a reasonable way.

Regards,

Erkki

>-----Original Message-----
>From: ext Rohan Mahy [mailto:[email-masked]] 
>Sent: 04.July.2006 03:10
>To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki)
>Cc: [email-masked]; [email-masked]; Rohan Mahy; 
>[email-masked]; [email-masked]
>Subject: Re: [Sip] Ready for WGLC on Outbound?
>
>Hi Erkki,
>

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 4 Jul 2006 13:37:16 -0700

I think people have stopped posting on this because they can't say  
anything that they have not already said. Don't take that as they agree.

We got very strong feed back on one point - don't send STUN messages  
to a proxy unless you know it supports them. People felt strongly  
about that - I don't know why - but there was lots of people that  
agreed with that.

I imagine people have sent me around 10 options on how to get the  
stun supported information and the set of outbound proxy URIs -  
certainly DNS and DHCP are some of them. We can write some drafts on  
various ways to do it. Right now my concern is making sure that no  
matter which of these many ways the WG decided to move forward with,  
outbound will work. So far every one of the possibilities I have  
heard would be possible with the current outbound. Given that, I'm  
not sure what we need to change in outbound. I'm not even sure what  
you are proposing that we change in outbound - I think what you are  
proposing is we need to hold up outbound until we choose which one of  
the 10 we will use and furthermore you feel very strongly on which  
one of the 10 we should use. I'm not keen on this - I think we have  
shown they are separable problems. The WG decided on this separation  
of problems awhile back - I think it was in Vancouver - and many  
people supported it. I think it was a good idea  - we have shown we  
can move outbound forward before we have determined all the ways that  
this configuration information is delivered to the UA. I would be  
very hesitant to reverse this decision now.

I don't think Dean's posts were sent as decries of the requirements  
from the chair but purely as his opinion in trying to help bring the  
discussion to consensus. But I do think the draft meets the  
requirements and ideas he was outlining - I think the current draft  
does meet the requirements he outlines. It does have a way for the  
"discovering whether a proxy supports the extensions of outbound" and  
on the topic of "there are two ways we can establish compatibility  
with an extensions", the WG rejected option 2 and we have gone with 1.

Cullen (with my outbound author hat on)

On Jul 4, 2006, at 3:50 AM, <[email-masked]>  
<[email-masked]> wrote:

>> outbound -04 is

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 4 Jul 2006 23:34:48 +0200

Cullen,

The point is that these are really 2 separate issues:
1. Discovering the set of outbound proxy URIs (with keepalive=stun 
parameters in them)
2. Confirming that a given proxy in the set actually supports outbound (ie 
validating the keepalive=stun information)

Of these 2 options, (1) is indeed a separable problem. (2) - to me - is not, 
for me outbound is not acceptable without something to address (2). It 
really should say "the UAC MUST NOT use STUN until { mechanism for (2) says 
its supported }"

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?

Regards,

Jeroen

----- Original Message ----- 
From: "Cullen Jennings" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Sent: Tuesday, July 04, 2006 10:37 PM
Subject: Re: [Sip] Ready for WGLC on Outbound?

> We got very strong feed back on one point - don't send STUN messages  to a 
> proxy unless you know it supports them. People felt strongly  about that - 
> I don't know why - but there was lots of people that  agreed with that.
>
> I imagine people have sent me around 10 options on how to get the  stun 
> supported information and the set of outbound proxy URIs -  certainly DNS 
> and DHCP are some of them. We can write some drafts on  various ways to do 
> it. Right now my concern is making sure that no  matter which of these 
> many ways the WG decided to move forward with,  outbound will work. So far 
> every one of the possibilities I have  heard would be possible with the 
> current outbound. Given that, I'm  not sure what we need to change in 
> outbound. I'm not even sure what  you are proposing that we change in 
> outbound - I think what you are  proposing is we need to hold up outbound 
> until we choose which one of  the 10 we will use and furthermore you feel 
> very strongly on which  one of the 10 we should use. I'm not keen on 
> this - I think we have  shown they are separable problems. The WG decided 
> on this separation  of problems awhile back - I think it was in 
> Vancouver - and many  people supported it. I think it was a good idea  - 
> we have shown we  can move outbound forward before we have determined all 
> the ways that  this configuration information is delivered to the UA. I 
> would be  very hesitant to reverse this decision now.
>
> I don't think Dean's posts were sent as decries of the requirements  from 
> the chair but purely as his opinion in trying to help bring the 
> discussion to consensus. But I do think the draft meets the  requirements 
> and ideas he was outlining - I think the current draft  does meet the 
> requirements he outlines. It does have a way for the  "discovering whether 
> a proxy supports the extensions of outbound" and  on the topic of "there 
> are two ways we can establish compatibility  with an extensions", the WG 
> rejected option 2 and we have gone with 1.
>

---

From: Ben Campbell <[email-masked]>
Date: Tue, 4 Jul 2006 23:10:28 -0500

I've been a  bystander, but will jump in here. Comment below:

On Jul 4, 2006, at 3:37 PM, Cullen Jennings wrote:

> We got very strong feed back on one point - don't send STUN  
> messages to a proxy unless you know it supports them. People felt  
> strongly about that - I don't know why - but there was lots of  
> people that agreed with that.
>
> certainly DNS and DHCP are some of them. We can write some drafts  
> on various ways to do it. Right now my concern is making sure that  
> no matter which of these many ways the WG decided to move forward  
> with, outbound will work. So far every one of the possibilities I  
> have heard would be possible with the current outbound. Given that,  
> I'm not sure what we need to change in outbound. I'm not even sure  
> what you are proposing that we change in outbound - I think what  
> you are proposing is we need to hold up outbound until we choose  
> which one of the 10 we will use and furthermore you feel very  
> strongly on which one of the 10 we should use. I'm not keen on this  
> - I think we have shown they are separable problems. The WG decided  
> Vancouver - and many people supported it. I think it was a good  
> idea  - we have shown we can move outbound forward before we have  
> determined all the ways that this configuration information is  
> delivered to the UA. I would be very hesitant to reverse this  
> decision now.

I strongly agree with Cullen. We do not need to block the outbound  
mechanism draft on figuring out the discovery stuff. The separation  
was a good idea. If for no other reason, it lets us get work done.

> from the chair but purely as his opinion in trying to help bring  
> the discussion to consensus. But I do think the draft meets the  
> "discovering whether a proxy supports the extensions of outbound"  
> and on the topic of "there are two ways we can establish  
> compatibility with an extensions", the WG rejected option 2 and we  
> have gone with 1.
>

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 5 Jul 2006 10:05:04 +0300

> validating the keepalive=stun information)

i don't understand this one.  if a proxy is listed as an outbound proxy
(for example in the result returned from DNS), why can't we require that it
supports stun keepalives?

-- juha

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 5 Jul 2006 10:23:21 +0200

Juha,

Do you mean
A) you dont understand what I am trying to say
B) you dont see / agree that this is needed

Let me try to rephrase:

Currently deployed proxies generally do not support STUN, especially not on 
the same ports that they use for SIP. Sending a STUN packet to such a proxy 
could very well be harmless, but it could also cause it to crash.

Adhering to the principle "be strict in what you send", it is the UAC's 
responsibility to make reasonably sure that a proxy it is about to STUN can 
take it. "keepalive=stun" in the URI it received through configuration is 
likely a good indicator, depending on which provisioning mechanism is used. 
But *independent* of the provisioning mechanism, a confirmation from the 
proxy itself is better.

Sure, we can state "any proxy listed as outbound proxy MUST support STUN". 
We might even say "all proxies SHOULD support STUN". But no matter what 
requirements we come up with, they won't be met by currently deployed 
proxies.

Summarizing:
1 - there is an implicit requirement "MUST NOT break current deployments". 
For outbound, this includes "proxies that do not support STUN MUST NOT 
receive STUN packets" (could consider to include something like this as a 
9th requirement in section 12 of 
http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-04.txt)
2 - since we cannot influence all receivers, this translates into a 
requirement on the sender of STUN packets (the UAC): MUST NOT send STUN 
unless supported by target proxy
3 - to meet this requirement, we currently have "MUST check provisioned URI 
has keepalive=stun". It should say explicitly "if not, then MUST NOT send 
STUN to that URI"
4 - I am argueing: "MUST check provisioned keepalive=stun" is not 
sufficient, because the configuration may be incorrect (for various reasons, 
also depending on what you use for provisioning). As an additional check, we 
need "MUST check confirmation from proxy"

We cannot depend only on the configuration mechanism (which is still TBD, 
and in principle open ended)

Regards,

Jeroen

----- Original Message ----- 
From: "Juha Heinanen" <[email-masked]>
To: "Jeroen van Bemmel" <[email-masked]>
Cc: "Cullen Jennings" <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 05, 2006 9:05 AM
Subject: Re: [Sip] Ready for WGLC on Outbound?

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 5 Jul 2006 11:46:07 +0300

> could very well be harmless, but it could also cause it to crash.

sure, but those proxies are not outbound proxys and should not be listed
as such.  problem solved.

 > requirements we come up with, they won't be met by currently deployed 

if your currently deployed proxy is not outbound proxy as specified in
the i-d, you don't list it as such.  it is a regular proxy and can do
whatever is specified in rfc3261.

-- juha

---

From: <[email-masked]>
Date: Wed, 5 Jul 2006 13:44:24 +0300

Hi Cullen, Rohan and Dean,

>anything that they have not already said. Don't take that as 

This is the last email which I intend to post on this subject
(and hopefully I can keep that intention). The reason to keep on
posting is that I am unable to attend the IETF meeting in Montreal,
so I can only raise issues by email prior to the meeting and ask
those issues to be discussed as open questions in the WG meeting.
If this happens and the WG is able to reach a consensus in the meeting
as recorded to the minutes, that will be time for me to eventually 
shut up and outbound draft to move on for the WGLC.

>one of the 10 we should use.

Please do not understand me incorrectly. My intention is not to block or
delay the approval of outbound draft, I also feel that it is important
to get it approved as soon as possible, to be able to cope with the
NAT/FW traversal problems better than now. Further on I do not try
to push the outbound draft to contain a solution for outbound discovery,
but a safe probe that a UA could do in order to check that sending STUN
packets will do no harm for the proxy. I always believed that this was
a requirement for Outbound-04, based on the comments I saw on the list 
prior to and right after the Dallas meeting (revolving around the 
issue whether to use STUN or SIP PING as the keepalive mechanism). 
Finding that Outbound-04 did not provide a mechanism, I tried to 
raise the issue as soon as I could, to get it closed asap, believing
that it would be sufficient that the authors to select the mechanism
amongst the options available and add 1-2 related paragraphs to 
Outbound-05 before the WGLC. I still hope it could be done like
that and just try to be helpful to avoid one pitfall with the draft.

>The WG decided on this separation  

Even if I have been working on SIP for some years, I only joined
the WG (including [email-masked] follow-up) in the beginning of this
year, so I have not been aware of what was discussed and decided
earlier. So thanks for being updated. However I would tend to agree
with how Jeroen put it in his email (it is the issue 2 which I also
tried to highlight):

>2. Confirming that a given proxy in the set actually supports 
>outbound (ie validating the keepalive=stun information)
>
>Of these 2 options, (1) is indeed a separable problem. 
>(2) - to me - is not, for me outbound is not acceptable 
>without something to address (2).

The specific concerns that I have (and would like the WG to 
consider in the meeting) are closely related to what you told:

>We got very strong feed back on one point - don't send 
>STUN messages to a proxy unless you know it supports them. 

1. This is what Outbound-04 says on the subject:

   User Agents that form flows MUST check if the configured URI they are
   connecting to has a 'keepalive' URI parameter (defined in Section 10)
   with the value of 'stun'.  If the parameter is present, the UA needs
   to periodically perform keepalive checks by sending a STUN [I-D.ietf-
   behave-rfc3489bis] Binding Requests over the flow.

Does the WG consider checking the configured URI as a safe enough
check for the UA to ensure that the SIP proxy support STUN ?

In my opinion it is not. As an example a vendor X could implement
a compliant but bad UA which provides an option for the user to 
configure the settings via an User Interface e.g. like this:
"Is the phone behind a NAT: Yes/No". When the user selects
"Yes" the UA would add the keepalive=stun flag to the proxy URI
even if the user does not have a clue if the proxy actually
supports outbound or not. There is nothing in outbound draft
to prevent such unsafe implementations to appear.

2. draft-koivusalo-sip-outbound-discovery identified a security
threat like this:

   DNS NAPTR records are used to allow a client to discover that the
   server supports SIP Outbound.  An attacker could potentially modify
   these records, resulting the client to send STUN request to a proxy
   that does not support STUN requests in its SIP port.  This kind of
   attack could cause the proxy to behave in an unpredictable way and
   might cause it to crash.

   This kind of attack is prevented by a mechansim introduced within
   draft-ietf-sip-outbound [8].  When sending REGISTER request, the UA
   has to add an option tag to it, requiring the proxy to reject the
   request if it does not support SIP Outbound.

   [[Author's note: the mechanism to be used within REGISTER request is
   still to be decided.  After the decision is made the text above must
   be rewritten.]]

Without such a mechanism in outbound draft there is nothing to do
to migitate the identified threat.

3. There is a separate draft being written about how the UA could
automatically discover if a proxy supports outbound or not.
Someone could claim that using that draft would make up the "safe
check". However I do not think it would be wise the outbound draft
itself to rely on any such additional draft to be ever approved
or used. Outbound draft should be sufficiently self-contained so
that applying it would not requrire the UA or proxy vendor to 
implement some related draft (which might be available much
later if ever) to do some mandatory things.

I hope I was able formulate those concerns clearly enough so that
the WG members can draw their opinions on those and make a 
judgement whether or not this needs to be addressed in the 
outbound draft before WGLC.

It is in your hands now ;-)

Regards,

Erkki

>From: ext Jeroen van Bemmel [mailto:[email-masked]] 
>Sent: 05.July.2006 00:35
>To: Cullen Jennings; Koivusalo Erkki (Nokia-TP-MSW/Helsinki)
>Cc: [email-masked]; [email-masked]; [email-masked]
>messages  to a 
>requirements

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 5 Jul 2006 10:52:44 -0700

Jeroen,

I'd like to address this one point.  My recollection from Dallas is 
that we had a very strong consensus that the existence of 
keepalive=stun was sufficient to send STUN messages.

Based on this, I think we need to make it a requirement of the 
configuration mechanism that  you can depend on its result to have 
accurate keepalive information.

thanks,
-rohan

On Jul 5, 2006, at 1:23, Jeroen van Bemmel wrote:
> sufficient, because the configuration may be incorrect (for various 
> reasons, also depending on what you use for provisioning). As an 
> additional check, we need "MUST check confirmation from proxy"
>
> We cannot depend only on the configuration mechanism (which is still 
> TBD, and in principle open ended)

---

From: "Bob Penfield" <[email-masked]>
Date: Wed, 5 Jul 2006 14:48:10 -0400

inline
----- Original Message ----- 
From: "Rohan Mahy" <[email-masked]>
To: "Jeroen van Bemmel" <[email-masked]>
Cc: "Cullen Jennings" <[email-masked]>; "Rohan Mahy" <[email-masked]>; 
<[email-masked]>; "Juha Heinanen" <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 05, 2006 1:52 PM
Subject: Re: [Sip] Ready for WGLC on Outbound?

> Jeroen,
>
> I'd like to address this one point.  My recollection from Dallas is that 
> we had a very strong consensus that the existence of keepalive=stun was 
> sufficient to send STUN messages.
>

Does that mean that a UA should not send STUN if the keepalive=stun is not 
present?

If so, will outbound be useful prior to the completion of the various 
configuration mechanisms? And is it acceptable for a mis-configured UA to 
cause the proxy or the registrar to crash or mis-behave?

A mechanism such as the proposed Proxy-Require/Require method similar to 
sec-agree allows the UA to determine that the proxy and registrar support 
STUN before it sends and potentially harmful messages.

cheers,
(-:bob

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 6 Jul 2006 10:19:20 +0200

Hi,
 
This again brings up the question: should the whole usage of STUN for keep-alive be described in a separate draft? The outbound spec would then just refer to that.
 
Especially IF we can agree on the fact that the STUN keep-alive is a stand-alone feature (not necessarily always used together with outbound), I don't see why the STUN keep-alive mechanism is described in one draft, and then in another draft we describe how to detect whether a proxy supports it or not. Why not put everything in one draft, then?
 
Regards,
 
Christer

________________________________

From: Cullen Jennings [mailto:[email-masked]]
Sent: Tue 04/07/2006 22:37
To: <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Sip] Ready for WGLC on Outbound?

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 6 Jul 2006 18:11:13 +0200

Does a proxy supporting STUN keep-alive have to be an "outbound proxy" (assuming you mean an edge proxy), as defind in the outbound spec?
 
Or, what do you mean by "outbound proxy"? As defined in 3261?
 
Regards,
 
Christer

From: Juha Heinanen [mailto:[email-masked]]
Sent: Wed 05/07/2006 10:46
To: Jeroen van Bemmel
Cc: Cullen Jennings; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Sip] Ready for WGLC on Outbound?

-- juha

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 6 Jul 2006 19:09:33 +0200

Rohan,

> accurate keepalive information.

No, you cannot shift it off like that. Outbound is introducing binary STUN 
messages that could potentially harm existing systems, so outbound is 
responsible for providing reasonable safeguards. If it were an "ordinary" 
new SIP feature, then standard RFC3261 safeguards would provide sufficient 
protection. But STUN is different

The problem with a requirement like you propose here is twofold:
1) it is too soft, in the sense that you cannot test for it
2) Some configuration mechanisms (like manual configuration) simply cannot 
meet this requirement

Again, what is the reason that we should not include a mechanism for this? 
Do you feel it would make the draft too complex?

Regards,

Jeroen

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 06 Jul 2006 14:06:47 -0400

inline.

Jeroen van Bemmel wrote:

> 2. Confirming that a given proxy in the set actually supports outbound 
> (ie validating the keepalive=stun information)
> 
> Of these 2 options, (1) is indeed a separable problem. (2) - to me - is 
> not, for me outbound is not acceptable without something to address (2). 
> It really should say "the UAC MUST NOT use STUN until { mechanism for 
> (2) says its supported }"

I personally think that the presence of the keepalive=stun attribute in 
the URI is sufficient of a "confirmation". The examples you and others 
have presented for why this is needed are (1) misconfiguration (someone 
gives a URI to the client which is incorrect in that it contains this 
flag when it shouldn't), (2) malicious users, (3) constructed URIs. On 
(2), let me point out that an attacker that can modify DNS or modify SIP 
messages (or whatever is used for the discovery function) can launch far 
more effective attacks than just adding keepalive=stun in the hopes that 
it causes a low-quality proxy to crash.

On (1), misconfugration could potentially produce all kinds of things 
that would cause a client to send things to the server that might make 
it crash, including non-SIP URI, URI with invalid header parameters, 
etc. I don't see keepalive=stun as special.

On (3), this is definitely a possibility. However I think the best way 
to mitigate is to say 'don't do that'. SIP-outbound can have some words 
which warn implementations that they MUST NOT insert this parameter into 
URI that they construct from a domain name.

Finally, let me say that if you have a proxy that crashes on receipt of 
binary messages on its sip port, you are in for real trouble. I think a 
far better solution is for proxy vendors to fix their proxies, rather 
than for us to bend over backwards to design new mechanisms that help 
protect such fragile servers from ever seeing these messages. No matter 
what we put in our specs, attackers can still send binary messages that 
will result in the same result you are trying to prevent.

Thanks,
Jonathan R.

-- 
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: Ben Campbell <[email-masked]>
Date: Thu, 6 Jul 2006 13:26:56 -0500

On Jul 6, 2006, at 12:09 PM, Jeroen van Bemmel wrote:

> Rohan,
>
>> Jeroen,
>>
>> I'd like to address this one point.  My recollection from Dallas  
>> is that we had a very strong consensus that the existence of  
> No, you cannot shift it off like that. Outbound is introducing  
> binary STUN messages that could potentially harm existing systems,  
> so outbound is responsible for providing reasonable safeguards. If  
> it were an "ordinary" new SIP feature, then standard RFC3261  
> safeguards would provide sufficient protection. But STUN is different

I've been watching this train of reasoning for a while now, and am  
not sure I buy it. Do we really expect SIP devices to melt down if  
they get stun and don't expect it? If so, they are big targets for  
DoS attacks.

> 2) Some configuration mechanisms (like manual configuration) simply  
> cannot meet this requirement
>
> Again, what is the reason that we should not include a mechanism  
> for this? Do you feel it would make the draft too complex?
>
> Regards,
>
> Jeroen
>
>
>

---

From: Anders Kristensen <[email-masked]>
Date: Thu, 06 Jul 2006 15:18:50 -0400

> will result in the same result you are trying to prevent.

I would agree with this in the case of UDP or in other cases where the 
transport does the framing. It seems that for stream based transports 
unrecognized binary data could mess up framing. Proxies could try to 
recover but I don't know if it's reasonable to expect proxies to keep 
connections open for an extended period of time when all they see is a 
some garbage every 30 seconds or so. It's not necessarily that the proxy 
crashes but that it gives up on a particular connection at some point.

Thanks,
Anders

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 6 Jul 2006 22:38:05 +0200

> crashes but that it gives up on a particular connection at some point.

Yes, exactly! And for TLS a proxy might interpret it as an encryption 
failure, and trigger some anomaly detection system, and then blacklist the 
client. All of this can be prevented through a simple measure: have the 
proxy insert some flag. As mechanisms go, this to me hardly feels like 
bending over backwards.

None of this will help against malicious attackers, but it will work for UAs 
that are simply unaware. And it will also make debugging easier

Regards,

Jeroen

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 6 Jul 2006 23:12:58 +0200

[ snap ]
> Jonathan wrote
>
> I'm not objecting to the concept of this check. I just think its not 
> necessary, something that might be optional at best. As such, if folks 
> decide they want something, it can go in another draft. I dont think we 
> need to burden sip-outbound with this.
>

The trouble is, once outbound is "out" any mechanism defined in a separate 
draft won't work as good. Because then there will be clients that simply 
ignore the flag. We either MUST now, or MAY never fix it.

For the benefit of those amongst us with live systems, I am including a 
simple Java test program below so you can test the effect of a STUN binding 
request on your unsuspecting proxy (currently UDP only, trivial to adapt)

Regards,

Jeroen

import java.net.DatagramPacket;
import java.net.DatagramSocket;
import java.net.InetAddress;
import java.net.InetSocketAddress;
import java.net.SocketException;
import java.net.UnknownHostException;

/**
 * Tests what happens when a client sends a STUN Binding request over UDP
 * @author Jeroen
 */
public final class STUNClient {

 /**
  * @param args
  * @throws UnknownHostException
  * @throws SocketException
  */
 public static void main(String[] args) throws Exception {

  byte [] bindingRequest = new byte[ 20 ];
  bindingRequest[0] = 0x00;
  bindingRequest[1] = 0x01; // type: 0x0001
  bindingRequest[2] = 0x00;
  bindingRequest[3] = 0x00; // length: 0 (excl header)
  // 4..19: random 128-bit transaction id, lets take 0

  DatagramPacket p = new DatagramPacket( bindingRequest, 
bindingRequest.length,
   new InetSocketAddress(InetAddress.getLocalHost(),5060)
  );
  DatagramSocket s = new DatagramSocket();
  s.send( p );
  s.receive( p );
  System.out.println( p.getSocketAddress() );
 }

}

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 6 Jul 2006 17:37:12 -0400

I think we all agree every device _should_ handle a STUN message on the same
port just fine, and I assume vendors active in the IETF or going to SIPit
would do just that.  (whatever "handle fine" means to them)

However the difference between a malicious attacker or benevolent tester
doing it, and this draft, is this will be an IETF RFC from the sip WG
specifying the "attack" as part of a legit SIP mechanism. (and it's not RFC
4475 :)  Whereas this WG has added a Required header or some other check
mechanism for virtually any other extension I can think of where the
proxy/registrar is really required to support something, this one does not
have such a mechanism.  Why?

And it's not the same as just a new option-tag or header - this is a
backwards-compatibility breaker.  There is no defined action for a
3261-compliant device to take when receiving such a binary message, is
there?  It cannot "reject" it with a sip response, cannot make the UA stop
sending it, nor can the UA detect the proxy doesn't support it even if the
UA wanted to check.  The UA will detect a keepalive loss, and try
"re-connecting" by re-registering and getting another keepalive loss,
indefinitely (although at least with back-off timers).

Meanwhile the operator of this 3261-compliant proxy just got a headache
courtesy of the IETF.  For each user who mistakenly checks some little
check-box which says whatever the vendor thought it should say for a
keepalive=stun semantics the operator must take action to correct - if
they're lucky.  If they're unlucky, and their proxy silently discards the
stun, they'll wonder why some UAs can make/receive calls for ~30 seconds,
then disappear, then come back, ad infinitum.  And this is a bad kind of
failure to detect/fix, because a reboot makes it "work" for a short time.

-hadriel
p.s. a STUN request should really be added to the next
sipping-torture-rfc4475bis.

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Thursday, July 06, 2006 2:07 PM
> To: Jeroen van Bemmel

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 06 Jul 2006 16:56:58 -0400

Jeroen van Bemmel wrote:

>>> Finally, let me say that if you have a proxy that crashes on receipt 
>>> of binary messages on its sip port, you are in for real trouble. I 
>>> think a far better solution is for proxy vendors to fix their 
>>> proxies, rather than for us to bend over backwards to design new 
>>> mechanisms that help protect such fragile servers from ever seeing 
>>> these messages. No matter what we put in our specs, attackers can 
>>> still send binary messages that will result in the same result you 
>>> are trying to prevent.
>>
>>
>> some garbage every 30 seconds or so. It's not necessarily that the 
>> proxy crashes but that it gives up on a particular connection at some 
>> point.
>>
>> Thanks,
>> Anders
> 
> 
> failure, and trigger some anomaly detection system,

There wouldn't be a TLS decryption failure - this is all transparent 
data as far as TLS is concerned. Anders is correct that you might lose 
framing on the TCP connection, in whcih case the client gets no service. 
No other clients are affected. However, keep in mind that the use case 
here is a misconfiguration. Any number of misconfigurations, such as an 
invalid IP address, for example, will cause the client to not receive 
service.

Indeed, I'll note that, in the outbound proxy discovery mechanism I just 
proposed, the flag comes for free with the mechanism since the outbound 
proxies are confirmed via service-routes, which can contain the 
stun=keepalive flag. This would argue strongly that any kind of check, 
if needed, goes with the discovery mechanism and not sip outbound itself.

Thanks,
Jonathan R.

---

From: <[email-masked]>
Date: Fri, 7 Jul 2006 10:44:44 +0300

Hi,

What Hadriel says here is in my opinion a clear reason why the
outbound draft (instead of any other optional or additional draft)
must have the safe check for the UA to ensure whether or not the 

Another reason is embedded into this statement from Jonathan:

> (3) constructed URIs. 

> URI that they construct from a domain name.

This suggestion seems to prevent the UA to use DHCP to discover
and use a local SIP proxy even if such an outbound compliant
proxy would exist. This does not sound a good idea to me.

Regards,

Erkki

---

From: Dean Willis <[email-masked]>
Date: Fri, 07 Jul 2006 03:01:38 -0500

> supports stun keepalives?

What do you mean "require"? Use a proxy-require option tag?

Or just hope it won't melt when you send it a STUN packet, meaning that 
you "require the operator to get it right".

The problem as I see it is we have no way of easily detecting an error 
if somebody mistakenly lists a non-compliant proxy as an outbound proxy 
in DHCP or some other discovery mechanism. I hate leaping off a trapeze 
without a safety net . . .

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 07 Jul 2006 03:04:03 -0500

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

--
Dean

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 7 Jul 2006 08:25:46 -0700

Jeroen,

On Jul 6, 2006, at 14:12, Jeroen van Bemmel wrote:
>> necessary, something that might be optional at best. As such, if 
>> folks decide they want something, it can go in another draft. I dont 
>> think we need to burden sip-outbound with this.
>
> The trouble is, once outbound is "out" any mechanism defined in a 
> separate draft won't work as good. Because then there will be clients 
> that simply ignore the flag.

Why is this anymore likely for clients that implement outbound?  What 
is the motivation for clients to ignore the flag?  If they ignore the 
flag and send STUN requests anyway against the they trash their own 
proxy.  That is not in the interest of the client vendor.

thanks,
-rohan

---

From: Adam Roach <[email-masked]>
Date: Fri, 07 Jul 2006 10:28:01 -0500

Dean Willis wrote:
> if somebody mistakenly lists a non-compliant proxy as an outbound 
> proxy in DHCP or some other discovery mechanism. I hate leaping off a 
> trapeze without a safety net . . .

You mean like sending SIP to an address and port just because DNS 
resolution leads you to believe that address and port is ready to 
receive SIP? But what if someone misconfigures their DNS and 
accidentally resolves a request for the SIP service to their SMTP port?

At some point, we need to trust that system administrators have a couple 
of brain cells to rub together; that they can notice when they've 
misconfigured their systems; and that they will take corrective measures 
when things fail to work.

/a

---

From: Dale Worley <[email-masked]>
Date: Thu, 6 Jul 2006 18:23:57 -0400

From: Ben Campbell <[email-masked]>

The problem (I think) is whether the device can recover framing
adequately to receive the next message on the "channel" in question.
Clearly, this isn't a problem with UDP or SCTP, which frame messages.
But if a UA establishes a TCP connection and sends a STUN message that
the recipient doesn't understand, we need to know that the recipient
can recover framing fast enough to process the SIP that the UA sends
afterward.  Otherwise, the UA's STUN messages would be performing a
DoS attack on its own SIP connection!

Dale

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 8 Jul 2006 18:46:50 +0300

Christer Holmberg (JO/LMF) writes:

 > Does a proxy supporting STUN keep-alive have to be an "outbound
 > proxy" (assuming you mean an edge proxy), as defind in the outbound
 > spec?

i don't know or care.  see subject line.  this thread is about outbound
proxies.

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 8 Jul 2006 19:29:34 +0300

Jeroen van Bemmel writes:

 > responsible for providing reasonable safeguards. 

i don't buy that.  stun port can be configured on many UAs.  it is thus
easy to set it to 5060.  proxies should be build to last any non-sip
packets.

-- juha

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Sat, 8 Jul 2006 18:45:31 +0200

The subjects says "Ready for WGLC on Outbound", and currently the usage of STUN for keep-alive is defined in that draft. Where do you see the word "proxy" in the subject line???

From: Juha Heinanen [mailto:[email-masked]]
Sent: Sat 08/07/2006 17:46
To: Christer Holmberg (JO/LMF)
Cc: Jeroen van Bemmel; Cullen Jennings; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Sip] Ready for WGLC on Outbound?

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 8 Jul 2006 20:12:48 +0300

Jonathan Rosenberg writes:

 > binary messages on its sip port, you are in for real trouble. 

fully agree.  let's close this tread.  

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 8 Jul 2006 20:23:08 +0300

> What do you mean "require"? Use a proxy-require option tag?

no, we simply say that outbound proxy MUST support stun keepalives.

 > without a safety net . . .

no properly implemented proxy melts no matter what you sent to it.  this
kind of arguments are completely bogus.

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 8 Jul 2006 20:33:57 +0300

Christer Holmberg (JO/LMF) writes:

 > The subjects says "Ready for WGLC on Outbound", and currently the
 > usage of STUN for keep-alive is defined in that draft. 

yes, but only in connection with outbound proxies.

-- juha

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Sat, 8 Jul 2006 21:19:17 +0200

>yes, but only in connection with outbound proxies.

There is an ongoing discussion related to documenting it as a standalone feature, and one of the options IS to document that standalone feature in the outbound draft.
 
I fully agree on the comments saying that a proxy should be able to receive STUN without crashing (it may enable some black-list functions etc, though, as described by Jeroen). However, I DO think it's a bad standard when you send stuff without knowing if the receiver supports it or not. In SIP we do use mechanisms (error codes, headers etc) to indicate what entities support and don't support, and I don't see why we shouldn't be able to do that also in this case.  
 
Regards,
 
Christer

---

From: Dean Willis <[email-masked]>
Date: Mon, 10 Jul 2006 00:04:13 -0500

On Jul 8, 2006, at 12:23 PM, Juha Heinanen wrote:

>> proxy

Dale has noted in a separate thread that STUN breaks TCP framing,  
possibly creating a self-inflicted DoS attack that the UA cannot  
detect to recover from.

So let's say my UA comes up on a strange network and I use nmap to  
find nodes responding on 5060/tcp that might serve as an outbound proxy.

I find one. Should I STUN it first, or ask it to process a SIP  
message request with a "Proxy-Require: outbound" before stunning it?

The current outbound draft, although it defines such an option tag,  
seems to define its use only in responses to REGISTER requests issued  
by a registrar. It says nothing about its use by a proxy that is in- 
between the registrar and the UA.

--
Dean

---

From: [email-masked]
Date: Mon, 10 Jul 2006 09:13:21 -0400

From: Dean Willis <[email-masked]>

Actually, Anders Kristensen raised the framing problem earlier, I was
just echoing him in the later context.

Dale

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 10 Jul 2006 11:11:54 -0400

inline.

[email-masked] wrote:

>>to mitigate is to say 'don't do that'. SIP-outbound can have some
> 
> words 
> 
>>which warn implementations that they MUST NOT insert this parameter
> 
> into 
> 

Not in my discovery proposal at least. A UA would construct the outbound 
proxy URI from DHCP without the flag. REGISTER is sent through it. 
Resulting service-route URI has the flag. Now keepalives get used.

-Jonathan R.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 10 Jul 2006 16:42:13 -0400

> Dale has noted in a separate thread that STUN breaks TCP framing,

One solution to fix this TCP framing problem would be to add an
attribute in the STUN request, just before the FINGERPRINT attribute,
that contain this octet string:

0x00000D0A6C3A32340D0A0D0A

This embeds the character string "\r\nl:24\r\n\r\n", which should be
enough to have the SIP parser skip the entire STUN message, and return
an error (same than with UDP).