On Thu, Jul 23, 2026 at 02:16:20PM +0200, Dumitru Ceara wrote:
> Hi Ilya, Mairtin,
>
> On 7/23/26 1:16 PM, Ilya Maximets wrote:
> > On 7/16/26 2:11 PM, Dumitru Ceara wrote:
> >> Hi Ilya, Mairtin,
> >>
> >> On 7/11/26 12:22 AM, Ilya Maximets wrote:
> >>> On 7/10/26 11:05 PM, Dumitru Ceara wrote:
> >>>> Hi Ilya,
> >>>>
> >>>> On 7/10/26 6:01 PM, Ilya Maximets wrote:
> >>>>> On 7/10/26 12:57 AM, Mairtin O'Loingsigh via dev wrote:
> >>>>>> Add a new "pass-related" action that behaves like "pass" for
> >>>>>> verdict (no verdict bit is set, so evaluation continues to
> >>>>>> the next tier) but follows the stateful path like
> >>>>>> "allow-related": it matches on hint registers, commits the
> >>>>>> connection via conntrack, and allows established/related
> >>>>>> traffic flows.
> >>>>>
> >>>>> I didn't read the code, so I'm not sure if ti is implemented this way,
> >>>>> but it feels like the semantics as it is described is not what it
> >>>>> supposed to be. If I see pass-related, I think that the related
> >>>>> traffic will have pass semantics as well, i.e., will be passed through
> >>>>> this ACL tier and be evaluated in the next tier. So, it will not just
> >>>>> be automatically allowed. Does that make sense?
> >>>>>
> >>>>
> >>>> I'm not sure we ever reached agreement on that. But please see below on
> >>>> why I think the approach Mairtin is following is what we should pursue.
> >>>>
> >>>>> Also, if the lower tier ACL allows the packet then what is the actual
> >>>>> difference between the higher tier ACL being pass or pass-related?
> >>>>>
> >>>>> This feature needs a lot more documentation for how it works.
> >>>>>
> >>>>> IIRC, the original description in the ticket is not really correct
> >>>>> and the way ACLs actually work wouldn't allow for what ovn-kubenetes
> >>>>> wanted.
> >>>>>
> >>>>> I vaguely remember that we ended up with the thought that pass-related
> >>>>> only makes sense for the same direction related traffic like FTP.
> >>>>> But I don't remember details. Dumitru, do you remember more context?
> >>>>>
> >>>>
> >>>> The way I remember it is that the current implementation has the right
> >>>> semantics for let's call them "older" uses of "multi-tier" pass ACLs in
> >>>> ovn-kubernetes.
> >>>>
> >>>> That's because there's always a highest-tier allow-related ACL
> >>>> configured by ovn-kubernetes.
> >>>>
> >>>> So traffic initiating new connections that hits "pass" rules in lower
> >>>> tiers and finally is either explicitly or implicitly allowed in the
> >>>> highest tier will always be committed to conntrack.
> >>>>
> >>>> Replies (and related packets) for such traffic will find the existing
> >>>> conntrack entry and will be correctly allowed.
> >>>>
> >>>> The only remaining problem is the case when we really have no
> >>>> allow-related ACLs configured on the switch.
> >>>>
> >>>> And I think you're right the only hard to tackle case then is related
> >>>> traffic.
> >>>>
> >>>> In a sandbox:
> >>>>
> >>>>> ovn-nbctl show ls
> >>>> switch 31b890ac-f8ba-4c20-9e21-ebbd606e781e (ls)
> >>>> port lsp1
> >>>> port lsp2
> >>>>
> >>>> # Explicitly drop FTP data traffic (port 20) in tier 1,
> >>>> # except for sessions allowed in tier 0.
> >>>
> >>> This is a misleading description, as tier 0 doesn't allow anything.
> >>>
> >>
> >> Sure, it should've been "allowed to pass to tier 1". Or whatever
> >> synonym of "allow" we want to use.
> >>
> >>>>> ovn-nbctl acl-list ls
> >>>> from-lport 100 (inport == "lsp1" && tcp.dest == 21) pass [tier 0]
> >>>> from-lport 100 (tcp.dst == 20) drop [tier 1]
> >>>>
> >>>> FTP data traffic from lsp1 (TCP dest port 20) will never make it through
> >>>> no matter what we add in tier 1, right?
> >>>
> >>> You can make the tier 0 ACL allow-related to make it go through.
> >>>
> >>>>
> >>>> But with the "pass-related" semantics Mairtin is adding, we'd have:
> >>>>
> >>>>> ovn-nbctl acl-list ls
> >>>> from-lport 100 (inport == "lsp1" && tcp.dest == 21) pass-related [tier
> >>>> 0]
> >>>> from-lport 100 (tcp.dst == 20) drop [tier 1]
> >>>>
> >>>> The first FTP control packet (TCP SYN towards port 21) hits the ACL in
> >>>> tier 0. It's a pass-related ACL so eventually, at the end of the
> >>>> complete ACL evaluation stage (after all tiers) we commit the session to
> >>>> conntrack.
> >>>
> >>> But it is pass-related, not allow-related. So, related connection should
> >>> be passed to the next tier and match there and be dropped by the tier 1
> >>> ACL.
> >>>
> >>
> >> So, implementation details aside, how would "pass-related" ever be
> >> useful. What's an example of tiered-ACL configuration, assuming the
> >> semantics you're describing ("related connection should be passed to the
> >> next tier"), it would make sense in? I'm failing to find one, I thought
> >> the FTP example was one but that's not true as you pointed out below.
> >>
> >>> The fact that you have pass-related turns every allow into allow-related
> >>> because everything is now committed into conntrack. In this case the
> >>> implicit default-allow is turned into implicit default allow-related.
> >>>
> >>> But you can achieve exactly the same behavior by using allow-related in
> >>> the
> >>> tier 0 in the first place. Or by adding a low priority explicit default
> >>> allow-related at the last tier, which pass-related in this implementation
> >>> appears to be just a misleading syntactic sugar for.
> >>>
> >>
> >> Adding a tier-0 allow-related instead of pass-related completely
> >> bypasses tier-1 where stricter drop rules may exist. But you're right
> >> about the explicit tier-1 allow-related, that would fix it.
> >>
> >> It can't be the default low priority allow-related though, what if the
> >> CMS has an explicit default drop ACL. It would actually need to be an
> >> explicit allow-related ACL matching on a superset of all "pass"
> >> conditions that could've been matched in previous tiers.
> >>
> >> The syntactic sugar wouldn't help much with the match part of such an
> >> ACL, the CMS would still have to build that in the same way.
> >>
> >>> Does that make sense?
> >>>
> >>
> >> So, all that said, I'm really wondering now if we need pass-related in
> >> the end or not. I thought there were cases we can't easily cover today
> >> but based on the discussion here it seems the actual hard work for the
> >> CMS is figuring out the last-tier match conditions. Which this
> >> pass-related feature wouldn't help with, I think.
> >>
> >> Should we drop this feature?
> >
> > We can create fictional situation where we only want to drop very
> > specific packets from the related traffic, but allow the rest. And
> > the pass-related would be handy in such cases. But I don't see a
> > real-world situation where it would be needed. So, we may as well
> > avoid further complicating the already complicated ACL semantics
> > until we have a real use case.
> >
>
> OK, maybe it's better to wait with this feature until we have a real use
> case like that. I agree that the ACL semantics are already complicated.
>
> Mairtin, if you agree, I'd say let's close the Jira ticket on our side
> documenting the discussion we had here. We can reconsider it in the
> future if we have a clear use case that cannot be handled by the current
> semantics. What do you think?
>
> > Best regards, Ilya Maximets.
>
> Thanks,
> Dumitru
>
Sounds good to me.
Thanks,
Mairtin
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
