Subject: [BEHAVE] BoF request: STUN Control Usage

From: "Dan Wing" <[email-masked]>
Date: Wed, 6 Jun 2007 23:43:01 -0700

As individual contributor:

I would like to summarize my reasons for calling this BoF, and the
value I see STUN Control can bring.  Hopefully this summary will tease
out futher objections or further agreement for this BoF and discussion
of draft-wing-behave-nat-control-stun-usage itself.

 1. ICE works.  This has been well demonstrated by its successful
    deployment on the Internet by millions of endpoints.  It works
    without explicit support by subscriber's NATs or ISP's NATs.

 2. A drawback of ICE (and STUN) is the chattiness of keepalive
    messages (primarily with SIP servers [draft-ietf-sip-outbound]) 
    and the chattiness of binding discovery messages for each 
    call (primarily due to ICE).

STUN Control adds an optimization to STUN's existing areas of
applicability by allowing an end host to negotiate and extend NAT
binding lifetimes.  This improves the performance of ICE and 
sip-outbound and any other protocols making use of STUN.

In our draft, we don't compare STUN Control to other protocols, so
here are some points:

* STUN Control is inherently limited in the scope of control it
provides.  It only allows for extension of binding lifetimes, and only
allows such extensions for the binding associated with the source
IP/port the STUN Control request is coming from.  Because of its
fundamentally limited scope of control, the NAT can operate with a
trivial authorization policy - a control message coming on its
internal interface is always authorized to manage the binding lifetime
for the private address and port the message comes from.  This is, in
fact, exactly the same authorization policies used by NATs today to
authorize the creation and termination of bindings.  STUN Control
merely extends that authorization to make the termination more 
controlled.  The trivial scope of control and authorization policy 
means that authentication, credentials, shared secrets, and so on, 
are not required.  The need for such security measures in other, 
richer control protocols makes them hard to deploy.  STUN Control 
is meant to be trivially deployable to solve a small but important 
problem.

* STUN Control works with nested NATs; UPnP does not.

* STUN Control is incrementally deployable.  Other mechanisms are not
(they require modifying end hosts and NATs, or else they fail or
they fall back to other mechanisms).  STUN Control is an
optimization to ICE and sip-outbound.  If a host or a NAT doesn't
support STUN Control, ICE and sip-outbound continue to work --
albeit with more frequent keepalive messages and binding discovery
messages sent to the STUN server (which is what they do today 
without STUN Control).

Please send comments to [email-masked].

-d

-----

(Below is my original BoF proposal.  Chairs are still TBD.  Since
my original request, it has been suggested that one hour isn't 
sufficient, as we need to discuss deployment barriers to existing 
techniques, and optimizations that would be useful for sip-outbound 
and ICE).

Description:
ICE and its companion protocol STUN are emerging as a popular
mechanism to traverse NATs without requiring deployment of new
software in existing NATs.  ICE has been specified for SIP, extended
to Jabber/XMPP, and will work with RTSP.  ICE is incrementally
deployable, providing operation over any sort of NAT and any sort of
firewall, without requiring upgrades to those NATs and firewalls.

A successful Firewall or NAT control protocols needs to also be
incrementally deployable so that applications can request enhanced
services from firewalls and from NATs to permit certain flows towards
a host and to the host's applications.  Incremental deployment allows
hosts to deploy the protocol without requiring NATs or firewalls in
front of the host to be upgraded to enjoy basic operation, but after
upgrading to enjoy enhanced operation.

Draft-wing-behave-nat-control-stun-usage describes how STUN could be
used to communicate with both NATs and firewalls to enhance the
operation of those NATs and firewalls to allow certain flows or treat
them differently.

This BoF is intended to discuss one proposed technique,
draft-wing-behave-nat-control-stun-usage as an incrementally-deployable
NAT control mechanism and firewall control mechanism, and to determine
if there is sufficient community interest to move this work forward
in the IETF.

Agenda:
  Agenda bash .............................................  5
  Summary of existing NAT traversal techniques ............ 20
   (UPnP, NAT-PMP/Bonjour, MIDCOM techniques, NSIS GIST, ICE)
  STUN Control ............................................ 30
                                                     ---------
                                                     total: 55

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

---

From: "David Barrett" <[email-masked]>
Date: Thu, 7 Jun 2007 12:39:18 -0700

> -----Original Message-----
> From: Dan Wing [mailto:[email-masked]]
> Subject: [BEHAVE] BoF request: STUN Control Usage
> 

Just curious, what statistics are available on ICE's real-world usage and
NAT-penetration success rates?  Specifically:

- How did you come up with the "millions of endpoints" number?

- What does "works" mean?  (I'd suggest this be measured in "direct peer
connectivity ratio" and "connection setup time", but any measure will do.)

Granted, it might be a bit OT given that you're really trying to talk about
STUN, but I'm always interested in new real-world statistics.

-david

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 7 Jun 2007 15:58:43 -0700

> Just curious, what statistics are available on ICE's 
> real-world usage and NAT-penetration success rates?  Specifically:
> 

GoogleTalk's API, Google Talk itself, Microsoft's Windows Live
Messenger (formerly called MSN), and Yahoo Messenger all use 
ICE.

> - What does "works" mean?  (I'd suggest this be measured in 
> "direct peer connectivity ratio" and "connection setup time", 
> but any measure will do.)

I found this, "Improving ICE Service Selection in a P2P System 
using the Gradient Topology", 
http://www.jimdowling.info/pubs/dowling-j_icep2p_saso07.pdf
which includes the following quote:

  [...] Google's estimate that 8% of the GoogleTalk traffic 
  is routed using relay nodes.

which cites
  Google. Google talk, Accessed, Feb 22, 2007.
  http://code.google.com/apis/talk/libjingle

which leads one to:
  http://code.google.com/apis/talk/libjingle/important_concepts.html

> Granted, it might be a bit OT given that you're really trying 
> to talk about STUN, but I'm always interested in new real-world 
> statistics.

It's a worthwhile discussion, even if a bit off topic.

If STUN/ICE were more, or less, common on the Internet would you
find a BoF on optimizing STUN more, or less, important?

-d

---

From: "David Barrett" <[email-masked]>
Date: Thu, 7 Jun 2007 20:00:28 -0700

> Messenger (formerly called MSN), and Yahoo Messenger all use

Ok, that's true, ICE code exists on millions of computers.  I wonder what
fraction of those clients actually use the VoIP features, however.  It'd be
neat to know how (or estimate) many ICE sessions are established daily,
especially as a fraction of total P2P VoIP connections.

Incidentally, do you know if it's possible to establish VoIP communications
between these networks?  Has it been demonstrated that these different ICE
implementations are in fact compatible, or are they more "ICE-influenced"?

>   is routed using relay nodes.

Very cool, thanks!

> find a BoF on optimizing STUN more, or less, important?

Well, I don't know the answers to the above questions I pose, but I'd wager
that the actual utility of ICE in the real world today is less dramatic than
"millions of endpoints" would suggest.  If that's true (and I have no data
to suggest it is or isn't), I'd suggest that perhaps we should work on
determining why ICE isn't more widely used and focus on that.  

For example, has it been proven that different ICE implementations
interoperate as smoothly in practice as they should in theory?  If not, what
real-world lessons can be drawn and applied to perhaps improve practical
interoperability going forward?  92% peer connectivity is pretty good --
perhaps there are bigger fish to fry than getting to 95% or 99%?

And while I realize this is all about ICE, I think this might be relevant to
STUN because there are a finite number of people in the IETF working on P2P,
and their time is a scarce commodity.  Given that ICE is STUN's primary
customer, STUN's fortunes sink or swim with ICE's (just as ICE's fortunes
sink or swim on SIP's).  

As such, until it's been demonstrated that ICE and SIP are already swimming
(which they might be), I'd be hesitant to spend much energy on expanding
STUN beyond the strict functionality required by ICE and would instead
refocus that effort on making ICE and SIP more relevant in the real world.

Said another way, until some measurable, significant fraction (25%?) of the
world's P2P VoIP calls use a SIP/ICE/STUN stack, I think the focus should be
on smoothing out the practical wrinkles that prevent greater adoption over
improving the theoretical capabilities of an underutilized protocol.

Reducing chattiness of STUN sounds great, but the amount of energy it'll
take to not only standardize the protocol but push standard implementation
into a significant portion of the world's NATs seems high.  If we could
measure all that energy into manhours, I wonder what better way those hours
might be spent?

-david

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 7 Jun 2007 20:36:46 -0700

> Ok, that's true, ICE code exists on millions of computers.  I 
> wonder what fraction of those clients actually use the VoIP 
> features, however. 

Dunno.

> It'd be neat to know how (or estimate) many ICE sessions are 
> established daily, especially as a fraction of total P2P 
> VoIP connections.
> 
> Incidentally, do you know if it's possible to establish VoIP 
> communications between these networks? 

I don't know.  I know Microsoft and Yahoo have collaborated
with their IM systems, but I don't know if that includes VoIP.

> Has it been demonstrated that these different ICE

ICE isn't finished, and early ICE versions are not compatible
with each other.  Thus, there isn't much hope those different
networks would be compatible until until ICE has gone to RFC
or if those networks had worked out a version of ICE they 
mutually agreed they would interoperate with (thus creating a
defacto standard).

> Well, I don't know the answers to the above questions I pose, 
> but I'd wager that the actual utility of ICE in the real world 
> today is less dramatic than "millions of endpoints" would suggest.  
> If that's true (and I have no data to suggest it is or isn't), 
> I'd suggest that perhaps we should work on determining why ICE 
> isn't more widely used and focus on that.  
> 
> interoperate as smoothly in practice as they should in 
> theory?  If not, what real-world lessons can be drawn and applied 
> to perhaps improve practical interoperability going forward?  92% 
> peer connectivity is pretty good -- perhaps there are bigger 
> fish to fry than getting to 95% or 99%?

Google's analysis is based on their own (GoogleTalk) network, I 
would expect -- not GoogleTalk-to-something-else.  I expect their
92% number is based on how often two users, each behind 
NATs with the 'Address and Port-Dependent Mapping' property
(RFC4787) attempt to talk with each other (this property was
formerly called 'symmetric NAT').  With ICE, since approximately
ice-10, that is the only case that causes a media relay to be
utilized.

> And while I realize this is all about ICE, I think this might 
> be relevant to STUN because there are a finite number of people 
> in the IETF working on P2P, and their time is a scarce 
> commodity.  Given that ICE is STUN's primary customer, STUN's 
> fortunes sink or swim with ICE's (just as ICE's fortunes
> sink or swim on SIP's).  
> 
> As such, until it's been demonstrated that ICE and SIP are 
> already swimming (which they might be), I'd be hesitant to 
> spend much energy on expanding STUN beyond the strict 
> functionality required by ICE and would instead refocus that 
> effort on making ICE and SIP more relevant in 
> the real world.
> 
> Said another way, until some measurable, significant fraction 
> (25%?) of the world's P2P VoIP calls use a SIP/ICE/STUN stack, 
> I think the focus should be on smoothing out the practical 
> wrinkles that prevent greater adoption over improving the 
> theoretical capabilities of an underutilized protocol.

Not sure I follow -- all of the major Internet-based IM clients
with voice and video capabilities use ICE (except Skype which
uses its own techniques), even though ICE isn't even an RFC.  The
value is so great these products have utilized a pre-standard
specification.  This seems quite compelling to me, especially
considering the difficulties usually incurred in implementing
pre-standard specifications in commercial products.

> Reducing chattiness of STUN sounds great, but the amount of 
> energy it'll take to not only standardize the protocol but 
> push standard implementation into a significant portion of 
> the world's NATs seems high.  If we could measure all that 
> energy into manhours, I wonder what better way those hours
> might be spent?

Yes, that's the question.

-d

---

From: "David Barrett" <[email-masked]>
Date: Thu, 7 Jun 2007 21:18:25 -0700

> ice-10, that is the only case that causes a media relay to be

Ah, ok, so it's a theoretical number.  Does anyone know the real number?
Until it's been measured empirically, at scale, in the real world, we simply
don't know.  In my experience, implementing the algorithms is easy, but
tweaking them to work in the real world is very, very hard.

> pre-standard specifications in commercial products.

It's no challenge to get an implementation of a protocol to interoperate
with itself (well, it *is* challenging, but that's not the point).  The real
challenge is having multiple implementations of the same protocol "just
work" without out-of-band coordination between the implementers.

Saying "these networks support ICE but not each other" is exactly equivalent
to saying "these networks have similar protocols -- all called ICE -- and
its unknown how much work it'll take to make them speak the same protocol".

> Yes, that's the question.

I don't mean to bash on ICE, but merely to say that until we prove ICE
works, ICE hasn't been proven to work.  I'd suggest "prove" means
"demonstrate in the real world at significant scale" and "work" means:

a) Achieves some minimum level of peer connectivity (90%?)
b) Is sufficiently unambiguous to interoperate without OOB coordination

If it hasn't already been done (and hopefully it has been), these should be
the focus.  Until then, it's wishful thinking to assume all's in order and
move on to something else.

Said another way, I think we've certainly achieved "documenting algorithms
that can be used to construct a proprietary protocol that achieves an
unknown level of NAT penetration".  But "standardizing a protocol that, when
implemented, ensures a minimum level of effectiveness and a high degree of
interoperation on a global scale" remains to be seen.

-david

---

From: <[email-masked]>
Date: Fri, 8 Jun 2007 09:44:12 +0300

Hi, 

>Given that ICE is STUN's primary customer, STUN's fortunes 
>sink or swim with ICE's (just as ICE's fortunes
>sink or swim on SIP's).  

I think this statement is a bit exaggerated. There
are already SIP VoIP UA implementations with RFC
3489 version of STUN but without ICE. They are
succesfully deployed with environments where the
NATs implement Endpoint-Independent Mapping behaviour.

Thus fates of STUN and ICE are not as tightly connected
to each other as you suggest. ICE provides added value
for complex environments, but there are significant
deployments which already work pretty well just with
SIP combined with STUN.

>functionality required by ICE and would instead refocus 
>that effort on making ICE and SIP more relevant in the 
>real world.

For the deployments I am referring to, it would be useful
to have STUN extended with a mechanism to control the
required keepalive interval for NAT binding:

