Skip to content

[ssm, multicast] align source address validation with dpd, nexus and mgd - #1049

Open
zeeshanlakhani wants to merge 1 commit into
masterfrom
zl/mcast-source-validation
Open

[ssm, multicast] align source address validation with dpd, nexus and mgd#1049
zeeshanlakhani wants to merge 1 commit into
masterfrom
zl/mcast-source-validation

Conversation

@zeeshanlakhani

@zeeshanlakhani zeeshanlakhani commented Aug 31, 2026

Copy link
Copy Markdown
Contributor

This work adds a series of validation checks, including these new ones:

  • Rejecting IPv6 sources that embed an IPv4 address: the IPv4-mapped and IPv4-compatible forms of RFC 4291 sections 2.5.5.1 and 2.5.5.2, and the well-known NAT64 prefix 64:ff9b::/96 of RFC 6052 sect. 2.1.
  • Rejecting IPv4 sources in 0.0.0.0/8 and 240.0.0.0/4:
    • class E (240.0.0.0/4): the IANA special-purpose registry (RFC 6890) marks it "Source: False", so it may never appear as a source.
    • 0.0.0.0/8 is "Source: True", since RFC 1122 sect 3.2.1.3 allows it before a host learns its address, but an (S,G) source must be a specific unicast address that reverse-path forwarding can resolve to an incoming interface, which it never is.
    • shared address space (100.64.0.0/10, RFC 6598) is "Source: True" and not globally reachable, so it stays allowed here.
  • We add new address predicates: Ipv4Addr::is_this_network, Ipv4Addr::is_reserved, and Ipv6Addr::embedded_ipv4_form. These sit on the address types but the policy composing them into the source rules lives on SourceFilter, so that multicast policy does not leak onto a generic address type. Both handlers holding a SourceFilter can then share it easily.
  • Only Include sets are checked btw: an Exclude set names traffic to drop, and an operator may want to block an address that could never be a real source anyway.

Note: this is not a refactor. set_mcast_forwarding validated no source addresses at all before now. Eery rule above is a new reject on that path. This aligns us with the other repos and the ongoing oxnet refactoring.

@zeeshanlakhani
zeeshanlakhani force-pushed the zl/mcast-source-validation branch from edd8653 to 3e2615e Compare August 31, 2026 11:34
@zeeshanlakhani
zeeshanlakhani force-pushed the zl/mcast-source-validation branch 2 times, most recently from 8e02176 to 9d307fd Compare September 3, 2026 10:21
This work adds a series of validation checks, including these new ones:

- Rejecting IPv6 sources that embed an IPv4 address: the IPv4-mapped and
  IPv4-compatible forms of RFC 4291 sections 2.5.5.1 and 2.5.5.2, and
  the well-known NAT64 prefix 64:ff9b::/96 of RFC 6052 sect. 2.1.
- Rejecting IPv4 sources in 0.0.0.0/8 and 240.0.0.0/4:
  - class E (240.0.0.0/4): the IANA special-purpose registry (RFC 6890)
    marks it "Source: False", so it may never appear as a source.
  - 0.0.0.0/8 is "Source: True", since RFC 1122 sect 3.2.1.3 allows it
    before a host learns its address, but an (S,G) source must be a
    specific unicast address that reverse-path forwarding can resolve to
    an incoming interface, which it never is.
  - shared address space (100.64.0.0/10, RFC 6598) is "Source: True" and
    not globally reachable, so it stays allowed here.
- We add new address predicates: `Ipv4Addr::is_this_network`,
  `Ipv4Addr::is_reserved`, and `Ipv6Addr::embedded_ipv4_form`. These sit
  on the address types but the policy composing them into the source
  rules lives on `SourceFilter`, so that multicast policy does not leak
  onto a generic address type. Both handlers holding a `SourceFilter`
  can then share it easily.
- Only `Include` sets are checked btw: an `Exclude` set names traffic
  to drop, and an operator may want to block an address that could
  never be a real source anyway.

Note: this is not a refactor. `set_mcast_forwarding` validated no
source addresses at all before now. Eery rule above is a new reject
on that path. This aligns us with the other repos and the ongoing oxnet
refactoring.
@zeeshanlakhani
zeeshanlakhani force-pushed the zl/mcast-source-validation branch from 9d307fd to 20656f7 Compare September 3, 2026 10:32
@zeeshanlakhani zeeshanlakhani self-assigned this Sep 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant