Re: [NNagain] FCC - delete, delete, delete

[David Lang <david@lang.hm>]

[-- Attachment #1: Type: text/plain, Size: 5735 bytes --]

In case it's not clear. I am NOT happy with how device manufacturers ship old 
code and never update it.

I just believe that the fix is not to make the devices impossible to update 
(other than scrapping and replacing them), but it's to make it so that the 
devices are easier to update. They are mostly using opensource code, so force 
them to make it so that you can easily install newer versions of code, don't let 
them have proprietary device drivers.

If the CIA and other three letter agencies can't prevent leaks and hacks, it's 
unreasonable to base your security on the idea of a company having better 
security so they never have any bugs, hacks, or leaks.

Even govenments fail to eliminate all problems (see submarines and spacecraft) 
with near unlimited budgets

companies that try to make software perfect before release go out of business 
before release.

companies that try to prove that an upgrade cannot cause any problem before it's 
deployed have lots of vulnerabilities because they take so long to upgrade (and 
eventually get bit by some bug that makes it through their testing)

I am firmly on the side of release early, release often. be it product releases 
or patching. When (not IF) an update has problems, it's a lot easier to roll 
back a small amount, and far easier to to figure out what went wrong when there 
are fewer changes.

David Lang


On Fri, 14 Mar 2025, Dick Roy wrote:

> Date: Fri, 14 Mar 2025 14:20:00 -0700
> From: Dick Roy <dickroy@alum.mit.edu>
> To: 'David Lang' <david@lang.hm>,
>     'Richard Roy via Nnagain' <nnagain@lists.bufferbloat.net>
> Cc: 'Tara Stella' <tara@tara.sh>
> Subject: RE: [NNagain] FCC - delete, delete, delete
> 
> Yup ... and the must be SECURE updates by the way!  Security is required throughout the supply chain!
>
> RR
>
> -----Original Message-----
> From: David Lang <david@lang.hm>
> Sent: Friday, March 14, 2025 2:09 PM
> To: Richard Roy via Nnagain <nnagain@lists.bufferbloat.net>
> Cc: Tara Stella <tara@tara.sh>; Richard Roy <dickroy@alum.mit.edu>
> Subject: Re: [NNagain] FCC - delete, delete, delete
>
> it's also impossible to fix bugs when you prevent updates.
>
> show me any product deployed at large scale that has not had bugs.
>
> David Lang
>
> On Fri, 14 Mar 2025, Richard Roy via Nnagain wrote:
>
>> Date: Fri, 14 Mar 2025 19:05:18 +0000
>> From: Richard Roy via Nnagain <nnagain@lists.bufferbloat.net>
>> To: Network Neutrality is back! Let´s make the technical aspects heard this
>>     time! <nnagain@lists.bufferbloat.net>, Tara Stella <tara@tara.sh>
>> Cc: Richard Roy <dickroy@alum.mit.edu>
>> Subject: Re: [NNagain] FCC - delete, delete, delete
>>
>> Bob,
>>
>>
>>
>> You are certainly correct.  Complexity of implementation always leads to the potential for more attack surfaces.  As importantly, security as an add-on is really no security at all.  If security is not designed in at the outset, optimal security can rarely if ever be achieved.  First and foremost at the core of security is "credential material" that MUST be protected IN TAMPER-PROOF/EVIDENT HARDWARE (e.g. FIPS 140-x).  It is nearly impossible to secure a system without this capability, and not all of the systems out there today are so "equipped" making system-wide trust nearly impossible. ☹☹☹
>>
>>
>>
>> Cheers,
>>
>> RR
>>
>>
>>
>> -----Original Message-----
>> From: Nnagain <nnagain-bounces@lists.bufferbloat.net> On Behalf Of Robert McMahon via Nnagain
>> Sent: Friday, March 14, 2025 11:53 AM
>> To: Tara Stella <tara@tara.sh>
>> Cc: Robert McMahon <rjmcmahon@rjmcmahon.com>; Network Neutrality is back! Let´s make the technical aspects heard this time! <nnagain@lists.bufferbloat.net>
>> Subject: Re: [NNagain] FCC - delete, delete, delete
>>
>>
>>
>>> I'm not an expert, but I wonder if the complexity has increased the potential attacking surface.
>>
>>
>>
>> I'm not an expert here either - but I do think complexity does increase the attack service. Breaking up the control and data planes seems like a good idea to me.
>>
>>
>>
>> Also, devices like CPUs that run programmable logic are a target because their logic flows can be hijacked. Hardware solutions for simple functions like forwarding packets cannot be reprogrammed at the data plane level, minimizing their attack service.
>>
>>
>>
>> Moving the control plane(s) into a management domain where security experts do their work everyday seems a must to me. Pushing this into consumer premises and adding more and more seems like a disaster in the making.
>>
>>
>>
>> https://www.splunk.com/en_us/blog/learn/control-plane-vs-data-plane.html
>>
>>
>>
>> Bob
>>
>>
>>
>> On Fri, Mar 14, 2025 at 1:16 AM Tara Stella <tara@tara.sh<mailto:tara@tara.sh>> wrote:
>>
>>>
>>
>>> On Thu, 2025-03-13 at 22:24 -0400, David Bray, PhD via Nnagain wrote:
>>
>>>
>>
>>> Indeed. Yet here on ground SS7 remains vulnerable and exploitable too?
>>
>>>
>>
>>>
>>
>>> I'm working for a big telco in Europe, and I'm just marginally involved in the telco network.
>>
>>> AFAIK, in our infrastructure, SS7 is a niche in some very old equipment sitting somewhere.
>>
>>> On fixed broadband, we migrated everything over IP, voice is SIP, including VAS services, that are somehow fading away as well (IMS still in place for voicemail).
>>
>>> On 5G Standalone, everything is HTTP on the control plane and GTP encapsulation on the user plane.
>>
>>>
>>
>>> I'm not an expert, but I wonder if the complexity has increased the potential attacking surface.
>>
>>> Cheers,
>>
>>> Tara
>>
>>>
>>
>> _______________________________________________
>>
>> Nnagain mailing list
>>
>> Nnagain@lists.bufferbloat.net<mailto:Nnagain@lists.bufferbloat.net>
>>
>> https://lists.bufferbloat.net/listinfo/nnagain
>>
>
>