- Extensions needed for the already deployed set of 
  protocols would be minimal.

- There would be significant benefits both to the
  traffic in the network and the battery consumption
  of mobile VoIP devices.

So I think this effort is valuable regardless on what
happens to ICE.

Regards,

Erkki

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Fri, 8 Jun 2007 09:13:41 +0200

Hi,

I think that SIP outbound is as "primary" customer of STUN as ICE is.

Regards,

Christer

> From: [email-masked] [mailto:[email-masked]] 
> Sent: 8. kesäkuuta 2007 9:44
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [BEHAVE] BoF request: STUN Control Usage
> 
> Hi, 
> 
> sink or swim 
> >with ICE's (just as ICE's fortunes sink or swim on SIP's).
> 
> I think this statement is a bit exaggerated. There are 
> already SIP VoIP UA implementations with RFC
> 3489 version of STUN but without ICE. They are succesfully 
> deployed with environments where the NATs implement 
> Endpoint-Independent Mapping behaviour.
> 
> Thus fates of STUN and ICE are not as tightly connected to 
> each other as you suggest. ICE provides added value for 
> complex environments, but there are significant deployments 
> which already work pretty well just with SIP combined with STUN.
> 
> >As such, until it's been demonstrated that ICE and SIP are already 
> >swimming (which they might be), I'd be hesitant to spend 
> much energy on 
> >expanding STUN beyond the strict functionality required by ICE and 
> >would instead refocus that effort on making ICE and SIP more 
> relevant 
> >in the real world.
> 
> For the deployments I am referring to, it would be useful to 
> have STUN extended with a mechanism to control the required 
> keepalive interval for NAT binding:
> 
> So I think this effort is valuable regardless on what happens to ICE.
> 
> Regards,
> 
> Erkki
> 
>

---

From: "Pete Cordell" <[email-masked]>
Date: Fri, 8 Jun 2007 09:38:45 +0100

----- Original Message From: "David Barrett" <[email-masked]>

> measure all that energy into man-hours, I wonder what better way those 
> hours
> might be spent?

Alas, IMO, nobody has a better idea of where such man-hours could be spent.

I think STUN control is a small incremental piece of work and it makes sense 
to do it while the expertise is still present in the behave WG and all the 
various issues and interactions are current in peoples' minds.

Also, for better or worse, things like STUN, ICE, outbound are all 
inter-related and it seems sensible to deliver them as a package rather than 
trying to bake one and then move onto the next.  At least then, if, in the 
unlikely event that ICE requires a tweak to allow for STUN control, then it 
can be done.

Finally, it's seemed obvious to me from day 1 that 'the' NAT would be the 
ideal location for the STUN server.  So, IMO, the work should go ahead.

Regards,

Pete.
--
=============================================
Pete Cordell
Codalogic Ltd
for XML Schema to C++ data binding visit
 http://www.codalogic.com/lmx/
=============================================

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 08 Jun 2007 10:18:32 -0400

To take this a step further, I think sip-outbound is the primary 
benefactor of stun-control, not ICE.

The big pain point today are these awful keepalives we need to 
constantly be sending for sip-outbound. WHen UDP is used, its every 20 
or 30 seconds. That represents a huge load on the servers even when its 
STUN (though much better than REGISTER like what SBCs use today). With 
stun control, we could control this so that SIP servers would see 
reduction in stun volume by one or even two orders of magnitude. That is 
a real big bang for the buck. Also benefits wireless applications.

-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: "David Barrett" <[email-masked]>
Date: Fri, 8 Jun 2007 11:14:34 -0700

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Subject: Re: [BEHAVE] BoF request: STUN Control Usage
> 
> STUN (though much better than REGISTER like what SBCs use today).

Again, just to push back on this a bit, how "huge" is a huge load?  In my
experience the keepalive traffic is the best kind: negligible, totally
predictable, and scales linearly with userbase.  All things being equal I'd
prefer it weren't necessary, but it's certainly not on the radar as being a
problem worth worrying about.  (If traffic is really such a huge problem,
let's just reduce the packet size -- a single packet is all that's really
needed to get the job done.)

Rather, the "cost" of unknown timeouts (the real problem STUN Control is
meant to solve) is engineering to accommodate them.  But unfortunately,
until STUN Control has near universal deployment -- and especially given
that there's no way to detect if a non-STUN-Control-compliant gateway is in
place -- we'll all still need to code exactly as if the STUN-Control
protocol didn't exist.  (Indeed, it'll be *more* costly as now we need to
support another protocol.)

In effect, STUN Control has a value curve looking like a square wave of
near-zero (even sub-zero) reduction of P2P software complexity up to
something like 90% global deployment (at which point application developers
are ok with just accepting a smaller userbase as the price of convenience).

I don't mean to be negative, but it just seems like a huge burden to
accomplish this and -- if I as a P2P software developer am meant to be the
benefactor -- I'd suggest the gain isn't worth the cost.

Personally, I would *much* rather that we just spend that same energy
getting BEHAVE deployed faster, or getting SIP/ICE/STUN used more widely
(starting with just quantifying how widely in fact they are being used).
Otherwise I fear we'd just create a document describing a neat protocol that
in theory does great things but in practice has limited (or unknown)
utility.

-david

---

From: "Adam Fisk" <[email-masked]>
Date: Fri, 8 Jun 2007 15:57:02 -0400

> benefactor of stun-control, not ICE.

Agreed.

> a real big bang for the buck. Also benefits wireless applications.

Any idea how many of the deployed SIP servers use UDP?  In my understanding,
more and more implementations were switching to TCP because SIP messages
were hitting up against the 1500 byte MTU limit for UDP.  Maybe the wireless
guys are using UDP?  I never really considered using the UDP implementation
myself just because I didn't see the point.  I guess the point would be
better performance, but the added complication doesn't seem worth it.

I've even heard talk of excluding UDP altogether if we were to write SIP
over again.  I bring this up because the double CRLF keep alive for TCP with
SIP outbound is a really trivial addition.  If almost everyone's using TCP,
then your reasoning above for STUN control breaks down.

-Adam

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 8 Jun 2007 13:47:58 -0700

> Any idea how many of the deployed SIP servers use UDP? 

There is some information from SIPit 20,
https://www.sipit.net/SIPit20_Summary but of course that
lacks market share information.

> In my 
> understanding, more and more implementations were switching 
> to TCP because SIP messages were hitting up against the 1500 
> byte MTU limit for UDP. 

Based on that SIPit information, 71% claimed to work fine
with fragmented UDP packets and 10% didn't know.  I guess the
remainder (19%) know they break with fragmented UDP.  I dunno
what those implementations plan to do -- maybe choose a 
better IP stack?

Additionally, under high traffic rates from a single IP 
address (such as a bunch of SIP clients behind a single NAPT), 
draft-heffner-frag-harmful describes problems with reassembly
which I doubt are sufficiently appreciated by those running
SIP over UDP.

> Maybe the wireless guys are using UDP?  I never really considered
> using the UDP implementation myself just because I didn't see the
> point.  I guess the point would be better performance, but the added
> complication doesn't seem worth it.
> 
> I've even heard talk of excluding UDP altogether if we were 
> to write SIP over again.  I bring this up because the double 
> CRLF keep alive for TCP with SIP outbound is a really trivial 
> addition.  If almost everyone's using TCP, then your 
> reasoning above for STUN control breaks down. 

To summarize, I believe you're saying if UDP keepalives create 
too much load on your server or network, just use TCP.

-d

---

