Subject: [AVT] RTP port sharing - new proposal

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Sat, 11 Aug 2001 01:01:13 -0700

Port-Sharing and media-sender identification. [Port sharing across sessions
not RTP & RTCP].

The port-sharing ability is _crucial_ for near-term VoIP provisioning across
firewalls. The need for a solution is still there - I encourage detractors
to propose alternate mechanisms to solve this problem.

I proposed a port-sharing/media-correlation scheme recently involving SSRC
space sharing between sessions and corresponding reverse source
identification. This met with some amount of resistance in that it reduces
the collision avoidance of SSRC (although this is only a problem in some
application models) .

The basic approach for using a shared RTP port is to have the ability to
correlate any RTP sender with its corresponding session. [which is a subset
of  the broader problem/ability to identify uniquely the source of any
media-sender.]

One type of solution spaces involve using the existing transport and RTP
information to provide this correlation:
· Transport: Use knowledge of the source transport address to identify the
source. This has bad interactions with NAT's and in my opinion is not a good
approach - although unfortunately it is the one that seems to be creeping
into a lot of areas.
· RTP: My previous proposal was a scheme to share the SSRC space across
multiple sessions - which was rejected. Any alternatives? I get the feeling
that doing anything with the SSRC is going to be deemed as "being a good
intention paving the road to hell" and not get WG approval. 
· RTCP: Use the correlation of the RTCP CNAME (with session) to identify the
SSRC of media source. This requires a change in the way that RTCP packets
are sent initially - which I'm sure will be an even less popular proposal
(and has other transport related problems). Ugly anyway.

So I can't see any solutions in above-mentioned space that are likely to get
IETF endorsement (assuming IETF will recognize the need for port-sharing
fundamentally and hence approve anything).

An alternate approach: add session or source identification to the RTP media
flow.

This has already been implemented: Secure RTP! 

Unfortunately the cryptographic costs of this solution many be infeasible
for all implementations or applications.

However I believe the SRTP framework can be leveraged to provide a simple
solution: use an SRTP media flow where the NULL encryption cipher is
negotiated and no authentication tag is added - only use the SPI tag.

This SPI tag can provide what we need - a way of correlating the media
sender with a session - hence allowing ports to be shared. The SRTP key
management should already handle (or needs to) the negotiation of the SPI
value (and NULL ciphers).

The solution obviously has bandwidth implications but I guess that's the
tradeoff when you cannot place restrictions on the existing 32-bit source
identifier (SSRC) so that it can be used between sessions. I have discussed
a proposal with the authors of SRTP for reducing this cost in the common
case.

Robert.

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www1.ietf.org/mailman/listinfo/avt