From: Patrick McHardy <kaber@trash.net>
To: Greg Alexander <greqcs@galexander.org>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: (PATCH) Re: Two patches for nf_conntrack_sip
Date: Tue, 19 Jan 2010 19:09:18 +0100 [thread overview]
Message-ID: <4B55F54E.4020205@trash.net> (raw)
In-Reply-To: <20100119172306.GF11547@goonies.be>
Greg Alexander wrote:
>> Its not about what applications or phones do at all. Its about what
>> you can do by sending fake INVITE or other requests containing foreign
>> addresses. I'm not going to change the default, sorry.
>
> Okay, this is becoming increasingly frustrating for me. I keep on
> pointing out to you that SIP is a standard by which people register their
> intent to exchange media streams directly between unrelated peers. You
> then wave your hands and say "fake" or "poke a hole" and ignore what I've
> said. Nothing in nf_nat_sip permits arbitrary holes to be poked! Until
> the host initiates a SIP conversation, nf_nat_sip does not facilitate ANY
> packets moving through the firewall. Until the host sends an SDP packet,
> nf_nat_sip only facilitates SIP packets. Once the media stream begins,
> nf_nat_sip will not facilitate any new holes without a new SDP packet.
>
> An SDP packet is a conspicuous standard-conforming notification that
> incoming traffic is expected on a specific local port, and the remote
> host is left unspecified. You are saying we should ignore this
> standard-conforming notification merely because we do not approve of
> wildcard remote hosts. This is insufficient. We only disapprove of
> wildcard remote hosts because there is the potential to poke arbitrary
> holes through the firewall. There is the potential for monsters under my
> bed, so I shine my flashlight and I know there are no monsters. I
> inspect nf_conntrack_sip and I know there is no arbitrary hole poking!
You obviously haven't inspected it very well. I have no interest in
continuing this debatte.
> Patch follows.
>
> --- nf_conntrack_sip.c 2010/01/15 21:51:08 1.1
> +++ nf_conntrack_sip.c 2010/01/16 09:29:07 1.3
> @@ -375,7 +375,7 @@
> dptr += hdr->len;
> else if (hdr->cname && limit - dptr >= hdr->clen + 1 &&
> strnicmp(dptr, hdr->cname, hdr->clen) == 0 &&
> - !isalpha(*(dptr + hdr->clen + 1)))
> + !isalpha(*(dptr + hdr->clen)))
> dptr += hdr->clen;
> else
> continue;
Applied, thanks.
next prev parent reply other threads:[~2010-01-19 18:09 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 [this message]
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
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=4B55F54E.4020205@trash.net \
--to=kaber@trash.net \
--cc=greqcs@galexander.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.