Warren,
On 26-May-23 21:03, Warren Kumari wrote:
On Thu, May 25, 2023 at 11:13 PM, Brian E Carpenter <[email protected]
<mailto:[email protected]>> wrote:
On 26-May-23 08:33, Manfredi (US), Albert E wrote:
-----Original Message-----
From: Tom Herbert <[email protected] <mailto:[email protected]>>
It's more than a preference to have host security, it is an
absolute requirement that each host provides security for its applications and
users. This requirement applies to SmartTVs, SmartPhones, home computers, and
pretty much all the several billion end user devices connected to the Internet.
No host device would ever assume that the network consistently provides any
adequate level of security, for real security we need to assume that the host
is the first and last line of defense (i.e. zero trust model).
I could not agree more, Tom. So, as Fernando and others have said, the
impulse is to block everything coming in from the Internet that you figure you
don't need **right now**. Such as weird complicated header extensions.
It's perfectly fine if a host chooses to block incoming packets for any
reason whatever, including unknown extension headers. That's quite consistent
with the *network* allowing permissionless innovation.
The problem arises when any upstream intermediate node drops a packet
because it doesn't like it for some reason. There, you immediately create the
tussle between transparency and security, and I strongly suspect that there is
no universal way of avoiding that tussle. Not every new feature has backing
from Google.
The ISP has its own concerns, to protect its network, but I, in my
enterprise or household, have different concerns. I'm not going to trust the
ISP's security mechanisms to provide my own security needs.
Honestly don’t see how IPv6 is going to change that. Over time, perhaps, some
specific extensions used out in the wild will be seen as crucially important to my
enterprise or household, and maybe those will not be blocked. But "trust me, you
must accept all these EHs"? More likely, those potential innovations will go unused
and maybe will eventually be implemented in a different way.
A well-implemented host will not be troubled by unkown extension headers or
options.
Indeed. However, not all hosts are well-implemented.
If my "smart" TV isn't capable of ignoring unkown extension headers, its
vendor will have to give me my money back.
Erm, have you ever tried this? I certainly haven't, but I'd assume that trying to contact
[Vizio|Sony|LG|Sharp|Kenmore] and explain that e.g a packet with the "IOAM
Destination Option and IOAM Hop-by-Hop Option" makes the TV turn off will not be
particularly fruitful (or fun).
No. I'd go to the retail outlet and say "That TV you sold me keeps crashing." And then
I'd invoke a wonderful law we have here called "The Consumer Guarantees Act." I'd have a
reasonable chance.
But more seriously, our job here is surely to specify host behaviour correctly.
There's not a lot more we can do to improve the situation.
As I've said already, there's a tussle here that we (the IETF) probably can't
abolish.
Brian
I don't want my ISP or my CE router to block any extension headers.
Your ISP and CPE vendor are incentivized to reduce costs (people calling customer service
to complain that their FoozleWhatzit TV keeps rebooting) and drama (press articles that
bad people are turning on cameras on BarzleWerg baby monitors and posting
"interesting" videos online).
It's hard to write a breathless press article that Comcast doesn't allow Shim6
EH, and the number of people calling to complain that HIP EH doesn't pass
through their CPE is likely to be very small.
Until this changes, ISPs and CPEs are likely to continue blocking. Yup, from an
architectural and purity standpoint this is not a good thing - but, sadly,
principles don't pay the bills.
Explaining to your enterprise security admin that allowing the mobility header
it is the right thing do is hard, especially when she's pointing at the badge
reader that keeps rebooting because it's IPv6 stack is awful. She has a clear
and tangible story - random packets make this thingie reboot, why would you
trust it to handle some potential new EH in a secure manner?! Your story is
much harder and hand-wavy — some new EH might possibly be defined at some point
in the future that might possibly allow some future feature that somehow
improves things...
Security evolved as it did, over IPv4, for a reason, methinks.
There is really no difference between the story of IPv4 options and IPv6
extension headers, except that extensibility was a sales argument for IPv6, so
naturally people have tried to use them. And it would be exactly the same for IPvN
where N>6.
Yup - just like with e.g IPv4 source route options, the incentives need to be
correct — the risk of allowing IPv4 source routed packets into the network
exceeded to benefit to the network, and so they got blocked.
This is why we cannot have nice things - the incentive model prefers security,
stability and cost over future extensibility and principles.
W
Brian
_______________________________________________
v6ops mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/v6ops
<https://www.ietf.org/mailman/listinfo/v6ops>
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
