netdev - Re: [PATCH net-next v4 2/5] ipv6: ioam: Data plane support for Pre-allocated Trace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1616887215.34203636.1622386231363.JavaMail.zimbra@uliege.be>
Date:   Sun, 30 May 2021 16:50:31 +0200 (CEST)
From:   Justin Iurman <justin.iurman@...ege.be>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, tom@...bertland.com
Subject: Re: [PATCH net-next v4 2/5] ipv6: ioam: Data plane support for
 Pre-allocated Trace

>>> A per-interface sysctl ioam6_enabled is provided to process/ignore IOAM
>>> headers. Default is ignore (= disabled). Another per-interface sysctl
>>> ioam6_id is provided to define the IOAM (unique) identifier of the
>>> interface. Default is 0. A per-namespace sysctl ioam6_id is provided to
>>> define the IOAM (unique) identifier of the node. Default is 0.
>> 
>> Last two sentences are repeated.
> 
> One describes net.ipv6.conf.XXX.ioam6_id (per interface) and the other describes
> net.ipv6.ioam6_id (per namespace). It allows for defining an IOAM id to an
> interface and, also, the node in general.
> 
>> Is 0 a valid interface ID? If not why not use id != 0 instead of
>> having a separate enabled field?
> 
> Mainly for semantic reasons. Indeed, I'd prefer to keep a specific "enable" flag
> per interface as it sounds more intuitive. But, also because 0 could very well
> be a "valid" interface id (more like a default value).

Actually, it's more than for semantic reasons. Take the following topology:

 _____              _____              _____
|     | eth0  eth0 |     | eth1  eth0 |     |
|  A  |.----------.|  B  |.----------.|  C  |
|_____|            |_____|            |_____|

If I only want IOAM to be deployed from A to C but not from C to A, then I would need the following on B (let's just focus on B):

B.eth0.ioam6_enabled = 1 // enable IOAM *on input* for B.eth0
B.eth0.ioam6_id = B1
B.eth1.ioam6_id = B2

Back to your suggestion, if I only had one field (i.e., ioam6_id != 0 to enable IOAM), I would end up with:

B.eth0.ioam6_id = B1 // (!= 0)
B.eth1.ioam6_id = B2 // (!= 0)

Which means in this case that IOAM would also be enabled on B for the reverse path. So we definitely need two fields to distinguish both the status (enabled/disabled) and the IOAM ID of an interface.