Subject: [MMUSIC] RTSP ALGs, STUN, and destination parameter

From: Tom Marshall <[email-masked]>
Date: Wed, 2 Apr 2003 11:03:58 -0800

I'm writing an RTSP ALG for Linux iptables, and came across the problem of
handling the destination parameter.  There are several scenarios:

0. destination parameter not present.  Not a problem.

1. Client is using STUN.

   destination parameter will be the client's internal address.

   It must not be rewritten, or streaming will fail.

2. Client is not using STUN, just being verbose.

   destination parameter will be the client's internal address.

   It must be rewritten to the external NAT address or stripped out, or
   streaming will fail.

3. Client wants the data to be sent somewhere else.

   destination parameter will not be the client's internal address.

   Three cases here:
     3a. Client has dual nics.
     3b. Client wants to send the data to another machine behind the NAT.
     3c. Client wants to send the data to another machine on the internet.

   I don't think one can distinguish 3a and 3b so they can be considered as
   the same problem.  The best way to deal with this case is probably to let
   the administrator decide with a security setting.  Possible values are:

     - Always strip destination parameter.  Not recommended.
     - Strip destination parameter if it does not match client's internal
       address.  This is the default and recommended setting.
     - Never strip the destination parameter.  Not recommended.

This is all pretty straightforward so far.  Now comes the tricky part.  What
to do with the address in the destination parameter as it passes through the
NAT (assuming it's not stripped out)?  I need a way to distinguish between
cases 1 and 2 above to decide.  If I arbitrarily choose to rewrite the
address or not, the other case will be broken.

Does anyone have any suggestions?

-- 
Write a wise saying and your name will live forever.
        -- Anonymous

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 02 Apr 2003 17:12:54 -0500

<rant>I can't help pointing out that this kind of problem is exactly why 
ALGs are problematic. They are attempting to interpret the intention of 
the user so that they can "fix" the message to maintain the desired 
intention of the user in the presence of a nat.</rant>

a more pragmatic comment inline:

>    It must not be rewritten, or streaming will fail.

If the client is using STUN, the destination parameter will not be an 
internal address, it will be an external one. If the NAT knows which 
addresses are internal and which are external, it can differentiate case 
1 from case 2 in this way.

>    It must be rewritten to the external NAT address or stripped out, or

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: Tom Marshall <[email-masked]>
Date: Wed, 2 Apr 2003 14:41:18 -0800

> intention of the user in the presence of a nat.</rant>

Remember, STUN is a very new idea and it works by using some knowledge of
common NAT implementations.  Are going to volunteer to fix all the existing
clients that are out in the field to use STUN and/or Symmetric RTP?  ;-)

Additionally, even if you have the asbolute best STUN (or Symmetric RTP)
client and server imaginable, it is still possible that you won't be able to
punch a hole in a NAT firewall.  Why not?  Because they depend on the NAT
firewall setting up a "connection" when it sees outbound UDP packets.  If
the NAT firewall is sufficiently secure and it requires that UDP packets are
related to an existing TCP connection, it won't work.

> 1 from case 2 in this way.

Good idea.  I'll see if this is possible, thanks.

-- 
One is not superior merely because one sees the world as odious.
        -- Chateaubriand (1768-1848)