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

From: "Dan Wing" <[email-masked]>
Date: Thu, 1 Feb 2007 09:21:34 -0800

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

Traffic from inside->outside is sufficient to keep the binding
active.  

This means that if two ICE-aware endpoints are behind their 
own respective NATs, they'll both need to transmit STUN 
Indication keepalives to keep their own respective NAT 
bindings open (or, of course, send RTP or RTCP packets).

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

(They're just called "Indications", not "Binding Indications")

Indications are mentioned in the existing -05 specification, but 
it says that only TURN uses Indications (because rfc3489bis hasn't 
been updated to reflect ICE-13's new use of Indication for ICE's 
keepalive):

http://tools.ietf.org/html/draft-ietf-behave-rfc3489bis-05#section-7.2
 
...
> 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 ..

It's an attempt to reduce confusion.  In sip-outbound, the
STUN protocol is not used to discover your initial binding; the 
STUN protocol is only used to keep an existing binding alive 
and to detect when a re-Register is needed (that is, when your
initial binding changed).

I'd say sip-outbound's usage of the STUN protocol does a little
of both; it doesn't fit cleanly into 'keepalive' nor 'binding
discovery'.

The usages, as separated in rfc3489bis, are intended to ease
implementation of a STUN client and server so that you know
which STUN message types to support (Binding Request/Response,
Indications, etc.), and which STUN attributes you need to
support.  Perhaps they're failing at their intended purpose;
I don't see a better way to split things up but I'm open to
suggestions.

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

Yes.  Outbound should reference this section of rfc3489bis 
explicitly (that is, by section number).

> but section 12.2.7 says "...SIP client could use the *binding 
> discovery* usage to obtain..." 

Yeah, that's wrong, as outbound doesn't do that.  I believe
in some earlier version of outbound we did think it might
be useful to first do a STUN Binding Request in order to
populate the Contact header correctly, but that was deemed
unnecessary and isn't in the last few versions of outbound
(it may have never made it into the text and was just a 
hallway conversation, I don't recall exactly now).

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

According to outbound, the first packet you send to UDP/5060
is a SIP Register, though, right?  It's only to keep the
binding alive (and to learn of a new NAT binding) do you 
occasionally send a STUN Binding Request packet to UDP/5060
every NNN seconds.

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

Absolutely.
 
> so can we conclude with the following statement (simplified):
> 
>    port 3478: STUN Binding Discovery
>    port 5060: SIP and STUN Keepalive

If you're only thinking of SIP-Outbound, there isn't a need at all
for a STUN server listening on UDP/3478.  It's only needed for ICE.

-d

> 
> 
> many thanks for your clarifications, I think things are bit
> clearer now ..
>
> /alfred
> 
> 
> <snip>

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