Subject: [Sipping] Making SBCs more transparent for NAT traversal

From: [email-masked]
Date: Fri, 28 Oct 2005 16:53:37 +0300

Hi,

One of the most common functions that SBCs or Back-to-Back UAs in general are used is NAT traversal. There are a couple of quite crucial benefits for doing this:
- There is no need to implement complex things like ICE or TURN in the User Agent, and this makes deployment much faster. 
- In the cellular wireless environment use of STUN and TURN is problematic. If you want to keep the UDP bindings for media open constantly just in case they are needed, you will drain the battery in the device quite dramatically (at least in WCDMA this is a clear issue, and basically in all other radio technologies, where the device can go to some sort of "idle" or "power saving" mode). On the other hand if you do STUN/TURN only when someone sends an INVITE to you or you want to send INVITE, the session setup time will increase due to additional RTTs.

On the other hand we know that SBCs are evil, since while tampering with the SDPs they break end-to-end security. Also, if all media flows need to traverse through SBCs, that will increase the cost of the SIP infra and introduce unreliability.

I believe the IETF should consider how to build a compromise in this area. If the problem is that the SBCs do things without the UAs knowing about this, we should develop mechanisms how the UA can actually ASK the SBC to do something. Also, if there is a problem in changing the SDP, we should develop mechanisms how to distinguish between things that are e-2-e protected and where adding/modifying is appropriate.

Wouldn't it be possible to define something which on the high level looks like this:
- Assume that ICE is used as the framework for NAT traversal
- UAs may still use STUN and TURN to derive public addresses, if that is appropriate (taking the wireless terminal issue above into account)
- UA can include the addresses that it has for each media stream as candidates
- In addition to that, UA can *ASK* an SBC (assuming some sort of discovery mechanism to know that there is this type of function in the network) to provide one more candidate for those media streams it wants. For these the SBC would add a new candidate that would point to SBC's media relay, which would relay the traffic toward the UA.
- Receiver of the SDP is able to see which candidates where provided by the UA (and that those were unchanged) and which ones were added by intermediaries (assume that those could be protected by some m-2-e mechanism too)
- If the UA does not ask SBC interaction (for instance it is using TURN), SBCs are not allowed to do anything (or if they do, they at least must indicate that with the evil bit ;-)

I assume the overall solution can be reached by combining some ongoing work like
- ICE
- Session policies?
- End-to-middle security
- draft-wing-sipping-multipart-mixed-00

How about working toward this type of a goal in SIP/SIPPING? At least that would be better than the current situation where SBCs are used quite widely, while the IETF is listing issues why they should not be used.

(Another thing I'm worried is that e.g. in 3GPP and ETSI TISPAN SBCs seem to be the *only* standardized mechanism for NAT traversal. This means that all media flows pass through them *always*, regardless of whether there even is NAT or whether the UA is actually using STUN or TURN and would not even need the SBC to do anything. I think it would be good if there was something explaining to those folks that even if there may be some cases where using an SBC for NAT traversal might make sense, it does not have to be used for *all* UAs and *all* sessions.)

Regards,
	Markus 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Oct 2005 10:18:29 -0400

> - In the cellular wireless environment use of STUN and TURN is problematic. If you want to keep the UDP bindings for media open constantly just in case they are needed, you will drain the battery i…

Markus, I would like to understand this better. It feels like there is a 
fundamental dilemma regarding the power management for this wireless device.

On one hand, you want to avoid sending anything when you have nothing to 
say. On the other hand, the other elements in a call have resources 
committed to it, and want to abandon the call if the mobile is no longer 
there. All these various techniques amount to keep alive messages of one 
form or another. Ultimately the mobile has to send *something* 
periodically to prove that it is present and functioning.

So it seems that the best you can hope for is that the mobile only has 
to send one or a few things, at a frequency that doesn't bother it too 
much, and that everything that holds state for the call can be assured 
as a result of this minimal signaling.

I *think* the SBC's role in this is that by coupling signaling and 
media, it can use keep-alives on the signaling channel as proof that the 
mobile is alive, and keep generating its own keep-alives on the media 
channels.

This imposes both assumptions and constraints on the relationship 
between media and signaling sources. After all, sip explicitly decouples 
signaling and media.

If you have to turn on the radio periodically to send *some* sort of 
keepalive, does it cost significantly more to send several of them? Or 
is it that the frequencies differ for the various ones and so you need 
to turn on the radio independently for each one. If so, maybe that is an 
area where some work could yield benefits.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 28 Oct 2005 11:31:34 -0400

Markus,

Thanks for starting a discussion on this. This is a topic near and dear
to my heart. More below.

[email-masked] wrote:

> Hi,
> 
> One of the most common functions that SBCs or Back-to-Back UAs in
> general are used is NAT traversal. There are a couple of quite
> crucial benefits for doing this: - There is no need to implement
> complex things like ICE or TURN in the User Agent, and this makes
> deployment much faster.

Well, thats debatable.

> - In the cellular wireless environment use of
> STUN and TURN is problematic. If you want to keep the UDP bindings
> for media open constantly just in case they are needed, you will
> drain the battery in the device quite dramatically (at least in WCDMA
> this is a clear issue, and basically in all other radio technologies,
> where the device can go to some sort of "idle" or "power saving"
> mode).

I'm confused here. With ICE, you don't send packets all the time - only 
when you make a call. There is a bunch of packets excahgend at call 
setup time, and then once the call is setup, a periodic keepalive just 
on the selected media stream - once every 15s or so. That is a trivial 
percentage of the voice traffic, which is still flowing. So, I don't 
understand the issue.

> On the other hand if you do STUN/TURN only when someone sends
> an INVITE to you or you want to send INVITE, the session setup time
> will increase due to additional RTTs.

The latest ICE spec talks about how to use ICE and not see any increase 
in call setup. The key idea is to do the allocations based on UI hints 
on the originator. For example, on a mobile, it would be when the user 
enters there address book or begins entering digits on the keypad. Even 
if you dont do that, there are optimizations you can make in ice 
processing that will send an immediate invite without any stun/turn 
allocations; those would be done in parallel with the invite, and then 
only added in an UPDATE if the native IP/port didnt't immediately work.

> 
> On the other hand we know that SBCs are evil, since while tampering
> with the SDPs they break end-to-end security. Also, if all media
> flows need to traverse through SBCs, that will increase the cost of
> the SIP infra and introduce unreliability.
> 
> I believe the IETF should consider how to build a compromise in this
> area. If the problem is that the SBCs do things without the UAs
> knowing about this, we should develop mechanisms how the UA can
> actually ASK the SBC to do something. 

Sure, we have that already. If a service provider wants media relay, 
great. They can have it. Session policy would provide the endpoint with 
a turn relay address, and the endpoint would request an address from the 
turn relay before making a call. If you want, that (and only that) 
address would be included in the invite. Operator policy could dictate that.

> Also, if there is a problem in
> changing the SDP, we should develop mechanisms how to distinguish
> between things that are e-2-e protected and where adding/modifying is
> appropriate.

I would rather not do that. I think it is better to have mechanisms that 
allow operators to specify control with endpoints making the modifications.

> 
> Wouldn't it be possible to define something which on the high level
> looks like this: - Assume that ICE is used as the framework for NAT
> traversal - UAs may still use STUN and TURN to derive public
> addresses, if that is appropriate (taking the wireless terminal issue
> above into account) - UA can include the addresses that it has for
> each media stream as candidates - In addition to that, UA can *ASK*
> an SBC (assuming some sort of discovery mechanism to know that there
> is this type of function in the network) to provide one more
> candidate for those media streams it wants. 

Exactly. TURN server *is* the "SBC" in this model. I put "SBC" in quotes 
since its not quite; it doesnt work the way they do today (acting as 
b2bua), but it does act as a media and signaling intermediary.

For these the SBC would
> add a new candidate that would point to SBC's media relay, which
> would relay the traffic toward the UA. - Receiver of the SDP is able
> to see which candidates where provided by the UA (and that those were
> unchanged) and which ones were added by intermediaries (assume that
> those could be protected by some m-2-e mechanism too)

Not sure why that is needed.

> - If the UA
> does not ask SBC interaction (for instance it is using TURN), SBCs
> are not allowed to do anything (or if they do, they at least must
> indicate that with the evil bit ;-)
> 
> I assume the overall solution can be reached by combining some
> ongoing work like - ICE - Session policies? - End-to-middle security 

I believe ICE+session policies covers what you need.

> How about working toward this type of a goal in SIP/SIPPING? At least
> that would be better than the current situation where SBCs are used
> quite widely, while the IETF is listing issues why they should not be
> used.

Right. I would like to understand what the perceived problems are with 
the ICE mechanism as defined today, so that we can work on those 
problems to see how they can be addressed. You've raised one - power 
consumption. I'd like to understand what else.

> 
> (Another thing I'm worried is that e.g. in 3GPP and ETSI TISPAN SBCs
> seem to be the *only* standardized mechanism for NAT traversal. 

Yes, I'm worried about this too. For TISPAN especially this seems a 
mistake. ICE, when used with session policy, gives you all of the 
control that an SBC can give, but in a way that has none of its drawbacks.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   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: Cullen Jennings <[email-masked]>
Date: Fri, 28 Oct 2005 22:19:21 -0700

>> complex things like ICE or TURN in the User Agent, and this makes

I like to point out that several of the commercially available SBCs do use
things like STUN and ICE to do media optimization to remove themselves out
of the media path when they are non needed for NAT traversal. This improves
the voice quality, reduces the bandwidth the operator needs. Even when using
SBCs, we still need STUN/ICE.