On 23-May-23 05:24, Tom Herbert wrote:
On Mon, May 22, 2023 at 10:09 AM Ole Troan
wrote:
Nalini,
Once bugs are fixed, then we need to consider carefully what BCP around EHs
should be done, taking into account various common topologies as well as
devices such as proxies and load
Andrew,
On 22-May-23 23:28, Andrew Campling wrote:
On 21-May-23 10:29 PM, Brian E Carpenter wrote:
And there's the problem. The operator of a large network cannot possibly
know which extension headers every host on the network needs. It's called
permissionless innovation, and is supposed to
David Farmer wrote:
>> I think that many of us are still reeling from default configuration
>> of certain "firewalls" that banks seemed like, which dropped packets
>> containing ECN, and TCP options, and made it very very difficult to
>> deploy new things. Even when at the IETF
On 22-May-23 22:03, Ole Troan wrote:
It depends on your position in the network.
A) Transit AS:
Should transparently pass all traffic and not look beyond the 40-byte IPv6
header.
With the exception of NH=0.
Let’s have that discussion if there ever is a HBH option with “transit AS
On Mon, May 22, 2023 at 12:29 PM Fernando Gont wrote:
>
> Hi, David,
>
> On 22/5/23 18:05, David Farmer wrote:
> [...]
> >
> > I think that many of us are still reeling from default configuration of
> > certain "firewalls" that banks seemed like, which dropped packets
> > containing
>
On Mon, May 22, 2023 at 12:05 PM Fernando Gont wrote:
>
> Hi, Ole,
>
> On 22/5/23 15:36, Ole Troan wrote:
> [...]>>
> >> As a host and networking stack developer, I view the network and these
> >> arbitrary inconsistent security policies as the problem not as the
> >> solution to application and
Hi, David,
On 22/5/23 18:05, David Farmer wrote:
[...]
I think that many of us are still reeling from default configuration of
certain "firewalls" that banks seemed like, which dropped packets
containing
ECN, and TCP options, and made it very very difficult to deploy new
Hi, Ole,
On 22/5/23 15:36, Ole Troan wrote:
[...]>>
As a host and networking stack developer, I view the network and these
arbitrary inconsistent security policies as the problem not as the
solution to application and host security. The best tool developers
have is to encrypt as much of the
> Thanks for all your efforts!
Thanks for the kind words, Tom.
> I'd also point out that work is also underway to fix the protocol "bugs" with
>EH in> draft-ietf-6man-hbh-processing and draft-ietf-6man-eh-limits.
Great!
Thanks,
Nalini Elkins
CEO and Founder
Inside Products, Inc.
Tom,
>> Unless the application had a particular use for a extension header I would
>> not implement it.
>
> So you only run one application in your network? :-) Even if you
> polled every user in the network about every application they're
> running and found they don't currently use a certain
Ole,
> What would you even do with EHs through a load balancer?
I think a load balancer should pass EHs from the origin or destination through
unchanged or undropped. I, being a developer myself, can think of some quite
unfortunate actions which could occur if this is not done. It should
On Mon, May 22, 2023 at 10:09 AM Ole Troan
wrote:
>
> Nalini,
>
> >
> > Once bugs are fixed, then we need to consider carefully what BCP around EHs
> > should be done, taking into account various common topologies as well as
> > devices such as proxies and load balancers. I mention those in
Hi, Brian,
On 21/5/23 22:28, Brian E Carpenter wrote:
[...]
I'm not sure how that's a no brainer, who decides "the ones you really
need"?
Typically. whoever runs the destination AS or network. Or the transit
AS, if the packets will affect the transit AS.
And there's the problem. The
On Mon, May 22, 2023 at 10:53 AM Michael Richardson
wrote:
>
> David Farmer wrote:
> > "permissionless innovation." That being said, we MUST balance these
> > multiple priorities. which means we can not completely sacrifice
> > "permissionless innovation" to "security" and
On Mon, May 22, 2023 at 9:35 AM nalini.elk...@insidethestack.com
wrote:
>
> Ole,
>
> >>> it might be time that we accept that this was a bad idea. Which
> >>> deployment status has confirmed.
>
> >> Is it your intent to submit a draft deprecating IPv6 Extension Headers?
>
> > Do you want me to?
Nalini,
>
> Once bugs are fixed, then we need to consider carefully what BCP around EHs
> should be done, taking into account various common topologies as well as
> devices such as proxies and load balancers. I mention those in particular as
> what we have found points to those devices in
Ole,
>>> it might be time that we accept that this was a bad idea. Which deployment
>>> status has confirmed.
>> Is it your intent to submit a draft deprecating IPv6 Extension Headers?
> Do you want me to?
> A couple of them seem to have found some use within limited domains. Those
> problems
Hi Nalini,
> > it might be time that we accept that this was a bad idea. Which deployment
> > status has confirmed.
>
> Is it your intent to submit a draft deprecating IPv6 Extension Headers?
Do you want me to?
A couple of them seem to have found some use within limited domains. Those
David Farmer wrote:
> "permissionless innovation." That being said, we MUST balance these
> multiple priorities. which means we can not completely sacrifice
> "permissionless innovation" to "security" and "privacy" either.
+1
> 1. Certain EH constructs SHOULD never be allowed;
Hi Warren,
Thanks for that, I'll publish the revision right after your confirmation
(for the security question). Please see inline ([JI] tag).
On 5/20/23 22:02, Warren Kumari wrote:
Hi there, authors (and WG),
Thank you for this document. In general I found it clear, useful, and
an easy
On Mon, May 22, 2023 at 7:37 AM Ole Troan
wrote:
>
> Tom,
>
> > The problem is in public networks where the service provider acts as
> > "anonymous big brother" to enforce its concept of security to
> > "protect" the users. While I'm sure they'd like us to think that they
> > are acting for the
On Sun, May 21, 2023 at 4:29 PM Brian E Carpenter <
brian.e.carpen...@gmail.com> wrote:
> On 21-May-23 21:33, Fernando Gont wrote:
> > Typically. whoever runs the destination AS or network. Or the transit
> > AS, if the packets will affect the transit AS.
>
> And there's the problem. The operator
Ole,
> it might be time that we accept that this was a bad idea. Which deployment
> status has confirmed.
Is it your intent to submit a draft deprecating IPv6 Extension Headers?
Thanks,
Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360
On Monday,
Thanks for the feedback, Nalini. I believe that Ole’s subsequent comment
captured my concern and position in more precise technical terms:
Ole:
> Now for EHs in general. Their functionality of providing a separate
> signalling channel independent of the application… it might be time that we
>
Bob,
I am not sure of what you are saying.
> New uses should require protocol updates via the standard process or new
> protocols
Of course, protocol updates will go through the IETF process. All I am saying
is that sitting here in 2023, we cannot tell what "new uses" will be found in
2033.
Tom,
> The problem is in public networks where the service provider acts as
> "anonymous big brother" to enforce its concept of security to
> "protect" the users. While I'm sure they'd like us to think that they
> are acting for the benefit of the users and it's for the "good of the
> Internet",
On Mon, May 22, 2023 at 4:29 AM Andrew Campling
wrote:
>
> On 21-May-23 10:29 PM, Brian E Carpenter wrote:
>
> > And there's the problem. The operator of a large network cannot possibly
> > know which extension headers every host on the network needs. It's called
> > permissionless innovation,
From way up in the nose-bleed section for lurkers:
> Although, IMHO one of the points of extension headers is that they can be
> used to extend the protocol for purposes which we cannot think of today!
Something tells me that’s a bad idea for Internet-grade (and similar) standard
protocols …
On 21-May-23 10:29 PM, Brian E Carpenter wrote:
> And there's the problem. The operator of a large network cannot possibly
> know which extension headers every host on the network needs. It's called
> permissionless innovation, and is supposed to be one of the main success
> factors for the
Hi, all
I have written a blog on APNIC discussing the limitations of using extension headers in IPv6, the security issues associated with extension headers, and how to optimize the use of IPv6 extension headers.Here is the link to the blog on APNIC where I
It depends on your position in the network.
A) Transit AS:
Should transparently pass all traffic and not look beyond the 40-byte IPv6
header.
With the exception of NH=0.
Let’s have that discussion if there ever is a HBH option with “transit AS
applicability”.
B) Limited Domain
C) Modern
Delete
--
This electronic communication and the information and any files transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged,
32 matches
Mail list logo
