Subject: Re: [BEHAVE] NAT Control STUN Usage

From: Magnus Westerlund <[email-masked]>
Date: Wed, 30 May 2007 15:57:13 +0200

Magnus Westerlund skrev:
> Philip Matthews skrev:
>> Sorry to be coming into this conversation late.
>> I am just catching up on various mailing lists after finishing my drafts.
>>
>> BEHAVE is chartered to work on STUN.
>> STUN requires STUN servers to work, and defined how they behave.
>> Why shouldn't we recommend placing some of the servers into NATs
>> as this draft does?
>>
>> This draft is trying to address the problem of finding the allocated 
>> mappings
>> for nested NAT cases. I think this problem is an important one to solve,
>> because nested NATs are becoming more and more common.
>>
>> I think BEHAVE is a good place to work on a solution to this problem,
>> and I think the proposed solution is reasonable.
>>
>> I think it would be silly to NOT solve this problem just because of
>> charter issues.
>>
> 
> The problem is that large parts of this problem already has been solved 
> in the numerous NAT control protocols. Even in IETF we have two 
> different WG currently chartered with solving NAT control issues, MIDCOM 
> and NSIS. Going in this new direction for BEHAVE needs IETF wide 
> consensus and also good arguments why previous efforts are not solving 
> the problem. So if you are interested in this issue, please get together 
> and start discussing having a BOF.
> 

Hi,

Dan has requested a BOF on this topic. But I still haven't seen much 
debate why we would need something other than what is already under 
development within the IETF. I would appreciate some discussion and 
clarification before making any decision if there should be an BOF or not.

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]
----------------------------------------------------------------------

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

---

From: <[email-masked]>
Date: Wed, 30 May 2007 17:58:55 +0300

Hi,

I think STUN NAT control would be very valuable.

Explicit NAT/FW control in general is important especially for wireless
devices, where keepalives (especially for UDP) are really bad for
battery consumption. This is not just a nice-to-have optimization, but I
believe that in practice you could not use Internet-based VoIP/IM
services over e.g. HSDPA or WiMAX, if you had to do the keepalives in
the current way.  

What makes STUN interesting compared to e.g. NSIS is its incremental
deployment path. STUN is already supported in many SIP and XMPP clients,
and the popularity is increasing. An existing STUN client implementation
can be relatively easily extended to support NAT control as well (small
thing compared to e.g. full ICE support). STUN NAT control would then
very well fit into the process how STUN is otherwise used, so the cost
would be quite small even if there were no STUN-capable NATs on client's
path. STUN-capable NATs could then be gradually deployed to improve the
situation. Frankly, I don't see a similar deployment potential for NSIS.

In comparison to UPnP STUN has certain technical benefits like the
ability to deal with nested NATs. Also, UPnP is quite limited to local
area use and would not solve the wide-area wireless access issue I
mentioned in the beginning.

To have best possible value, I think STUN NAT control should also have a
way to deal with firewalls without NATs, i.e. there would have to be a
way to discover if there are STUN capable firewalls on the path. Of
course, the more we add to the protocol the less obvious the incremental
deployment argument becomes.

So, in summary: This is a pressing problem. None of the existing
solutions look promising for getting deployed. STUN NAT control has
certain aspects that would make the deployment more incremental and thus
easier. Thus, I am very supportive for the approval of the BoF.

Regards,
	Markus 

>-----Original Message-----
>From: ext Magnus Westerlund [mailto:[email-masked]] 
>Sent: 30 May, 2007 16:57
>To: Magnus Westerlund
>Cc: [email-masked]; Philip Matthews; Dan Wing
>Subject: Re: [BEHAVE] NAT Control STUN Usage
>
>Magnus Westerlund skrev:
>> Philip Matthews skrev:
>>> Why shouldn't we recommend placing some of the servers into NATs as 
>>> this draft does?
>>>
>>> mappings for nested NAT cases. I think this problem is an important 
>>> one to solve, because nested NATs are becoming more and more common.
>>>
>> The problem is that large parts of this problem already has been 
>> solved in the numerous NAT control protocols. Even in IETF 
>we have two 
>> different WG currently chartered with solving NAT control issues, 
>> MIDCOM and NSIS. Going in this new direction for BEHAVE needs IETF 
>> wide consensus and also good arguments why previous efforts are not 
>> solving the problem. So if you are interested in this issue, please 
>> get together and start discussing having a BOF.
>> 
>
>Hi,
>
>Dan has requested a BOF on this topic. But I still haven't 
>seen much debate why we would need something other than what 
>is already under development within the IETF. I would 
>appreciate some discussion and clarification before making any 
>decision if there should be an BOF or not.
>
>Magnus Westerlund
>

---

From: Melinda Shore <[email-masked]>
Date: Wed, 30 May 2007 13:31:38 -0400

> clarification before making any decision if there should be an BOF or not.

It seems dubious to me that yet another on-path signaling protocol is
needed, or particularly that yet another on-path NAT signaling protocol
is needed, when the problems that limit the deployability of any
on-path NAT signaling protocol in the first place remain unsolved.

I initially brought the on-path firewall/NAT signaling work to the IETF
lo, those many years ago because it solves some hard problems around
topology and ordering.  Unfortunately, however, it requires that at
least one end of a "path" not be NATted, and that either or both peers
know that it's not NATted.  The solutions that have been proposed (when
they've been proposed - there's been a lot of hand-waving) are often
worse than the problem, involving throwing new elements into the network
or sending out an effectively unbounded number of messages to do discovery.

The on-path stuff is extremely appealing but I think there are some
difficult problems that need to be solved before it can be deployed, and
it seems to me that it ought to be deployable before developing a
redundant protocol.

Melinda

---

From: Philip Matthews <[email-masked]>
Date: Wed, 30 May 2007 17:24:04 -0400

On 30-May-07, at 09:57 , Magnus Westerlund wrote:

> Magnus Westerlund skrev:
>
> Hi,
>
> Dan has requested a BOF on this topic. But I still haven't seen  
> much debate why we would need something other than what is already  
> under development within the IETF. I would appreciate some  
> discussion and clarification before making any decision if there  
> should be an BOF or not.

There are two parts to the problem:  Discovering nested NATs and  
Controlling NATs.

The Discovery part, in my opinion, is the most basic and more  
important part of this work. This allows ICE to work in cases where  
another NAT does not support hairpinning, and allows ICE to find a  
more efficient path in cases where the NATs involve do  support  
hairpinning.
The discovery portion is also the most straight-forward part of the  
problem, as I don't think it raises any additional security concerns.

The Control part is also useful, but it requires the Discovery  
portion, raises some security questions and seems to be the  
controversial aspect.

So I think the debate should be: Do we do Discovery+Control, or just  
start with the Discovery part?

I do not object to doing Discover+Control, but I don't want to lose  
the Discovery just because we tried to do the Control part.

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Wed, 30 May 2007 17:32:34 -0400

> on-path NAT signaling protocol in the first place remain unsolved.

I would be interested in hearing what you see as the deployment  
problems.

- Philip

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 31 May 2007 15:08:17 +0300

On Wednesday 30 May 2007 20:31:38 ext Melinda Shore wrote:
> needed,

STUN has already running on the real-life Internet for quite a while. This 
usage leverage and extend on that.

STUN makes a lot of sense particularly in ICE context given clients have to 
have it anyway, and the added complexity is minimal.

> or particularly that yet another on-path NAT signaling protocol 
> is needed,

Only real-life NAT control protocols are UPnP (bloated and buggy protocol 
designed outside IETF) and NAT-PMP. Both are unable to accomodate multiple 
hops, as STUN does.

> when the problems that limit the deployability of any 

Well, you do have to upgrade the NAT boxes to support the protocol. Though 
STUN has the interesting property that it still provides added value even if 
not all of the on-path NATs supports it: it still lets you discover 
intermediate NAT address bindings, for use in ICE or similar connectivity 
frameworks.

-- 
Rémi Denis-Courmont

---

From: Melinda Shore <[email-masked]>
Date: Thu, 31 May 2007 10:58:48 -0400

> I would be interested in hearing what you see as the deployment

Sure:

You need to have something that can turn the message around and
provide a reply, or else you need to receive responses back from
the middleboxes.  The first option is unreliable and the second
option leads to the possibilities of message proliferation and
message expansion (since you can no longer rely on packet rewriting
as a way of propagating topological information).

You need to have some way to secure messages when you don't
know in advance who you'll be sending messages to/receiving
messages from, and you'll be doing it in situations where you're
trying to limit packet size (avoid UDP fragmentation) and limit
computational load (public key operations in a middlebox).  We
found that group keys are an excellent solution for use within
a single security domain, but are obviously unsuitable for use
in situations in which you might be crossing arbitrary administrative
boundaries and can't know in advance who they'll be.

One end or the other end has to have a public address/presence.
If neither end has a public address or presence, that presence
has to be outsourced to some other device.  That often means
dropping yet another box (a relay, for example) into both ends
of the network.  The placement of the relay has to be topologically
appropriate to the endpoints or else the relay ends up being
a sort of SBC.

If you do go with a relay, you have to have some way to associate
it with the endpoint and you have to have some way to publicize the
association.  The way that's typically handled right now is through
telephony signaling.  In fact, this whole thing is looking an
awful lot like a VoIP network, and it's not actually very useful
for other applications.  (Presumably that's the reason for an
interest in using STUN rather than an actual signaling protocol,
as well).

