From: "Florian Fuessl" <flo@degnet.de>
To: "'Patrick McHardy'" <kaber@trash.net>,
"'Greg Alexander'" <greqcs@galexander.org>
Cc: <netfilter-devel@vger.kernel.org>
Subject: RE: Group consensus sought on nf_conntrack_sip behavior
Date: Wed, 20 Jan 2010 00:40:40 +0100 [thread overview]
Message-ID: <002c01ca9960$cf812d20$6e838760$@de> (raw)
In-Reply-To: <4B55FC78.80001@trash.net>
Hi Patrick, Hi Greg,
as you know, the aspects of NAT have definitely not been considered on the
development of SIP (RFC 3261); so this topic has unfortunately much room for
discussions how to handle problematical issues in detail.
In fact, using SIP together with NAT is still a tricky pain requiring
uncomely workarounds (STUN, keepalive, ...) from the user side.
Nf_conntrack_sip has helped to reduce the issues of SIP with NAT a lot from
the user side; but beyond doubt there are still open traps and unsolved Bugs
requiring some review on the code in some cases. :-/
Patrick McHardy wrote:
> Greg Alexander wrote:
> > Is there anyone else on this mailing list who cares to chime in?
> >
I guess almost everyone on this list does not suffer from this problem
regarding no need for this code on the own "home" installation.
> > I believe it is more important to conform to standards and common
> > practice, especially since they are the same in this case and
> > present no undue burden or risk.
> >
Nf_conntrack_sip should conform to the standards as far as possible; but on
the other side - as it's enabled by default on many distros - it's required
not to open potential security holes on a default installation.
> > Patrick McHardy seems to believe it is more important to enforce a
> > rule of thumb prohibiting wildcard expectations.
> >
> > We each have precedent in other NAT helpers to support our position.
>
> Well, I'll add one final point. You mentioned the IRC helper
> as precedent, without referring to anything concrete. You're
> mistaken though, the destination address is fixed. But I see
> where your misunderstanding might come from.
>
> What the SIP helper does is allow expectations between *arbitrary*
> hosts when the direct_media option is off - the destination address
> originates from the SDP payload, the source address is a wildcard.
>
IMHO the available options should be documented with examples requiring a
change of the default parameters.
Unfortunately using the default settings results in for most users hardly to
debug problems in some cases.
> > Any other opinions? Linux is a group effort.
> >
> > [...]
>
> Have fun.
sure: Yes, we have ;)
-Florian
prev parent reply other threads:[~2010-01-19 23:47 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-16 10:36 Two patches for nf_conntrack_sip Greg Alexander
2010-01-18 7:49 ` Patrick McHardy
2010-01-18 17:49 ` Greg Alexander
2010-01-18 18:13 ` Patrick McHardy
2010-01-18 19:36 ` Greg Alexander
2010-01-19 8:25 ` Patrick McHardy
2010-01-19 17:23 ` (PATCH) " Greg Alexander
2010-01-19 18:09 ` Patrick McHardy
2010-01-19 18:25 ` Group consensus sought on nf_conntrack_sip behavior Greg Alexander
2010-01-19 18:39 ` Patrick McHardy
2010-01-19 19:36 ` Greg Alexander
2010-01-19 22:01 ` Patrick McHardy
2010-01-20 0:02 ` Greg Alexander
2010-01-19 23:40 ` Florian Fuessl [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='002c01ca9960$cf812d20$6e838760$@de' \
--to=flo@degnet.de \
--cc=greqcs@galexander.org \
--cc=kaber@trash.net \
--cc=netfilter-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).