Multus network-attach-def ipv6 is not obfuscated #3008
Comments
|
No, |
|
Thank you, TT. Just wonder if you have this ipv6 feature support in the future? |
|
It's definitely on the list. The actual matching of addresses is not really an issue - the stance we have on consistent network topology after obfuscation is however. By this I mean, with ipv4 we maintain network topology and relationships with addresses. If we find an address from a new subnet, we create a new obfuscation subnet and assign addresses from there - it's not complete random assignment or even scrubbing an address to simply "--obfuscated_addr_0001--". This was a conscious decision made at the request of RH support teams (as a quick example, having topology consistent addressing can highlight a routing issue whereas scrubbing all addresses to "addr_XYZ" would hinder if not outright prevent that). So, for ipv6 we would want to maintain that consistency. Given how much more complex ipv6 addressing is, and how the address format is malleable, this becomes fairly difficult to do within sos. If there is another python module that has the ability to spit out addresses (e.g. "create an ipv6subnet object, and from it be able to generate addresses within that subnet on the fly") then that would make this implementation pretty straightforward actually. |
TurboTurtle
added a commit
to TurboTurtle/sos
that referenced
this issue
Nov 4, 2022
This commit adds a new parser and accompanying map for obfuscating IPv6 addresses. This new parser will attempt to capture valid IPv6 networks and addresses, and produce a mostly-randomized obfuscated pair. Due to the multiple formats an IPv6 address can take, some identifiers are necessary to preserve relevant information while still obfuscating actual addresses and networks. For example, global unicast addresses that have more than one defined hextet (greater than /16 prefix) will always generate an obfuscated address starting with `534f` (or 'so', continuing the style of our mac address handling that uses 'sos' as an identifier). Addresses with a /16 prefix or less, will start with simply '53'. Private addresses, which start with `fd` will generate an obfuscated address starting with `fd53`, so that the contextual understanding that it is a private network/address can remain. Link-local addresses which start with `fe80::` will remain that way, only having the device hextets obfuscated - again, keeping the contextual information that it is a link-local interface intact, as otherwise these obfuscations may confuse end users reviewing an sos report for problems. Note that the address `::1` and `::/0` are explicitly skipped and never obfuscated, for the same reasons given above. Additionally, this parser/map will write data to the default map (and any per-run private maps) differently than previous parsers. Rather than simply dumping the obfuscation pairs into the map, it is broken up via network, with hosts belonging to that network nested inside those network entries (still being json-formatted). Users will also note that the ipv6 entries in the map also have a `version` key, which is intended to be used for handling future updates to the parser/map when upgrading from an older sos version to a newer one. This may or may not be carried over to future updates to other parsers. Closes: sosreport#3008 Related: RHBZ#2134906 Signed-off-by: Jake Hunsaker <jhunsake@redhat.com>
5 tasks
TurboTurtle
added a commit
to TurboTurtle/sos
that referenced
this issue
Nov 10, 2022
This commit adds a new parser and accompanying map for obfuscating IPv6 addresses. This new parser will attempt to capture valid IPv6 networks and addresses, and produce a mostly-randomized obfuscated pair. Due to the multiple formats an IPv6 address can take, some identifiers are necessary to preserve relevant information while still obfuscating actual addresses and networks. For example, global unicast addresses that have more than one defined hextet (greater than /16 prefix) will always generate an obfuscated address starting with `534f` (or 'so', continuing the style of our mac address handling that uses 'sos' as an identifier). Addresses with a /16 prefix or less, will start with simply '53'. Private addresses, which start with `fd` will generate an obfuscated address starting with `fd53`, so that the contextual understanding that it is a private network/address can remain. Link-local addresses which start with `fe80::` will remain that way, only having the device hextets obfuscated - again, keeping the contextual information that it is a link-local interface intact, as otherwise these obfuscations may confuse end users reviewing an sos report for problems. Note that the address `::1` and `::/0` are explicitly skipped and never obfuscated, for the same reasons given above. Additionally, this parser/map will write data to the default map (and any per-run private maps) differently than previous parsers. Rather than simply dumping the obfuscation pairs into the map, it is broken up via network, with hosts belonging to that network nested inside those network entries (still being json-formatted). Users will also note that the ipv6 entries in the map also have a `version` key, which is intended to be used for handling future updates to the parser/map when upgrading from an older sos version to a newer one. This may or may not be carried over to future updates to other parsers. Closes: sosreport#3008 Related: RHBZ#2134906 Signed-off-by: Jake Hunsaker <jhunsake@redhat.com>
TurboTurtle
added a commit
to TurboTurtle/sos
that referenced
this issue
Nov 14, 2022
This commit adds a new parser and accompanying map for obfuscating IPv6 addresses. This new parser will attempt to capture valid IPv6 networks and addresses, and produce a mostly-randomized obfuscated pair. Due to the multiple formats an IPv6 address can take, some identifiers are necessary to preserve relevant information while still obfuscating actual addresses and networks. For example, global unicast addresses that have more than one defined hextet (greater than /16 prefix) will always generate an obfuscated address starting with `534f` (or 'so', continuing the style of our mac address handling that uses 'sos' as an identifier). Addresses with a /16 prefix or less, will start with simply '53'. Private addresses, which start with `fd` will generate an obfuscated address starting with `fd53`, so that the contextual understanding that it is a private network/address can remain. Link-local addresses which start with `fe80::` will remain that way, only having the device hextets obfuscated - again, keeping the contextual information that it is a link-local interface intact, as otherwise these obfuscations may confuse end users reviewing an sos report for problems. Note that the address `::1` and `::/0` are explicitly skipped and never obfuscated, for the same reasons given above. Additionally, this parser/map will write data to the default map (and any per-run private maps) differently than previous parsers. Rather than simply dumping the obfuscation pairs into the map, it is broken up via network, with hosts belonging to that network nested inside those network entries (still being json-formatted). Users will also note that the ipv6 entries in the map also have a `version` key, which is intended to be used for handling future updates to the parser/map when upgrading from an older sos version to a newer one. This may or may not be carried over to future updates to other parsers. Closes: sosreport#3008 Related: RHBZ#2134906 Signed-off-by: Jake Hunsaker <jhunsake@redhat.com>
TurboTurtle
added a commit
to TurboTurtle/sos
that referenced
this issue
Nov 14, 2022
This commit adds a new parser and accompanying map for obfuscating IPv6 addresses. This new parser will attempt to capture valid IPv6 networks and addresses, and produce a mostly-randomized obfuscated pair. Due to the multiple formats an IPv6 address can take, some identifiers are necessary to preserve relevant information while still obfuscating actual addresses and networks. For example, global unicast addresses that have more than one defined hextet (greater than /16 prefix) will always generate an obfuscated address starting with `534f` (or 'so', continuing the style of our mac address handling that uses 'sos' as an identifier). Addresses with a /16 prefix or less, will start with simply '53'. Private addresses, which start with `fd` will generate an obfuscated address starting with `fd53`, so that the contextual understanding that it is a private network/address can remain. Link-local addresses which start with `fe80::` will remain that way, only having the device hextets obfuscated - again, keeping the contextual information that it is a link-local interface intact, as otherwise these obfuscations may confuse end users reviewing an sos report for problems. Note that the address `::1` and `::/0` are explicitly skipped and never obfuscated, for the same reasons given above. Additionally, this parser/map will write data to the default map (and any per-run private maps) differently than previous parsers. Rather than simply dumping the obfuscation pairs into the map, it is broken up via network, with hosts belonging to that network nested inside those network entries (still being json-formatted). Users will also note that the ipv6 entries in the map also have a `version` key, which is intended to be used for handling future updates to the parser/map when upgrading from an older sos version to a newer one. This may or may not be carried over to future updates to other parsers. Closes: sosreport#3008 Related: RHBZ#2134906 Signed-off-by: Jake Hunsaker <jhunsake@redhat.com>
TurboTurtle
added a commit
to TurboTurtle/sos
that referenced
this issue
Nov 14, 2022
This commit adds a new parser and accompanying map for obfuscating IPv6 addresses. This new parser will attempt to capture valid IPv6 networks and addresses, and produce a mostly-randomized obfuscated pair. Due to the multiple formats an IPv6 address can take, some identifiers are necessary to preserve relevant information while still obfuscating actual addresses and networks. For example, global unicast addresses that have more than one defined hextet (greater than /16 prefix) will always generate an obfuscated address starting with `534f` (or 'so', continuing the style of our mac address handling that uses 'sos' as an identifier). Addresses with a /16 prefix or less, will start with simply '53'. Private addresses, which start with `fd` will generate an obfuscated address starting with `fd53`, so that the contextual understanding that it is a private network/address can remain. Link-local addresses which start with `fe80::` will remain that way, only having the device hextets obfuscated - again, keeping the contextual information that it is a link-local interface intact, as otherwise these obfuscations may confuse end users reviewing an sos report for problems. Note that the address `::1` and `::/0` are explicitly skipped and never obfuscated, for the same reasons given above. Additionally, this parser/map will write data to the default map (and any per-run private maps) differently than previous parsers. Rather than simply dumping the obfuscation pairs into the map, it is broken up via network, with hosts belonging to that network nested inside those network entries (still being json-formatted). Users will also note that the ipv6 entries in the map also have a `version` key, which is intended to be used for handling future updates to the parser/map when upgrading from an older sos version to a newer one. This may or may not be carried over to future updates to other parsers. Closes: sosreport#3008 Related: RHBZ#2134906 Signed-off-by: Jake Hunsaker <jhunsake@redhat.com>
TurboTurtle
added a commit
to TurboTurtle/sos
that referenced
this issue
Nov 16, 2022
This commit adds a new parser and accompanying map for obfuscating IPv6 addresses. This new parser will attempt to capture valid IPv6 networks and addresses, and produce a mostly-randomized obfuscated pair. Due to the multiple formats an IPv6 address can take, some identifiers are necessary to preserve relevant information while still obfuscating actual addresses and networks. For example, global unicast addresses that have more than one defined hextet (greater than /16 prefix) will always generate an obfuscated address starting with `534f` (or 'so', continuing the style of our mac address handling that uses 'sos' as an identifier). Addresses with a /16 prefix or less, will start with simply '53'. Private addresses, which start with `fd` will generate an obfuscated address starting with `fd53`, so that the contextual understanding that it is a private network/address can remain. Link-local addresses which start with `fe80::` will remain that way, only having the device hextets obfuscated - again, keeping the contextual information that it is a link-local interface intact, as otherwise these obfuscations may confuse end users reviewing an sos report for problems. Note that the address `::1` and `::/0` are explicitly skipped and never obfuscated, for the same reasons given above. Additionally, this parser/map will write data to the default map (and any per-run private maps) differently than previous parsers. Rather than simply dumping the obfuscation pairs into the map, it is broken up via network, with hosts belonging to that network nested inside those network entries (still being json-formatted). Users will also note that the ipv6 entries in the map also have a `version` key, which is intended to be used for handling future updates to the parser/map when upgrading from an older sos version to a newer one. This may or may not be carried over to future updates to other parsers. Closes: sosreport#3008 Related: RHBZ#2134906 Signed-off-by: Jake Hunsaker <jhunsake@redhat.com>
TurboTurtle
added a commit
to TurboTurtle/sos
that referenced
this issue
Nov 30, 2022
This commit adds a new parser and accompanying map for obfuscating IPv6 addresses. This new parser will attempt to capture valid IPv6 networks and addresses, and produce a mostly-randomized obfuscated pair. Due to the multiple formats an IPv6 address can take, some identifiers are necessary to preserve relevant information while still obfuscating actual addresses and networks. For example, global unicast addresses that have more than one defined hextet (greater than /16 prefix) will always generate an obfuscated address starting with `534f` (or 'so', continuing the style of our mac address handling that uses 'sos' as an identifier). Addresses with a /16 prefix or less, will start with simply '53'. Private addresses, which start with `fd` will generate an obfuscated address starting with `fd53`, so that the contextual understanding that it is a private network/address can remain. Link-local addresses which start with `fe80::` will remain that way, only having the device hextets obfuscated - again, keeping the contextual information that it is a link-local interface intact, as otherwise these obfuscations may confuse end users reviewing an sos report for problems. Note that the address `::1` and `::/0` are explicitly skipped and never obfuscated, for the same reasons given above. Additionally, this parser/map will write data to the default map (and any per-run private maps) differently than previous parsers. Rather than simply dumping the obfuscation pairs into the map, it is broken up via network, with hosts belonging to that network nested inside those network entries (still being json-formatted). Users will also note that the ipv6 entries in the map also have a `version` key, which is intended to be used for handling future updates to the parser/map when upgrading from an older sos version to a newer one. This may or may not be carried over to future updates to other parsers. Closes: sosreport#3008 Related: RHBZ#2134906 Signed-off-by: Jake Hunsaker <jhunsake@redhat.com>
TurboTurtle
added a commit
to TurboTurtle/sos
that referenced
this issue
Nov 30, 2022
This commit adds a new parser and accompanying map for obfuscating IPv6 addresses. This new parser will attempt to capture valid IPv6 networks and addresses, and produce a mostly-randomized obfuscated pair. Due to the multiple formats an IPv6 address can take, some identifiers are necessary to preserve relevant information while still obfuscating actual addresses and networks. For example, global unicast addresses that have more than one defined hextet (greater than /16 prefix) will always generate an obfuscated address starting with `534f` (or 'so', continuing the style of our mac address handling that uses 'sos' as an identifier). Addresses with a /16 prefix or less, will start with simply '53'. Private addresses, which start with `fd` will generate an obfuscated address starting with `fd53`, so that the contextual understanding that it is a private network/address can remain. Link-local addresses which start with `fe80::` will remain that way, only having the device hextets obfuscated - again, keeping the contextual information that it is a link-local interface intact, as otherwise these obfuscations may confuse end users reviewing an sos report for problems. Note that the address `::1` and `::/0` are explicitly skipped and never obfuscated, for the same reasons given above. Additionally, this parser/map will write data to the default map (and any per-run private maps) differently than previous parsers. Rather than simply dumping the obfuscation pairs into the map, it is broken up via network, with hosts belonging to that network nested inside those network entries (still being json-formatted). Users will also note that the ipv6 entries in the map also have a `version` key, which is intended to be used for handling future updates to the parser/map when upgrading from an older sos version to a newer one. This may or may not be carried over to future updates to other parsers. Closes: sosreport#3008 Related: RHBZ#2134906 Signed-off-by: Jake Hunsaker <jhunsake@redhat.com>
TurboTurtle
added a commit
that referenced
this issue
Nov 30, 2022
This commit adds a new parser and accompanying map for obfuscating IPv6 addresses. This new parser will attempt to capture valid IPv6 networks and addresses, and produce a mostly-randomized obfuscated pair. Due to the multiple formats an IPv6 address can take, some identifiers are necessary to preserve relevant information while still obfuscating actual addresses and networks. For example, global unicast addresses that have more than one defined hextet (greater than /16 prefix) will always generate an obfuscated address starting with `534f` (or 'so', continuing the style of our mac address handling that uses 'sos' as an identifier). Addresses with a /16 prefix or less, will start with simply '53'. Private addresses, which start with `fd` will generate an obfuscated address starting with `fd53`, so that the contextual understanding that it is a private network/address can remain. Link-local addresses which start with `fe80::` will remain that way, only having the device hextets obfuscated - again, keeping the contextual information that it is a link-local interface intact, as otherwise these obfuscations may confuse end users reviewing an sos report for problems. Note that the address `::1` and `::/0` are explicitly skipped and never obfuscated, for the same reasons given above. Additionally, this parser/map will write data to the default map (and any per-run private maps) differently than previous parsers. Rather than simply dumping the obfuscation pairs into the map, it is broken up via network, with hosts belonging to that network nested inside those network entries (still being json-formatted). Users will also note that the ipv6 entries in the map also have a `version` key, which is intended to be used for handling future updates to the parser/map when upgrading from an older sos version to a newer one. This may or may not be carried over to future updates to other parsers. Closes: #3008 Related: RHBZ#2134906 Signed-off-by: Jake Hunsaker <jhunsake@redhat.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Does sos clean 4.4 support ipv6 yet?
I ran the test using sos clean 4.4, but it seems not cleaned those ipv6.
Add: mvnr-du:du-ddc7f8cb6-qqw8p:3a88000e-bfe3-436e-b810-b2bd290fb66a:mvnr-du/du-f1c-conf(sriov):f1c {"cniVersion":"0.4.0","interfaces":[{"name":"f1c","sandbox":"/var/run/netns/4239d766-68e8-4c74-a983-6e4edf2583d3"}],"ips":[{"version":"6","interface":0,"address":"2607:c540:8c00:3318::34/64","gateway":"2607:c540:8c00:3318::1"}],"routes":[{"dst":"::/0"}],"dns":{}}
Thanks.
The text was updated successfully, but these errors were encountered: