furry13 / v6ops-464xlat-enable

1 stars 1 forks source link

Security considerations for PREF64 and clat/ipv4 coexistence #15

Closed furry13 closed 3 months ago

furry13 commented 5 months ago

PREF64 mist not be used as a signal to disable IPv4 to prevent an attack with rogue PREF64 info on networks w.o L2 IPv6 security

mstojens commented 3 months ago

Right -- if IPv4 connectivity exists, we MUST NOT use CLAT -- I need to go re-check the text, but I'm pretty sure we cover this? If it isn't in Security Considerations already, it definitely should be though.

mstojens commented 3 months ago

We had already done this by writing this:

While disabling CLAT is impactful for all applications and traffic flows already utilizing CLAT, it is recommended not only from performance perspective, but also from security point of view. Because IPv4-only networks are inherently IPv6-ignorant, they might lack IPv6 layer2 security features, such as RA Guard. that would prevent spoofed RAs. An attacker can send an RA containing the PREF64 option, while the network doesn't provide any PLAT functionality. If the node keeps CLAT enabled and uses it for IPv4-only destinations, that traffic could be blackholed (availability attack) or routed through an attacker-controlled route (active attack on insecure traffic or hoarding secure traffic for "Harvest Now, Decrypt Later" attacks for non-PQC secure traffic [draft-ietf-pquip-pqc-engineers Section 8] ). Rogue RAs can also disturb traffic to destinations that support both IPv4 and IPv6 by causing IPv6 through an attacker's PLAT to be used instead of the legitimate network owner's IPv4 path.