Subject: [BEHAVE] Redirect for STUN Relay

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 4 Jul 2007 22:30:06 -0400

I was wondering whether it would make sense to have redirect type of
functionality for STUN Relay, e.g. referring another server in a
negative answer to an initial allocate request.

The use case I am thinking of is load balancing. Discovery of STUN
servers relies on DNS but a predefined weight allocation based on
capacity may not provide always satisfactory results. The load on a
server would be a parameter of capacity, bandwidth for a session and the
duration of the sessions it is relaying. One could argue that on average
sessions with different durations would be more or less evenly
distributed among different STUN relay servers but I think it wouldn't
be wrong to say that this parameter is more volatile than others. 

During times of heavy resource allocation in servers, search based on
weights associated with servers may require multiple request/responses
till an actual allocation is performed. With the ability to refer
another server, information STUN servers in a farm have about other
server's resource usage or a front end may be utilized.

This may not be a good fit for certain architectures/configurations but
for such cases one may simply choose not to refer another server.

     Thanks,
     Tolga

_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 5 Jul 2007 09:09:05 +0300

> negative answer to an initial allocate request.

This is *already* in the specification, and has been there for several years.

-- 
Rémi Denis-Courmont

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 5 Jul 2007 08:20:43 -0400

O.K., sorry my bad.

  Thanks,
  Tolga

> -----Original Message-----
> From: Rémi Denis-Courmont [mailto:[email-masked]]
> Sent: Thursday, July 05, 2007 2:09 AM
> To: [email-masked]; Asveren, Tolga
> Subject: Re: [BEHAVE] Redirect for STUN Relay
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 05 Jul 2007 10:58:13 -0400

Actually, this is something which we were planning on removing in the 
revision coming up. There were comments during last call about the 
utility of the mechanism, security concerns, and so on. Also there 
didn't seem to be anyone who wanted it. There are much better ways of 
doing load balacning, for example utilizing a front-end load balancing 
element that actually tracks capacity of back end relays, and then 
directs the request to the least loaded server. THis is standard 
practice for load balancing for many other protocols. That kind of 
mechanism is also faster and more stable. Redirect mechanisms can result 
in ping-ponging especially near capacity limits.

-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: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 05 Jul 2007 08:15:31 -0700

Jonathan Rosenberg wrote:
> didn't seem to be anyone who wanted it. 

OK, I missed the discussion, because I use the 300 response, and plan to
continue to use it.  I also proposed a long time ago to replace the IP
address in the 300 response by a name so the SRV RR processing can be
reapplied, but without success.

There are much better ways of
> practice for load balancing for many other protocols. 

This also force to buy expensive stuff that is not needed with the end
to end mechanisms.  It's OK if people want to use B2BUA, SBC, load
balancers, NAT - their money, not mine - but Internet standards should
not force people to do this.

So I am strongly opposed to remove the 300 response from STUN.

> That kind of

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [RFC1855-compliant space for rent ]
Work: [email-masked]            [                                 ]

---

From: "Mayank Dev Sondhi" <[email-masked]>
Date: Thu, 19 Jul 2007 14:09:09 +0530

+1 for me too, we use the 300 response for working WITH our load balancers,
this is definitely useful. As for security issues, we rely on
Message-Integrity to protect the address. Ping-ponging across servers is
left to the client to handle appropriately(fixed number of retries before
giving up)

-Mayank

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 19 Jul 2007 17:11:12 -0700

We kept 300 in rfc3489bis-07,
http://tools.ietf.org/html/draft-ietf-behave-rfc3489bis-07#section-14.6
(but I don't think Marc's email was ever followed up.  Sorry about that.)

-d

> From: Mayank Dev Sondhi [mailto:[email-masked]] 
> Sent: Thursday, July 19, 2007 1:39 AM
> To: Marc Petit-Huguenin
> Cc: [email-masked]
> +1 for me too, we use the 300 response for working WITH our 
> load balancers, this is definitely useful. As for security 
> issues, we rely on Message-Integrity to protect the address. 
> Ping-ponging across servers is left to the client to handle 
> appropriately(fixed number of retries before giving up) 
>  
> -Mayank
> 
>  
> 	>>> This is *already* in the specification, and has 
> been there for several 
> 	>>> years.
> 	>>>
> 	>>> --
> 	>>> Rémi Denis-Courmont
> 	
> 	--
> 	Marc Petit-Huguenin           [                         
>         ]
> 	Home: [email-masked] 
> <mailto:[email-masked]>  [RFC1855-compliant space for rent ]
> 	Work: [email-masked]            [                         
>         ]
> 	
>

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Fri, 20 Jul 2007 19:46:08 +0200

Hi,

Due to other tasks, I've been out of the 3489bis loop for a while, so my
intention is NOT to question decissions that have been made - simply to
give some questions for clarification based on those decissions.