From: "Adam Fisk" <[email-masked]>
Date: Fri, 8 Jun 2007 17:03:55 -0400

> lacks market share information.

Interesting.  So it looks like most implementations support both.  I wonder
how many of those actually use the UDP implementation over the TCP in terms
of what clients actually connect with.  I know I wouldn't, but I wonder.

> which I doubt are sufficiently appreciated by those running

I would think there would be many issues along these lines.  It has to be
one of the thorniest parts of any implementation in any case.

> too much load on your server or network, just use TCP.

Basically.  Put a slightly different way, if no one's using UDP in practice
anyway, then the TCP keep alive mechanism doesn't seem too onerous.  There
unfortunately seems to be little way to get a solid answer to that question,
though, so I'm not sure where to go with it.

Thanks.

-Adam

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 11 Jun 2007 09:49:53 +0300

On Friday 08 June 2007 21:14:34 ext David Barrett wrote:
> predictable, and scales linearly with userbase.

Handling keep-alives may well be totally neglectible on a modern and 
well-implemented SIP server. And it is of course of neglectible CPU cost to a 
client.

*But* it is a HUGE battery W-h sink for mobile devices that have to wake-up 
their radio every 30 seconds to send something. VoIP is not going to fly if 
battery life is 5 times less than circuit-switched...

(...)
> Otherwise I fear we'd just create a document describing a neat protocol
> that in theory does great things but in practice has limited (or unknown)
> utility.

STUN control puts no extra requirement to the server side, and is entirely 
optional on the client side, so I would not see it as a problem if you think 
you do not need it.

-- 
Rémi Denis-Courmont

---

From: "David Barrett" <[email-masked]>
Date: Mon, 11 Jun 2007 02:37:30 -0700

> From: Rémi Denis-Courmont [mailto:[email-masked]]
> well-implemented SIP server. And it is of course of neglectible CPU cost
> to a client.

I'm glad you agree that for non-mobile applications, keepalives are
negligible for clients and servers alike.  Is there anyone else who thinks
keepalive traffic presents real-world CPU or bandwidth problems for
non-mobile applications (and can show some kind of reality-based math to
back up the assertion), or can we lay the matter to rest?

> optional on the client side, so I would not see it as a problem if you
> think you do not need it.

The problem is its existence takes energy away from other incomplete,
higher-priority projects.  Even worse, merely discussing another reinvention
of STUN adds further delays to BEHAVE and SIP/ICE/STUN adoption as everyone
who might have considered it thinks "Whelp, I'll just do my own thing and
wait another year or so until they figure out what I'm supposed to do."

To repeat, I'd love it to exist and be widely deployed.  But until this
solution is deployed in a standard form with >90% coverage of all the
world's NAT's, it offers near zero value because every P2P application would
still need to build the exact same technology as today to accommodate
unknown timeouts.

Furthermore, to obtain >90% penetration of NATs will take *a lot* of time
and hard work.  This is a project that won't see the light of day for a
decade, at best.  I'd prefer those years of diligent, hard work were instead
focused on just getting BEHAVE more widely deployed in its current form, or
even just focused on increasing SIP/ICE/STUN's overall adoption.

-david

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 11 Jun 2007 16:17:16 +0200

Hi,

I have decided to not approve this BOF for Chicago. The main reason is 
that we should focus on getting the all the proposals currently in the 
pipe out of it. BEHAVE for example has a number of things, including 
STUN-BIS and TURN that we should get out in the near future. Having this 
BOF will be a distraction for this. I also expect MIDCOM and NSIS to 
have made progress towards publishing their solutions as RFCs.

I would recommend the proponents, interested and people seeing issue to 
keep a dialog and continue to prepare for a future BOF. I think the next 
IETF meeting in Vancouver in the fall will be a more suitable time for 
discussing the general topic on NAT control and any further work in IETF 
on this topic.

Regards

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: <[email-masked]>
Date: Mon, 11 Jun 2007 23:07:16 +0300

Hi,

Even if the BoF for IETF 69 was not approved, I think it's useful to
continue the discussion. Here are some thoughts I have about NAT/FW
control and STUN usage for it.

