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.
Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