It's doable, but it's not doable in a general way and it's really
going to work only in very constrained environments.  It's not an
80/20 solution, but rather a 20/80 one.

And, by the way, STUN would probably need substantial changes
to the protocol machinery in order to handle state maintenance.
Packetization is really not that interesting (a little interesting,
but not a lot) - what matters is how the protocol behaves.  "NAT
control" installs state in middleboxes - you'll need to be able
to handle errors like transmission failures, device reboots,
routing changes, and so on.  You'll also need to be able to delete
the state you install.  By the time you're done tweaking it so
that it will be a useful state maintenance tool you'll have a
full-blown signaling protocol, only a quirky one that's not
very general and probably isn't very different from other signaling
protocols aside from packetization.  (FWIW, a few years ago I
wrote up a "STUN-based Signaling" specification that uses the NLS
state machine but STUN packetization, and there should still be
copies floating around ID archives - it solves a political problem
but not a technical one and was rightly ignored).

I could accept (and do accept) the argument that NSIS is not a
good choice for situations in which the substantial set up costs
can't be amortized well, but that's not the argument that's being
presented here.

Anyway, the broader point is that we've already done on-path
signaling six ways from Sunday and the hard problems association
with NAT signaling remain unsolved.  I have a hard time seeing why
it's a good idea to create yet another protocol while continuing to
avoid dealing with the problems associated with the architecture.

Melinda

---

From: Philip Matthews <[email-masked]>
Date: Thu, 31 May 2007 14:12:27 -0400

Thanks for detailed response!
However, I am not  sure I really understand all your points.
See inline.

> as a way of propagating topological information).

If I understand you correctly, STUN currently takes the first approach
by requiring a STUN server somewhere in the network. And you consider
this unreliable because there is nothing that forces someone to provide
a STUN server?  Do I understand you correctly?

> boundaries and can't know in advance who they'll be.

In the STUN case, I think you are referring to the various attacks  
against STUN.
Some, but not all, of them are mitigated by the Shared Secret exchange,
but in practice not many people seem to implement this.

> can't be amortized well, but that's not the argument that's being

I confess I didn't understand the above points. Perhaps you  
misunderstand
what Dan is proposing to do with STUN? All he is proposing (as far as  
I know),
is to  discover the binding that a NAT has installed for a particular  
local host and port,
and then either query the NAT for the timeout value associated with
the binding, or suggest a value to the NAT.
He is NOT proposing to use STUN to signal the connection, and the  
only other
involvement of STUN will be as part of ICE to select a path for the  
media.

Or perhaps is it just me that is all confused?

- Philip

---

From: Melinda Shore <[email-masked]>
Date: Thu, 31 May 2007 14:51:20 -0400

> a STUN server?  Do I understand you correctly?

It forces the STUN server to be 1) addressable (not so much
of an issue), and 2) in a topologically-appropriate location.
Problem 2) has led to the development of ICE, about which the
less is said the better.

> but in practice not many people seem to implement this.

Well, on the one hand the exchange is of really limited utility
since it doesn't prove identity, but on the other hand it's the
only protection (other than obscurity) against an attacker.
Explicit signaling is always going to be more secure, *if*
you can authenticate the NAT.

> All he is proposing (as far as
> I know),

Look, STUN was "just" going to be used until midcom was finished.  And
then it was "just" to be used in cases where a NAT cannot be modified.
And then BEHAVE was "just" going to define NAT behavior so that STUN
would work across it.  And now it's "just" putting a STUN server
inside a NAT so that a NAT is basically a midcom device.  Take another
look at the draft - it's *definitely* defining on-path signaling to
NATs, and it's doing it without referencing existing on-path signaling
protocols.

Melinda

---

From: Philip Matthews <[email-masked]>
Date: Thu, 31 May 2007 15:55:50 -0400

> Problem 2) has led to the development of ICE, about which the

I still don't understand.
As I see it, the biggest advantage of Dan's draft is that allows a  
client to
discover NATs, and thus STUN servers can be placed in the most
topologically-appropriate location of  all: namely, the NAT itself.

> you can authenticate the NAT.

Though you dismissed ICE above, to my mind the advantage of ICE
is that it solves a lot of the security problems of STUN.
That is why I am less worried about the STUN security problems.

> NATs, and it's doing it without referencing existing on-path signaling

I agree that there is not much comparison with other approaches in  
the draft.
In fact, I confess to be pretty ignorant of other approaches myself.
I guess I should go and read some Midcom documents.

- Philip

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 31 May 2007 14:35:12 -0700

Melinda Shore wrote:

[snip]
> NATs, and it's doing it without referencing existing on-path signaling

Tiny little Behave mutates and grows and can potentially replace big
Midcom .  Looks to me as evolution applied to protocol engineering.  It
works for operating systems[1], why not for network protocols?

[1] http://kerneltrap.org/node/11

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