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. 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. 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. 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. 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. Does it make sense now? -- 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
