[Serusers] NAT ping and consumer router

[Richard]

Hi all,

It was a good discussion. Although I didn't find out any consumer
router/firewall working with NAT ping, I had some surprisingly good finding.

Before this whole nat ping and binding refreshing issue, I always think a
better solution is SIP aware NAT, i.e. ALG. I didn't find any good device
because most ALG router/firewalls were used to be high-end and relatively
expensive. Also many ALG implementation, e.g. fixup protocol in cisco PIX
have some serious flaws to be usable.

Fortunately I found one very good implementation of SIP ALG. It is linksys
wireless router WRT54G with the latest firmware. This sub-$100 router
changes the private IP address embedded in the SIP message, e.g. via and SDP
addresses. The sip NAT binding has a 3600 seconds expiration timer. So as
long as the phone register once an hour, it should be fine. The best part of
this solution is that linksys provides source code which is based on linux
2.4 kernel. If there is ever a need to add a feature, we can produce our own
firmware image.

To complete the story, this is not a panacea. It won't solve all problems.
For example, it is still lacking deterministic port mapping. For example, if
the router has a reboot, all the NAT bindings are lost. The new binding will
mess up with existing ones saved in ser. Anyway, in the short term, this is
probably the best we can find out. 

Ironically a division of cisco can produce something much better than its
flagship firewall products.

Thanks,
Richard


-----Original Message-----
From: serusers-bounces at iptel.org [mailto:serusers-bounces at lists.iptel.org] On
Behalf Of Jiri Kuthan
Sent: Monday, August 23, 2004 9:15 AM
To: John Todd
Cc: serusers at lists.iptel.org
Subject: RE: [Serusers] NAT ping and consumer router

At 08:50 PM 8/23/2004, John Todd wrote:
>I agree.  However, I don't see ICE or any of the other extensions becoming
part of most UA implementations for at least another >1.5 years (assuming
that approvals happen quickly at IETF) but those of us with customers have
to come out with solutions faster than that in this quickly-solidifying
market.

agreed.


>> >The manner in which Asterisk handles this type of keepalive is somewhat
simple but novel, and may be worth examination.   Every X seconds, an
OPTIONS request is made to the remote UA by the server. Even if the UA does
not support the OPTIONS query, it typically hands back a SIP error, which
serves the purpose of keeping the NAT translations open.  If the device
supports OPTIONS, then a "normal" SIP reply is sent, also serving the
intended purpose.
>>
>>Its great it mostly works but it is a hack. It introduces lot of
brittlenes -- it will
>>fail whenever NAT bindings change: if NAT reboots, it will fail if NAT is
not too
>>deterministic, it will fail if forcible IP address change occurs, etc.
Getting it
>>robust is simply hard without client support. (Which is BTW a simple
application of the e2e
>>principle.)
>
>I agree that it is a hack, but so is any solution that tries to solve this
problem from the "outside" of the NAT.  Using OPTIONS is perhaps just a
slightly different hack that may make more NAT boxes do the right thing.
>
>(Side note: has anyone generated a list of NAT boxes/software which require
outbound packets for translations to stay open?  In other words: where,
exactly, does SER's method NOT work?)

I'm unfortunately not aware of such.

>>I'm not familiar with what you reference here; are you talking about
cached credentials, or some other method that isn't a full authentication
lookup for REGISTER requests which "appear" to have the same characteristics
as prior registrations?  (danger!  I've imagined what you might be talking
about, and in my (perhaps incorrect) assumptions, I can see some security
problems.  With this method, it would probably be easy to "take over" a SIP
UA's identity for inbound calls without password authentication if the
attacker was behind the same NAT external address.)

Well, the assumption would be that contacts (including port) have not
changed.
If that is the case, skipping authentication introduces rather slight
security
risks.

-jiri 

_______________________________________________
Serusers mailing list
serusers at lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers