On 26-May-23 21:13, Ole Troan wrote:
A well-implemented host will not be troubled by unkown extension headers or
options.
Indeed. However, not all hosts are well-implemented.
"Not be troubled by” == “drop”?
Yes, discard as RFC 8200 says.
I don’t agree that a well-implemented host and
Warren,
On 26-May-23 21:03, Warren Kumari wrote:
On Thu, May 25, 2023 at 11:13 PM, Brian E Carpenter mailto:brian.e.carpen...@gmail.com>> wrote:
On 26-May-23 08:33, Manfredi (US), Albert E wrote:
-Original Message-
From: Tom Herbert mailto:t...@herbertland.com>>
If only there were some *principle* to guide operators in better
understanding when it might be worth spending their time blocking something
that is not a *specific credible threat*
Oh wait... https://en.m.wikipedia.org/wiki/Robustness_principle
Now, where there is a specific, credible threat
On Fri, May 26, 2023 at 2:13 AM Ole Troan wrote:
>
> > A well-implemented host will not be troubled by unkown extension headers or
> > options.
> >
> > Indeed. However, not all hosts are well-implemented.
>
> "Not be troubled by” == “drop”?
> I don’t agree that a well-implemented host and
Hi, Warren,
On 26/5/23 11:03, Warren Kumari wrote:
On Thu, May 25, 2023 at 11:13 PM, Brian E Carpenter
mailto:brian.e.carpen...@gmail.com>> wrote:
[]
A well-implemented host will not be troubled by unkown extension
headers or options.
Indeed. However, not all hosts are
This is a really good thread!
For me, it highlights that there appears to be a gulf in understanding, or at
least working assumptions, between developers and those responsible for network
(public or private) security. I suspect that gulf might narrow somewhat if
developers faced some of the
On Fri, May 26, 2023 at 11:13 AM, Ole Troan wrote:
> A well-implemented host will not be troubled by unkown extension headers
> or options.
>
> Indeed. However, not all hosts are well-implemented.
>
> "Not be troubled by” == “drop”?
>
I had assumed "not troubled by" meant "doesn't explode,
> A well-implemented host will not be troubled by unkown extension headers or
> options.
>
> Indeed. However, not all hosts are well-implemented.
"Not be troubled by” == “drop”?
I don’t agree that a well-implemented host and application should blindly
accept any and all extension headers.
If
On Thu, May 25, 2023 at 11:13 PM, Brian E Carpenter <
brian.e.carpen...@gmail.com> wrote:
> On 26-May-23 08:33, Manfredi (US), Albert E wrote:
>
> -Original Message-
> From: Tom Herbert
>
> It's more than a preference to have host security, it is an absolute
> requirement that each host
sday, May 25, 2023 5:44 PM
To: Brian E Carpenter
Cc: IPv6 Operations ; 6man ; opsec@ietf.org
Subject: Re: [OPSEC] [v6ops] [EXTERNAL] Re: [IPv6] Why folks are blocking IPv6
extension headers? (Episode 1000 and counting) (Linux DoS)
-Original Message-
From: Brian E Carpenter
> It's p
-Original Message-
From: Brian E Carpenter
> 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.
Right, but, as others
On 26-May-23 08:33, Manfredi (US), Albert E wrote:
-Original Message-
From: Tom Herbert
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,
On Thu, May 25, 2023 at 1:34 PM Manfredi (US), Albert E
wrote:
>
> -Original Message-
> From: Tom Herbert
>
> > 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
-Original Message-
From: Tom Herbert
> 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
l performance penalty.
> I am not sure which reason is bigger: additional cost or security risk. It
> depends on the organization type.
> Ed/
> -Original Message-
> From: OPSEC [mailto:opsec-boun...@ietf.org] On Behalf Of Arnaud Taddei
> Sent: Thursday, May 25, 2023 8:1
tested, supported, and somebody
> should pay an additional performance penalty.
> I am not sure which reason is bigger: additional cost or security risk. It
> depends on the organization type.
> Ed/
> -----Original Message-
> From: OPSEC [mailto:opsec-boun...@ietf.org] On Behalf O
On Wed, May 24, 2023 at 6:02 PM Manfredi (US), Albert E
wrote:
>
> -Original Message-
> From: ipv6 On Behalf Of Fernando Gont
>
> > Given the amount of things that get connected to the Net (smart bulbs,
> > refrigerators, etc.) -- and that will super-likely never receive security
> >
addei=40broadcom@dmarc.ietf.org]
Sent: Thursday, May 25, 2023 8:47 AM
To: Vasilenko Eduard
Cc: Fernando Gont ; Manfredi (US), Albert E
; IPv6 Operations ; 6man
; opsec@ietf.org
Subject: Re: [OPSEC] [EXTERNAL] Re: [IPv6] [v6ops] Why folks are blocking IPv6
extension headers? (Episode 1000 and counting)
18 matches
Mail list logo
