Subject: RE: [BEHAVE] NAT Control STUN Usage

From: "Dan Wing" <[email-masked]>
Date: Fri, 1 Jun 2007 12:12:10 -0700

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

Thanks for your note of support.

I added a capability to discover firewalls in the -02 document
via a 'tagging' mechanism, which is similar to how NSIS/TIST/NLS
find their on-path NSIS/TIST/NLS-aware devices, yet still provides
the incremental deployment of STUN and STUN Control.  It's
in section 5.3 of the -02 version of the document (which appears
to not have yet been posted), available at:
http://svn.resiprocate.org/rep/ietf-drafts/dwing/draft-wing-behave-nat-contr
ol-stun-usage-02.html#anchor7

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

Thanks again,
-d

> 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:
> >>> 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
> >
> 
> 
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/behave
> 

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

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 1 Jun 2007 12:17:58 -0700

Melinda Shore [mailto:[email-masked]] wrote:

> On 5/30/07 9:57 AM, "Magnus Westerlund" 
> <[email-masked]> wrote:
> > 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.
> 
> 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. 

ICE resolves that specific problem by using multiple candidates.

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

I believe you are, here, referring to ICE's use of candidates,
which I know you find unappealing.  

ICE does bound the number of messages it sends, and it does
prioritize the discovery messages in order to quickly find a
useable candidate address.

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

-d

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 1 Jun 2007 13:07:03 -0700

Melinda Shore [mailto:[email-masked]] wrote:

> On 5/30/07 5:32 PM, "Philip Matthews" 
> <[email-masked]> wrote:
> > I would be interested in hearing what you see as the 
> > deployment problems.
> 
> Sure:
> 
> You need to have something that can turn the message around and
> provide a reply,

That would be a STUN server, in the case of today's STUN, and also
in the case of draft-wing-behave-nat-control-stun-usage.

> or else you need to receive responses back from
> the middleboxes. 

> The first option is unreliable

It is no more unreliable than other UDP-based protocols (e.g., DNS).

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

Yep, and that's only necessary if the discovery process includes firewall
discovery.  It wasn't until -02 that firewall discovery was in
draft-wing-behave-nat-control-stun-usage; prior to that the document only
did NAT discovery which doesn't lead to expansion of the response message to
discover on-path NATs.

I'm not sure what you're referring to with 'message proliferation' -- is
that in relation to discovery or control of multiple middleboxes, all of
which need to be discovered and controlled separately causing proliferation
of messages to each of them, or referring to something else?

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

That is the substantial difference between
draft-wing-behave-nat-control-stun-usage and previous attempts in this space
(e.g., UPnP, MIDCOM, NSIS).

With draft-wing-behave-nat-control-stun-usage, the security model is easier
because you're using the same host port ('socket') to open the NAT binding
as you're using to discover on-path NATs as you're using to request the NAT
to extend its binding timeout.  Most other approaches (e.g., MIDCOM and
NSIS) do need a more involved security model because they need to create
some association between the host and its NAT and what the host wants the
NAT to do.  To another extreme, other approaches (e.g., UPnP and NAT-PMP
(Bonjour)) allow any internal host to request and open any NAT binding it
wants -- for other hosts or for other ports on the same host.

This makes STUN, and STUN Control, unique -- in order to open a binding for
a port, you need to send a packet from that port, and in order to adjust its
binding duration you need to send a packet from that same port and be able
to respond to the NAT's nonce challange.  This means to adjust someone's NAT
binding using draft-wing-behave-nat-control-stun-usage  the attacker needs
to be on-path between the host and its NAT -- such an attacker is able to
already cause much harm to existing protocols such as DNS and TCP which
cannot adequately defend themselves from that same on-path attacker.

> and you'll be doing it in situations where you're
> trying to limit packet size (avoid UDP fragmentation) 

draft-wing-behave-nat-control-stun-usage only increases packet size with the
new 'tagging' feature, added in -02 to support Markus' request for discovery
of on-path firewalls.  This discovery adds 12 bytes to the STUN Response
packet for every firewall that wants to be separately controlled using STUN
Control.  The typical STUN Response packet is approximately 150 bytes
(including IP and UDP headers).  I think we're fine -- we can have about 30
on-path firewalls before exceeding 512 bytes.  (I chose 512 bytes because
that's what DNS chose and it seems reasonable.)

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

STUN Control has no need for such heavy-handed security because
each port on the host can only adjust its own bindings on the 
NAT.

Crossing administrative boundaries isn't possible with typical
NAPTs because a packet has to originate from behind the NAPT
in order to create the binding on the NAPT.  Anyway, handling
authorization across domains isn't related to what 
draft-wing-behave-nat-control-stun-usage attempts to address 
because a host can only control NAT bindings that it, itself
created with its own UDP port.  As the host didn't create NAPT
bindings on public interfaces of another administrative domain's
NAT, it cannot control them.  The other administrative domain 
is responsible for its own policy -- just as today they are 
responsible for whatever their NAT traversal scheme is (if any)
and for keeping their NAT bindings alive (if any), their own
HTTP proxies, and their own firewall policies and whatever else
they like to run.  

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

Your points in the above two paragraphs are related to ICE and
if ICE determines (through its connectivity checks) that it needs a 
relay (a TURN server) or if ICE discovers (through its connectivity
checks) if can establish connectivity without a relay using IP 
addresses learned via STUN.  This is interesting but not germane 
to draft-wing-behave-nat-control-stun-usage.

Further, the existing deployments of ICE, on the Internet, have
demonstrated it works 100% of the time.  

I do hope the vendors that have shared that information with me 
privately are able to comment to that effect publicly in this 
thread.

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

Merely sending a UDP or TCP packet across a NAT creates state --
the NAT binding.  All draft-wing-behave-nat-control-stun-usage
does is query the NAT for its binding duration and provide a way
to adjust that duration -- and that query and control is only 
for the same IP address and same UDP port that created that 
initial state on the NAT.

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

draft-wing-behave-nat-control-stun-usage avoids this complication
by using the same IP address and UDP port on the host that created
the NAT binding.

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

-d

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 1 Jun 2007 13:22:02 -0700

Melinda Shore [mailto:[email-masked]] wrote:

> On 5/31/07 2:12 PM, "Philip Matthews" 
> > 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?
> 
> 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.
> 
> > Some, but not all, of them are mitigated by the Shared 
> > Secret exchange, 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.

RFC3489's shared secret exchange only provides protection against an
attacker who is on-path during subsequent UDP communications with your STUN
server.  The protection prevents that attacker from spoofing STUN responses;
the attacker could spoof those responses in order to:

  1. cause you to insert a victim's IP address into your subsequent SDP (in
order to use you as a launchpad for a DoS attack against a victim), or to
  2. give you an IP address they control so that you use it in your
subsequent SDP (in order that they can guarantee they'll be one of the
candidate IP addresses and increase the chance they'll be on-path for your
subsequent communication)

(1) was a significant attack when we had only RFC3489 (STUN).  With the
advent of ICE and ICE's connectivity checks, only 6 packets would be sent
towards that victim machine (if the victim isn't listening for STUN
packets); less if the victim is listening for STUN and sends a STUN error
response.

(2) the attacker was already on-path between the STUN client and its STUN
server (in order to spoof the STUN response), so it's possible -- depending
on where the attacker is located -- that they might not be on path for the
natural communication with your peer.  An attacker located next to the STUN
server might be interested in this attack, for example; but an attacker in
the same coffeeshop (on the same 802.11 network, for example) would not need
to perform this active attack because they will still be on-path for your
subsequent communication with your intended peer.

(2) is also thwarted by using SRTP.

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

draft-wing-behave-nat-control-stun-usage is outside of BEHAVE's current
charter, which is why a BoF has been requested to discuss if and how
draft-wing-behave-nat-control-stun-usage should be standardized in IETF.

> Take another look at the draft - it's *definitely* defining on-path 
> signaling to NATs,

Yes, it is.

> and it's doing it without referencing existing on-path signaling
> protocols.

draft-wing-behave-nat-control-stun-usage's NAT discovery and especially its
NAT Control technique works differently than previous NAT control
techniques.  All other techniques have involved a separate control channel
(SNMP for MIDCOM; UPnP invented its own XML-based protocol), whereas
draft-wing-behave-nat-control-stun-usage uses the same UDP port that
originally opened the NAT binding in order to control that very same NAT
binding's timeout.

There is overlap with draft-wing-behave-nat-control-stun-usage-02's new
"tagging" discovery technique with NSIS, TIST, and NLS; the new "tagging"
discovery technique is used to find firewalls (not NATs).  I included a
reference to NSIS, TIST, and NLS when I added that new discovery technique.

-d