Now, if I remember correctly, we used to define "STUN usage" as some
function that STUN was used to perform, for example keep-alive. Now,
however, "STUN usage" is defined as an external mechanism (for example
ICE) that uses STUN for different tasks, and that external mechanism
must define how STUN is used to perform different task (which headers to
use etc). 

For example, it is not possible to say "this mechanism uses STUN for
keep-alive, as defined in 3489bis", but "this mechanism uses STUN for
keep-alive, and that is done using this header, that header blah blah
blah".

Now, the questions:

1. Since every mechanism which uses STUN must describe how it's done,
does it mean that in theory that means mechanism X and mechanism Y could
use STUN in different ways for performing an identical task (for example
keep-alive)?

(Of course, mechanism Y could always refer to mechanism X, but that's
another issue)

2. Follow-up on previous question: if a non-IETF SDO defines a "STUN
usage", I assume they would also, for the different STUN functions, need
to describe which STUN headers are used etc (the can not say "this
mechanism uses STUN for keep-alive, as defined in 3489bis" either)?

For example, let say that SDO-XX wants to use STUN for example simply to
retrieve the mapped address. There is no existing STUN usage that can be
referred to (at least it's not ICE, and it's not Outbound), so SDO-XX
would have to describe themselves which STUN headers to use etc.

(NOTE: The purpose is not to discuss the details and usefullness of the
example)

Regards,

Christer

---

From: Philip Matthews <[email-masked]>
Date: Fri, 20 Jul 2007 14:58:15 -0400

> (Of course, mechanism Y could always refer to mechanism X, but that's

Your "mechanism" is what 3489bis-07 calls a "usage".
A "mechanism" in 3489bis-07 is a reusable extension to the protocol.
There are a number of "mechanisms" defined in 3489bis-07 that usages
can use.

So yes, if another usage of STUN were to come along, then it would have
to define exactly how to use STUN. It could use the binding method and
any mechanisms defined in 3489bis-07, but if it wants something new,
it must define it.

Regarding NAT Keepalives, one can use either Binding Request/Reply  
transactions or
Binding  Indications (Outbound uses the former, while ICE uses the  
latter).
Most of the details for how to do this are defined in 34890bis-07.
If a new usage comes along that wants to use STUN in this way, then  
there is not
much it has to do.

> would have to describe themselves which STUN headers to use etc.

Yes and no.
The Binding method is defined in 3489bis-07, and this is most of what  
is needed.
The main thing this new usage would have to do is consider the  
security implications
of using STUN. If it is doing "classic STUN", then it would need to  
say why it
is not worried about the security problems of using STUN in this way.

Hope this helps.

- Philip

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Sat, 21 Jul 2007 20:51:06 +0200

Hi Philip,

>>Due to other tasks, I've been out of the 3489bis loop for a while, so 
>>my intention is NOT to question decissions that have been made - 
>>simply to give some questions for clarification based on those 
>>decissions.
>>
>>must define how STUN is used to perform different task (which headers 
>>to use etc).
>>
>>does it mean that in theory that means mechanism X and mechanism Y 
>>could use STUN in different ways for performing an identical task (for

>>example keep-alive)?

Yes. Y could be ICE and X something else.

>There are a number of "mechanisms" defined in 3489bis-07 that 
>usages can use.

Yes.
 
>So yes, if another usage of STUN were to come along, then it 
>would have to define exactly how to use STUN. It could use 
>the binding method and any mechanisms defined in 3489bis-07, 
>but if it wants something new, it must define it.
>
> 
>Regarding NAT Keepalives, one can use either Binding 
>Request/Reply transactions or Binding  Indications (Outbound 
>uses the former, while ICE uses the latter).
>If a new usage comes along that wants to use STUN in this 
>way, then there is not much it has to do.

In real life, probably not. 

But, still, the new usage must still describe when the STUN messages are
sent etc, as required in chapter 13.

And, the 2nd paragraph of chapter 13, maybe it then would be good to
say: "three STUN usages are defined in IETF". 

>>usage", I assume they would also, for the different STUN functions, 
>>need to describe which STUN headers are used etc (the can not say 
>>"this mechanism uses STUN for keep-alive, as defined in 3489bis" 
>>either)?
>>
>>For example, let say that SDO-XX wants to use STUN for example simply 
>>to retrieve the mapped address. There is no existing STUN usage that 
>>can be referred to (at least it's not ICE, and it's not Outbound), so 
>>SDO-XX would have to describe themselves which STUN headers to use 
>>etc.
> 
>Yes and no.
>The Binding method is defined in 3489bis-07, and this is most 
>of what is needed.

Correct, but the SDO would still need to describe when the STUN messages
are sent, etc, as required in chapter 13.

>The main thing this new usage would have to do is consider 
>the security implications of using STUN. If it is doing 
>"classic STUN", then it would need to say why it is not 
>worried about the security problems of using STUN in this way.

Well, it's difficult to say what other SDOs are going to do, but I guess
we just have to trust them :)

>Hope this helps.

Yes. Thank you!

In addition, a small editorial issue (I appologize if someone has
already mentioned it): At the end of the 3rd paragraph chapter 1 I guess
it should say "is a usage of STUN" - not "is a usage of ICE".

Regards,

Christer

---

From: Philip Matthews <[email-masked]>
Date: Sat, 21 Jul 2007 17:32:47 -0400

Thanks for the typos and suggested corrections.

If one just wants to use STUN for a keep-alive mechanism,
then the text should be pretty lightweight. Certainly, we are
hoping for something very lightweight for Outbound.

- Philip

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Sun, 22 Jul 2007 08:56:49 +0200

Hi, 

>hoping for something very lightweight for Outbound.

My personal assumption is that someone could want to use STUN simply to
gather the mapped address, and possibly also use it for keep-alive. That
is a much "lighter" usage than ICE (but of course it does not provide
all the features that ICE does).

Regards,

Christer

> >>> Due to other tasks, I've been out of the 3489bis loop for 
> a while, 
> >>> so my intention is NOT to question decissions that have 
> been made - 
> >>> must define how STUN is used to perform different task (which 
> >>> headers to use etc).
> >>>
> >>> keep-alive, as defined in 3489bis", but "this mechanism uses STUN 
> >>> for keep-alive, and that is done using this header, that 
> header blah 
> >>> blah blah".
> >>>
> >>> Now, the questions:
> >>>
> >>> 1. Since every mechanism which uses STUN must describe how it's 
> >>> done, does it mean that in theory that means mechanism X and 
> >>> mechanism Y could use STUN in different ways for performing an 
> >>> identical task (for
> >
> >>> example keep-alive)?
> >>>
> >>> (Of course, mechanism Y could always refer to mechanism X, but 
> >>> that's another issue)
> >>
> >> So yes, if another usage of STUN were to come along, then it would 
> >> have to define exactly how to use STUN. It could use the binding 
> >> method and any mechanisms defined in 3489bis-07, but if it wants 
> >> something new, it must define it.
> >>
> >>
> >> transactions or Binding  Indications (Outbound uses the 
> former, while 
> >> ICE uses the latter).
> > But, still, the new usage must still describe when the STUN 
> messages 
> > are sent etc, as required in chapter 13.
> >
> >>> For example, let say that SDO-XX wants to use STUN for example 
> >>> simply to retrieve the mapped address. There is no existing STUN 
> >>> usage that can be referred to (at least it's not ICE, and 
> it's not 
> >>> Outbound), so SDO-XX would have to describe themselves which STUN 
> >>> headers to use etc.
> >>
> >> Yes and no.
> > Correct, but the SDO would still need to describe when the STUN 
> > messages are sent, etc, as required in chapter 13.
> >
> >> security implications of using STUN. If it is doing 
> "classic STUN", 
> >> then it would need to say why it is not worried about the security 
> >> problems of using STUN in this way.
> >
> > Well, it's difficult to say what other SDOs are going to do, but I 
> > guess we just have to trust them :)
> >
> >> Hope this helps.
> >
> > Yes. Thank you!
> >
> > already mentioned it): At the end of the 3rd paragraph chapter 1 I 
> > guess it should say "is a usage of STUN" - not "is a usage of ICE".
> >
> > Regards,
> >
> > Christer
> >
> >
> 
>

