Subject: [BEHAVE] Difference between STUN Binding Discovery and NAT Keepalive

From: "Alfred E. Heggestad" <[email-masked]>
Date: Sun, 28 Jan 2007 13:15:08 +0100

Hi

I am trying to understand the difference between the two STUN usages
defined in rfc3489-bis05, in sections 12.1 and 12.2, Binding Discovery
and NAT Keepalive. My current understanding of the two is as follows:

* Binding Discovery:
   - Used to get publicly mapped address:port
   - Used for both SIP and RTP/RTCP
   - Backwards compatible with RFC3489
   - authentication and message integrity is RECOMMENDED
   - requests SHOULD be challenged

* NAT Keepalive
   - periodic keepalive on same flow
   - detection of flow failure
   - multiplexed sockets with application
   - client SHOULD NOT use message integrity
   - server SHOULD not authenticate
   - used by outbound draft for flow keepalive

this leads to the following question:

   How can a STUN server providing both usages differentiate between the
   two usages, when both send a STUN Binding Request?

If we assume that for a particular deployed domain, there are two STUN
servers, one multiplexed with SIP on port 5060 and one standalone STUN
server on port 3478. In this case the two servers know which usage they
implement and can respond accordingly. However, the information from the
Binding Discovery STUN server on port 3478 is totally useless if the UA
is behind symmetrical NAT.. For a UA behind NAT to retrieve its publicly
mapped address, with respect to the SIP server, the SIP and STUN traffic
must follow exactly the same flow from UA via NAT to SIP/STUN server.

 From rfc3489-bis05:

12.2.7.  Client Procedures

    If the STUN Response indicates the client's mapped address has
    changed from the client's expected mapped address, the client SHOULD
    inform other applications of its new mapped address.  For example, a
    SIP client could use the binding discovery usage to obtain a new
    mapped address, and then register it using SIP registration
    procedures.

This scenario will not work for symmetrical NATs.

Typically in my UA one usage will be enough, periodically sending STUN
Binding Request messages to the SIP server, to get the publicly mapped
address:port AND keep the flow alive. If the SIP server I am currently
talking to does not have the "sip-stun" option tag, I could always
locate the STUN server for that domain using DNS SRV, but that will not
help if my UA is behind symmetrical NAT..

hopefully all my questions made sense..

/alfred

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

---

From: Vikas <[email-masked]>
Date: Tue, 30 Jan 2007 13:12:51 +0000

>>>>Before authentication it can see the request type and can
challenge if it is a binding request(see section 6 - A class of 0 is a
   Request, a class of 1 is an indication, a class of 2 is a success
response, and a class of 3 is an error response).

> >>>>>>This functionality can't be achieved only by these two STUN usage.You may have to implement ICE for that.(see section 1- It will allow incoming UDP
>    packets through NAT, but only through a subset of existing NAT types.
>    In particular, the STUN binding usage by itself does not enable
>    incoming UDP packets through NATs whose mapping property is address
>    dependent or address and port dependent [14])
>
>
>

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 30 Jan 2007 10:52:02 -0800

>    - requests SHOULD be challenged

The last two bullets provide protection against an attacker that 
is on the path between your STUN client and your STUN server.

>    - used by outbound draft for flow keepalive

One nuance with NAT Keepalive is that in the most recent version
of ICE (draft-ietf-mmusic-ice-13.txt), the NAT keepalive used
in ICE was changed from a Binding Discovery / Binding Response
exchange to an Indication.  The Indication is a unidirectional
STUN message, which has no response.

draft-ietf-behave-rfc3489bis has not yet been updated to align
with this change to draft-ietf-mmusic-ice-13.

>    How can a STUN server providing both usages differentiate 
> between the two usages, when both send a STUN Binding Request?

The STUN server listening on UDP/5060 will only receive STUN
messages for the Keepalive Usage.

> If we assume that for a particular deployed domain, there are two
> STUN servers, one multiplexed with SIP on port 5060 and one
> standalone STUN server on port 3478. In this case the two servers
> know which usage they implement and can respond accordingly.
> However, the information from the Binding Discovery STUN server on
> port 3478 is totally useless if the UA is behind symmetrical NAT..

It's not totally useless -- even if you're behind a symmetric NAT
you can still establish bi-directional UDP communication with 
another endpoint if that other endpoint knows its transport 
address.  

However, if that other endpoint is _also_ behind a symmetric NAT, 
you a media relay (TURN server or SBC) is necessary.

ICE describes the procedures to do this.

> For a UA behind NAT to retrieve its publicly mapped address, with
> respect to the SIP server, the SIP and STUN traffic must follow
> exactly the same flow from UA via NAT to SIP/STUN server.

A SIP client, which wants to learn its public transport address
for SIP traffic, doesn't need to talk to the STUN server 
listening on UDP/3478 -- it only needs to talk to the STUN
server embedded with its SIP proxy on UDP/5060.

Are you concerned about the different SHOULDs around 
message integrity for the Binding Discovery usage?

> This scenario will not work for symmetrical NATs.

It will work if the STUN Binding Request is sent to the same
port as all SIP traffic (UDP/5060), and demultiplexed by the
SIP proxy.

> address:port AND keep the flow alive.

I just searched draft-ietf-sip-outbound-07, and can't find where
it is necessary for the SIP UA to learn its public IP address and
UDP port.  That is, other than learning that it *changed* (which
it can learn via the periodic keepalives), it seems that 
draft-ietf-sip-outbound-07 doesn't say the SIP UA needs to
learn its public transport address using STUN.   It's not
necessary, anyway -- the SIP proxy knows the transport address
of an incoming UDP packet when the SIP proxy receives the packet.

> If the SIP server I am currently
> locate the STUN server for that domain using DNS SRV, but 
> that will not help if my UA is behind symmetrical NAT..

-d

---

From: "Alfred E. Heggestad" <[email-masked]>
Date: Wed, 31 Jan 2007 23:38:05 +0100

Hi Dan,

thanks for your reply, see inline.

> with this change to draft-ietf-mmusic-ice-13.

ah, ok. is unidirectional STUN indication (sent from UA) guaranteed
to work with all types of NAT boxes ? is it not so that certain
NATs assume bidirectional traffic to keep the flow open?

will STUN Binding Indication be a new STUN message in rfc3489bis-06 ?

> messages for the Keepalive Usage.

ok fair enough.

> ICE describes the procedures to do this.

OK maybe my question was a bit vague. I am aware of ICE/TURN and
how the media/NAT can be solved by that.

I was mainly asking STUN-related questions, with a view from the
outbound draft ;)

> message integrity for the Binding Discovery usage?

Yes, agreed. To get my public SIP address I only need to send
a STUN Binding Request to my SIP Proxy at UDP/5060.

I am not concerned about the message integrity, I am mainly
trying to understand why Binding Discover and NAT Keepalive
usage cant be just one usage (i.e. the same) instead of two
usages that are protocol-wise very similar ..

> port as all SIP traffic (UDP/5060), and demultiplexed by the

yes. so the new section in rfc3489-bis05 12.2 NAT Keepalives is
mainly a tool for outbound, and should go to UDP/5060 ?

but section 12.2.7 says "...SIP client could use the *binding discovery* usage
to obtain..." - why recommend that the client has to send a new STUN Binding
Request, when the client at the same to has just got the new publicly mapped
address:port from the current NAT Keepalive Binding Response ?

> of an incoming UDP packet when the SIP proxy receives the packet.

ok, it was my assumption that the publicly mapped address from
the STUN Binding Response was used to updated the Via: and Contact:
headers of the SIP UA. But you are right; the SIP proxy knows
where the SIP message came from.

should we ask the outbound people if this could be clarified?

so can we conclude with the following statement (simplified):

   port 3478: STUN Binding Discovery
   port 5060: SIP and STUN Keepalive

many thanks for your clarifications, I think things are bit
clearer now ..

/alfred

<snip>