On 03/13/2018 04:27 PM, Robert White wrote:
On 03/12/2018 11:32 PM, zrm wrote:
I still don't see why you should use different ports for SIP traffic
initiated with a PCP PEER request than the same SIP traffic initiated in
the traditional way.
It finally occurs to me that you literally don't know enough about the
various networking protocols for my examples to make sense to you...
SIP is a _notoriously_ problematic and questionably "secure" protocol
who's misuse is simple and whos real dollar cost can be substantial. If
you are running a telephone switch that supports SIP - like asterisk -
as opposed to a simple endpoint like a single phone - someone can bounc
their long distance calls through your switch and cost you serious
dollar amounts.
But SIP isn't a "voice over IP protocol", it's a protocol that
negotiates VOIP data sessions.
A typical single phone call might involve several SIP data sessions.
In the real world I would have one or two "providers", such as Vonage or
whatever.
My firewall will _only_ want to accept _initial_ incomming SIP sessions
from my provider. So I am going to put a single hole in my firewall
rules for a very restricted set of ports and only those that come from
my particular assigned gateway at e.g. Vonage. I don't even want to
accept packets from the rest of the Vonage ecosystem.
But in practice all the people who want to call me don't _just_ use
Vonage, and if they do use Vonage, they might not use the same Vonage
gateway.
So lets say I'm in Seattle and my caller is in the UK. He's going to
talk to his UK provider, and that UK provider is going to tell him to
talk to Vonage. Then Vonage is going to connect to me and say "hey,
expect a connection from this particular guy on this particular port,
that cool?"
At this point my Asterisk switch is going to want to make a PEER request
that opens a port that MY FIREWALL WOULD NORMALLY REJECT so that the UK
guy and I can negotiate a data session.
I think I see where we're talking past each other.
SIP predates PCP by quite a while. In the days before PCP this would be
done with the traditional STUN methods, UDP hole punching or TCP
simultaneous open, that sort of thing.
Since connections from arbitrary peers are not allowed, the client would
send an _outgoing_ packet to the remote peer, which is allowed. Then
when the remote peer makes its connection using the same addresses and
ports, its packet causes the conntrack state to become ESTABLISHED (i.e.
traffic seen in both directions), and there is a rule accepting
ESTABLISHED connections, so then the connection is allowed.
With PCP PEER it's typically _the same thing_, only the client gets a
PEER response with some helpful information like the assigned external
IP and port. When the PEER request is approved it sets up the conntrack
entry so that when the remote peer sends its packet, the ctstate becomes
ESTABLISHED and matches the rule accepting ESTABLISHED connections.
Which is why the rules for PEER and outgoing connections are usually the
same -- they do the same thing.
If I say "not cool bro", then Vonage will ask UK Guy if we can make the
connection in the other direction. And if _he_ also says "not cool bro"
then Vonage will pass the negotiations back-and-forth with a heavy sigh.
And everything is cool for the negotiations part of the actual SIP session.
BUUUTTTT....
SIP only arranges for an actual VOIP data pathway to be opened. At some
point we want to open a link that will pass actual talking. This is not
SIP traffic. This is going to be H323 or some other data stream encoded
link.
That is, it's a (typically) UDP stream that should pass straight from UK
guy to my Asterisk box. Or maybe even from UK Guy to my desktop VOIP
device after my Asterisk switch determines that the extension UK Guy
wants is indeed on my desk.
At this point the SIP controller (e.g. my Asterisk switch) is going to
want to use a PEER request to establish a mapping that is ALSO NORMALLY
DISALLOWED BY MY FIREWALL so that UK Guy's H323 device can talk to my
H323 device directly.
This is the real example I was looking for. PCP has a THIRD_PARTY option
that allows a client to make a request on behalf of another host, which
I wasn't thinking about.
In my implementation (and I suspect I'm not alone) any PEER request with
the THIRD_PARTY option currently gets refused with UNSUPP_OPTION because
it's kind of a big security hole with no simple way to secure it. And
it's only useful if the actual endpoint can't just make the PEER request
for itself.
If I was to actually implement that, it would then make sense to use
different rules for THIRD_PARTY PEER requests than the ones from the
host itself, because in that case they're actually different hosts with
different authorization levels and there is nothing equivalent to that
in the firewall itself.
If that's a "not cool bro" as well, then we need a third party device to
be involved that just takes the stream from both of us, or the call just
doesn't actually pass any sound. That third party service reduces
service quality and/or costs "minutes" or other money or credits.
In fact, if I get a lot of calls from UK Guy, such as if that's a branch
of my growing business, then any query against the current firewall
state would indicate that reuse of that link might be very-very-very bad
since someone is already talking on that quartet of
source,sport,dest,dport data. That is, if this is the second call
between the same two IP addresses we definitely don't want to reuse the
same ports.
This is already dealt with. NFCT_Q_CREATE fails when a conflicting
conntrack entry exists, at which point it tries a different external
IP/port, or refuses the request if those specific ones were requested.
But if it's a call between different IP addresses we may well want to
use the same ports (much like 53 is reused in DNS traffic all the time
by both ends).
And sure, once you've arranged everything you'd then use packet marking
(etc) to dodge the normal reject rules. But you don't want to do that
until after the connection is negotiated and ready since you don't want
to open packets based on firewall state, you want to open them based on
the PCP and the Asterisk state instead.
Sure, the PCP daemon wouldn't create a conntrack entry with that
connmark until it gets a PEER request from a host specifically
authorized to override the normal firewall rules in the relevant way.
So one of the _vital_ purposes of PCP is to TEMPORARILY ENLARGE FIREWALL
PERMEABILITY in response to validated requests from known good sources.
By definition, if PCP is only going to allow what the firewall already
allows, then PCP is a useless intermediary step.
I think this is the part you're misunderstanding. You're envisioning
PEER as something _only_ a specifically-authorized host (e.g. SIP
controller) can use to do things that aren't otherwise allowed.
But there actually are reasons for arbitrary regular hosts to use it for
things they're allowed to do without it.
The PEER response contains the assigned external IP and port. That
information is needed for anything that has to traverse double NAT and
PEER provides it directly instead of needing a collection of ugly hacks
to try to guess them.
PEER can be used to renew the NAT mapping state, so the client doesn't
have to send a keep-alive across the internet just to maintain state in
their local gateway, and has the mapping lifetime in the response so the
client knows when to renew it instead of having to send a keep-alive
every 20 seconds when the client doesn't know that it won't expire for
20 hours.
Anything that makes long-lived connections and wants them to survive a
gateway reset can use PEER to do that.
And all of that stuff should follow the normal firewall rules by
default, even if there may also be special additional rules for
THIRD_PARTY PCP requests from the SIP controller.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