---

From: Philip Matthews <[email-masked]>
Date: Sun, 22 Jul 2007 06:36:54 -0500

> all the features that ICE does).

There are a number of well-known problems that can occur when using  
STUN in that way.
So 3489bis-07 discourages that use. Section 2 says:

    STUN was originally defined in RFC 3489 [RFC3489].  That
    specification, sometimes referred to as "classic STUN", represented
    itself as a complete solution to the NAT traversal problem.  In that
    solution, a client would discover whether it was behind a NAT,
    determine its NAT type, discover its IP address and port on the
    public side of the outermost NAT, and then utilize that IP address
    and port within the body of protocols, such as the Session  
Initiation
    Protocol (SIP) [RFC3261].  However, experience since the publication
    of RFC 3489 has found that classic STUN simply does not work
    sufficiently well to be a deployable solution.  The address and port
    learned through classic STUN are sometimes usable for communications
    with a peer, and sometimes not.  Classic STUN provided no way to
    discover whether it would, in fact, work or not, and it provided no
    remedy in cases where it did not.  Furthermore, classic STUN's
    algorithm for classification of NAT types was found to be faulty, as
    many NATs did not fit cleanly into the types defined there.  Classic
    STUN also had security vulnerabilities which required an extremely
    complicated mechanism to address, and despite the complexity of the
    mechanism, were not fully remedied.

So to use STUN "officially" in that manner, you need to consider these
potential problems and describe why they are not a concern in your
particular usage. This was one of the motivations for moving to this
new definition of usage.

- Philip