On Mon, May 22, 2023 at 10:09 AM Ole Troan <otroan=40employees....@dmarc.ietf.org> 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 particular > > as what we have found points to those devices in particular as posing > > problems rather than transit networks. > > I look at load balancers as an extension of the application (or network > function).
Ole, If you're talking about a transparent proxy or a transparent stateful device in the network, I tend to view those devices as potentially invasive and harmful to an application as opposed to an extension of the application. Think of all the problems we've had with stateful middleboxes and all the hacks we need in networking stacks to work around them... > 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 protocol, what happens the next day when one of your customers wants to use the banned protocol? > And that’s with an implementors hat on. Writing custom load-balancers for > network services. > What would you even do with EHs through a load balancer? Provide ALGs for EHs > containing addresses inside of them? It would have to be on a case by case > basis. Why would a load balancer care about EH? In the worst case, don't you just need to parse over the extension headers to find the transport layer headers for load balancing (note RFC8200 allow intermediate nodes to not process HBH options). Tom > > > > Of course, our testing to date is absolute lack of transmission rather than > > lack of transmission based on EH length or type. We felt that was the > > logical first step. > > O. _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec
