[v6ops] Re: Traffic control protocols (PCP and UPnP IGD)

[Daryll Swer <[e-mail]>]

> The mistake is thinking that PCP is creating a new problem. That’s not
so. You are already vulnerable to attacks via network programming errors.
They just happen in the other direction: zero click attacks, mal-adware,
etc.

+1

I also fail to understand, how is it, the IETF's job to create highly
customised, pre-defined, detailed firewall templates for PCP/UPnP, with the
assumption the hosts can't be trusted. Nope. That's not the IETF's
job, IMO, that's the average Joe's job — Either hire an expert, learn it
yourself, trust your ISP (yeah, right); If none of these options are
available, it's not the IETF's problem.

I'm all in for PCP signalling to open a port in the stateful firewall as I
originally described, and PCP shouldn't encourage locking of the ecosystem
to just TCP/UDP, it should support all standardised layer 4 protocols
(DCCP, UDP-Lite, SCTP, maybe more).

> You seem to be  arguing that it’s better for there to be no way at all
for me to have a listener on my network than for the firewall provided by
my ISP that I can’t control to completely prevent me from having a listener.

That's my interpretation as well, and if true, I disagree with Gert.

Side note:
That being said, in the absence of PCP, a stateful firewall will be fine
for native P2P that's solicited over STUN. NO TURN, but with only STUN. I
currently do use a stateful firewall in my family home because I don't
control all the endpoints and ran extensive testing (with PCAPs) for P2P
applications, they do work over the firewall thanks to STUN (and firewall
rules that don't broke solicited P2P), however, unsolicited ingress is just
obviously not going to work without PCP.

*--*
Best Regards
Daryll Swer
Website: daryllswer.com
<https://mailtrack.io/l/94949aa4543970e421ce513199eac48657d9b846?url=https%3A%2F%2Fwww.daryllswer.com&u=2153471&signature=1b67aab56bd86676>


On Sun, 28 Jul 2024 at 18:40, Ted Lemon <[e-mail]> wrote:

> I hear you, Gert. I’m not saying that you are wrong to be concerned with
> that. What I’m saying is that this isn’t a protocol problem. Further, at
> present nobody is doing what you are afraid they will do, and I think the
> authors of openssh would be quite offended at your characterization of how
> they think although given that “PasswordAuthentication yes” is still
> standard in sshd_config, perhaps your cynicism isn’t misplaced.
>
> But the mistake I’m trying to point out is a bit different.
>
> The mistake is thinking that PCP is creating a new problem. That’s not so.
> You are already vulnerable to attacks via network programming errors. They
> just happen in the other direction: zero click attacks, mal-adware, etc.
>
> Meanwhile, the loss of functionality caused by firewalls is obvious: there
> are a whole class of things people should be able to do with their internet
> connection that they can’t because of firewalls.
>
> The way we typically deal with this issues is with value added software:
> eg your eero router comes with an app that you can use to control this
> stuff. PCP just makes the app easier to use: rather than having to know how
> to open up a hole in your firewall for an app, the app just asks for what
> it needs and you say yes or no.
>
> On an iOS device we might handle this with an entitlement, and make the
> author that you think is such an idiot actually justify why they want a
> listener.
>
> You seem to be  arguing that it’s better for there to be no way at all for
> me to have a listener on my network than for the firewall provided by my
> ISP that I can’t control to completely prevent me from having a listener.
>
> Is that actually what you mean?
>
> Op zo 28 jul 2024 om 03:03 schreef Gert Doering <[e-mail]>
>
>> Hi,
>>
>> On Sat, Jul 27, 2024 at 04:56:44PM -0700, Ted Lemon wrote:
>> > Gert, this is /precisely/ what PCP is for: to tell the firewall which
>> ports
>> > to allow through. My speaker doesn???t tell PCP to allow anyone on the
>> > outside to play music to my speakers because that wouldn???t make
>> sense. My
>> > ssh server isn???t very useful if I can???t get to it from the outside.
>> But
>> > only that one ssh server???there are other ssh servers on my network
>> that
>> > would not make sense to expose.
>> >
>> > This is what PCP enables: fine-grained control over ingress.
>>
>> I totally understand the *idea* behind it.
>>
>> Implementors of, say, "speakers" might not get that their device is not
>> supposed to be accessible by, say, their nice cloud service and still do
>> add PCP to their speakers.  Because someone thinks it's a good idea.
>>
>> Which is exactly my point that you try to not see - PCP, as a protocol,
>> used for exactly those services that are a) intended to be reachable, and
>> b) securely so, is a nice tool.  PCP as a default action for "everything
>> that opens a listening socket" contradicts having a firewall by default.
>>
>> I expect implementors to do "PCP as a default action for everything",
>> because that's much easier than adding a config knob to let the informed
>> user do the right thing.
>>
>> Also, of course, all software developers that add a listen socket will
>> assume that their software is the most important you run, will need to
>> be talked to, AND is totally secure.
>>
>> Real life vs. protocol design.
>>
>> Gert Doering
>>         -- NetMaster
>> --
>> have you enabled IPv6 on something today...?
>>
>> SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Ingo
>> Lalla,
>>                                            Karin Schuler, Sebastian Cler
>> Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
>> D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
>> Tel: [phone]         USt-IdNr.: DE813185279
>>
>