- As methodologies such as ICE and real-world applications such as Skype
or GoogleTalk have shown, NAT/FW traversal *can* be done relatively
effectively in general. For fixed devices and networks even the constant
keepalives to maintain state in the middleboxes is not an issue.
However, for wireless devices and networks the situation is quite
different. Keepalives, especially for UDP, consume the battery
relatively fast, as the radio transmitter/receiver needs to wake up
periodically to send otherwise unneeded packets. In practice any
application that needs to maintain a UDP mapping/pinhole, could not be
sustained for more than a few hours (as opposite to few days) in any
wide area cellular network, such as WCDMA/HSDPA or WiMAX (802.16e). TCP
already works much better, so its use e.g. for SIP is highly
recommended, but it still has the same problem in general.

- Most difficult are applications, where always-on connectivity needs to
be maintained. Examples include VoIP/IM/Presence. SIP, XMPP, Skype all
share the same problem, although typically SIP would be worst as UDP is
often used as the transport. Also, any protocols relying on UDP
encapsulation and maintaining always-on/long sessions, have the same
issues. For instance IPSec VPNs, Mobile IP, Teredo, ...

- The solution space is very challenging. The impact of IPv6 is still
very minor, also it has the same basic problem with firewalls. Of
course, the NAT/FW devices in cellular access could be configured with
longer timeouts (another useful idea in addition to TCP usage), but
there is no trivial way for applications to detect this.

- Something like STUN NAT control would be tempting for wireless devices
to implement, *if* some of the NAT box vendors would support it too, so
there would be at least some deployment potential. The biggest use cases
for UDP control would be in my opinion:
  - 1. Controlling the mappings for protocols using UDP encapsulation
such as IPSec, Mobile IP and Teredo. If the "path to the public address
space" could be controlled, these kind of protocols could allow quite
powerful connectivity with just a single UDP mapping.
  - 2. ICE optimization. Gathering candidates before sending offer or
answer can cause some delay. With STUN control, at least one candidate
could be maintained quite cheaply just waiting for a call to be
made/received, so that the offer/answer could be generated immediately.
  - I'm not so sure on SIP outbound. TCP should be used for that. More
later on.

- Another useful thing would be something that would work for TCP, since
that would help apps like SIP, e-mail etc. I'm not sure how feasible
STUN control would be. I guess in principle the tagging method in -02
draft would work, but also the TCP peer (server) would need to run a
STUN server in the same port as the app protocol and mux the two.
Current deployment of STUN would not help in bootsraping this. (Actually
SIP outbound had the muxing stuff for TCP in an earlier version. I was
against if for different reasons. I don't want to go and open that
anymore, but certainly the debate can now be seen in a bit differet
light too.)

- The biggest problem I see (in addition to usual issues with
deployment, topologies etc.) is that of a non-STUN capable firewall on
the path. This could not be detected. So, it would be hard to know when
you really have the path under control and can reduce the keepalive
messages.

Personally I think we should continue the work in this area, I don't see
the problem going away for the next few years, actually it will probably
hit the headlines sooner or later as wireless broadband starts to become
available and people notice that they still can't really run their
Skype, Gizmo or Gtalk clients in the way they would want. Some say that
the ISPs should just go for v6, but I'm doubtful.

Regards,
	Markus

---

From: <[email-masked]>
Date: Mon, 11 Jun 2007 23:16:42 +0300

Hi Magnus,

I can understand your reasoning. I just hope that we don't end up in a
situation where there is the formally agreed solution X that no-one
implements and whose only function would be to block the development of
solutions Y and Z, which perhaps could have more implementation
interest. 

Instead of a BoF, I think it would still be useful to have slot in
BEHAVE to discuss the proposal. A bar BoF should definitely be held, at
least ;)

Markus

>From: ext Magnus Westerlund [mailto:[email-masked]] 
>Sent: 11 June, 2007 17:17
>To: [email-masked]
>I have decided to not approve this BOF for Chicago. The main 
>reason is that we should focus on getting the all the 
>proposals currently in the pipe out of it. BEHAVE for example 
>has a number of things, including STUN-BIS and TURN that we 
>should get out in the near future. Having this BOF will be a 
>distraction for this. I also expect MIDCOM and NSIS to have 
>made progress towards publishing their solutions as RFCs.
>
>I would recommend the proponents, interested and people seeing 
>issue to keep a dialog and continue to prepare for a future 
>BOF. I think the next IETF meeting in Vancouver in the fall 
>will be a more suitable time for discussing the general topic 
>on NAT control and any further work in IETF on this topic.
>
>Regards
>
>Magnus Westerlund
>

---

From: Melinda Shore <[email-masked]>
Date: Mon, 11 Jun 2007 16:59:39 -0400

On 6/11/07 4:07 PM, "[email-masked]" <[email-masked]>
wrote:
> effectively in general.

One quick point - Skype in particular works by bypassing firewall
access control decisions, and that isn't a good thing.  This is
one area in which the distinction between firewall and NAT matters
a great deal.  Firewalls enforce access policies, occasionally
very complex access policies.  NATs, to the extent they deal with
policy at all, deal with address policy, and in the pure NAT case
you're not dealing with authorization questions as you are with
firewalls.

Anything that goes through a firewall without giving the firewall
adequate opportunity to say "yes" or "no" is probably not okay, and
consequently it's important to draw distinctions between firewalls
and NATs in this context.

Melinda

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 11 Jun 2007 23:07:11 +0200

> what those implementations plan to do -- maybe choose a

<delurk>

A problem with fragmentation is that the port numbers are only in the  
first fragment so fragmented packets often have trouble getting by  
firewalls.

</delurk>

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 11 Jun 2007 19:20:27 -0700

> first fragment so fragmented packets often have trouble getting by  

Good point, thanks for delurking briefly.  NATs have a similar difficultly.
I don't know if the ~20% of stacks reported at SIPit that are known to break
with fragmented UDP were considering a firewall (or NAT) between their stack
and their next-hop SIP device, though.

-d

---

From: <[email-masked]>
Date: Tue, 12 Jun 2007 11:32:12 +0300

Hi,

Yes, understood and agreed.

For a client vendor/implemeter it's an interesting dilemma whether to
support something like HTTP/TLS "tunneling". On one hand it would make
your client work in more environments (users would typically see this as
a good thing), while on the other hand you are giving tools to break
network policies (enterprise/network admins see this as a bad thing).

Markus

>From: ext Melinda Shore [mailto:[email-masked]] 
>Sent: 12 June, 2007 00:00
>To: Isomaki Markus (Nokia-SIR/Espoo); [email-masked]; Dan Wing
>Subject: Re: [BEHAVE] NAT control and STUN - some thoughts
>
>> - As methodologies such as ICE and real-world applications such as 
>> Skype or GoogleTalk have shown, NAT/FW traversal *can* be done 
>> relatively effectively in general.
>
>One quick point - Skype in particular works by bypassing 
>firewall access control decisions, and that isn't a good 
>thing.  This is one area in which the distinction between 
>firewall and NAT matters a great deal.  Firewalls enforce 
>access policies, occasionally very complex access policies.  
>NATs, to the extent they deal with policy at all, deal with 
>address policy, and in the pure NAT case you're not dealing 
>with authorization questions as you are with firewalls.
>
>Anything that goes through a firewall without giving the 
>firewall adequate opportunity to say "yes" or "no" is probably 
>not okay, and consequently it's important to draw distinctions 
>between firewalls and NATs in this context.
>
>Melinda
> 
>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 14 Jun 2007 11:51:34 +0200

> solutions Y and Z, which perhaps could have more implementation

This is clearly one of the topics that a future BOF to some degree will 
need to deal with. There are already developed solutions, and the 
question that any proponent needs to answer is why they aren't working. 
I think STUN control have some appealing arguments, but I don't think 
this is the end of the discussion.

> BEHAVE to discuss the proposal. A bar BoF should definitely be held, at

No, not a slot in BEHAVE. As I said, lets focus BEHAVE on the WG's 
current issues. We also have requested a new mailing list to move the 
STUN control discussion too. It will be announced as soon it is working. 
A Bar BOF is fine and in fact encouraged.

Cheers

Magnus Westerlund

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 14 Jun 2007 11:26:52 -0700

> [email-masked] skrev:
...
> > BEHAVE to discuss the proposal.  A bar BoF should definitely be
> > held, at least ;)
>
> current issues.  We also have requested a new mailing list to move
> the STUN control discussion too.  It will be announced as soon it is
> working.

The new mailing list has been created, "Self-Address Fixing Evolution"
(SAFE):
 
     Evolution of the protocol and procedures of RFC3489 and 
     draft-ietf-behave-rfc3489bis, so that middleboxes can be 
     discovered, queried, and controlled.

Subscribe at:  https://www1.ietf.org/mailman/listinfo/safe

Please join the SAFE mailing list if you are interested in this topic.

> A Bar BOF is fine and in fact encouraged.

I'll schedule that in a few days on the SAFE mailing list.  I am
leaning towards Monday or Thursday for that, after dinner (Tuesday 
is the social and a SPIT bar BoF has been called for Wednesday).

-d