[Asterisk-Dev] A proposal regarding NATing firewalls

[Martin Kihlgren]

I currently work at a small business trying to sell ip-telephony to both
business- and home-users.

We have given much thought to the firewall problems when using ip-phones -
and it allways comes back to using some kind of rtp-redirector/proxy.

What I mean is that not only pstn<->ip calls lets their rtp-streams go
through the asterisk (or whatever ipbx one uses), but also ip<->ip calls let
their rtp-streams go to a redirecting server that just sends it off to the
other phone.

This certainly solves the problem, but it is an unnecessary bandwidth-sink.
Especially since we want to let our customers make _all_ ip<->ip calls for
free.

Now we have discussed and experimented around and come up with a few
features that would solve many of these problems, though probably not all.

However, since I am a very newbie asterisk-hacker, I thought I could present
my ideas here, hoping that the more experienced people can either:
- best case :) - say that these features allready are in the asterisk or:
- review the ideas I present for doability and then either:
 - next best case :) - tell me that they find them interesting and are
   willing to help me implement them properly or:
 - worst, but still pretty good case - give me some pointers on how to
   implement it myself
   
So, enough rambling, here are the features I am talking about:

1) Detection of NATing firewall changing rtp-port

 Today, when several devices sit behind the same firewall, you have to
 specify to the devices unique rtp-ports to use, or they will try to use the
 same source-ports and the firewall will force the outgoing rtp to other
 source-ports. 
 
 If the ipbx detected that the expected rtp-stream coming from a device
 originates from another port than the one specified in INVITES or similar
 signaling calls, it should change the destination-port of its own
 rtp-stream to the source of the actual stream.
 
 This might be complicated if it sets up the same listening-port for several
 devices behind the same firewall, since it then would be unable to
 distinguish from which device the packets with unexpected source-ports
 came, but if it sets up different listening-ports for each device it wants
 to have rtp-communication with it would still be possible to identify the
 device that sends from the "wrong" source-port.

2) Expanding the "nat" option to a "network" option.

 If every added device had the non-required option "network" instead of
 "nat", and that option defaulted to "internet" or something suchlike, this
 option could be used in a very interesting way.

 Then when a device wanted to make a call, the ipbx could detect if the call
 was made to another device on the same network, and let the devices send
 their rtp-streams to their advertised adresses (the "real" ones on their
 lan).
 
 If the call was made to a device _not_ on the same "network", the server
 would act as if both devices had the old "nat" option enabled, and use the
 "real" signaling- and rtp-ports of the packets transmitted from the device
 in all communication, including the implementation of proposal 1)

3) Adding a "nice firewall" option.

 If every registered device had the boolean option "nice firewall", meaning
 that it is behind a firewall having a few defined and pretty common
 characteristics, the need for the "rtp-redirector" would be removed in
 these cases.

 A "nice firewall" is one where:
 3.1) A source-adress/port on the inside of the firewall will get the same
      source-adress/port externally on the firewall if the transmitted
      packets are sent within a reasonable time (more than several seconds),
      even if the packets are sent to different destination-adresses/ports.
      The linux-kernel's NATing works this way today.
 3.2) A source-adress/port sending datagrams from inside the firewall to a
      destination-adress/port outside the firewall will result in a specific
      hole in the firewall letting in packets from the destination-adress/port
      to the source-adress/port if the returning packets are within a
      reasonable time (more than several seconds).
      The linux kernel's NATing works this way today if you allow datagrams
      that are ESTABLISHED on the FORWARD chain from internet-if->lan-if
 3.3) A received datagram that is not allowed on any chain will be DROPed,
      and not replied to with "adress unreachable" or "access denied" or any
      other negative icmp or datagram.

 If both devices are a) on different "network"s as to proposal 2), _and_ b)
 both have "nice firewall", the ipbx could act as follows:
  *Invite both devices to its rtp-redirector, and initiate the communication
   this way.
  *As soon as it has gotten packets from both devices to its rtp-redirector,
   it will - if both clients support re-invite or similar signaling -
   re-invite the devices to *each others external adresses/ports*, ie to the
   ports given them as external ports by their firewalls.
  *The first of the firewalls to recieve rtp-packets in these newly
   re-invited streams will just DROP them, but as soon as the device behind
   this firewall has sent a datagram to the source-adress/port of the DROPed
   datagram, these packets will be seen as ESTABLISHED, and get forwarded to
   the device behind the firewall.
  *A firewall that gets these datagrams _after_ it has allready transmitted
   datagrams to the source-adress/port of the incoming packets will
   naturally just forward them without fuss.

 This would remove much of the unnecessary bandwidth (and costs to several
 actors) used when two ip-devices communicate.
 
 Possibly the existance of a "nice firewall" could even be automatically
 detected by the ipbx when a device registers, using a few fake invites and
 re-invites, but that should probably be seen as bells and whistles.

Please consider these ideas, and tell me if I am completely confused - or if
I am actually on to something :D

regards,
//Martin Kihlgren

-- 
###################################################################
"There was a time when religion ruled the
 world. It was known as The Dark Ages."
       [Ruth Hurmence Green]
###################################################################
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20040101/2a3c3672/attachment.pgp