Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery
updates
Extracted elements (14)
For traditional ND, the only plausible reason to fragment would be a Router Advertisement carrying a very large number of options, but this can always be avoided by splitting the information across multiple RA messages instead. Splitting is preferable even for interoperability since some ND implementations silently ignore fragmented RAs.
Forbidding IPv6 fragmentation in Neighbor Discovery normalizes existing behavior and sets expectations to the lowest common denominator, because: (1) a significant number of existing implementations already silently drop fragmented ND messages; (2) packets large enough to require fragmentation are unlikely in practice; and (3) large ND information can always be split across multiple messages.
SEND Certification Path Advertisement messages are treated differently from other ND messages because the Certificate Option they carry can contain substantially more data than any other ND option, potentially exceeding the local link MTU, making it impractical to forbid fragmentation entirely for CPA.
Some Neighbor Discovery implementations are known to silently ignore Router Advertisement messages that employ fragmentation. Operators detecting silently dropped ND traffic should check whether the sending device supports preventing ND fragmentation; resolution may require a software upgrade.
With 2048-bit keys as required by RFC 6494, Certification Path Advertisement packets range from 1127 to 1238 bytes, which is below the minimum IPv6 MTU of 1280 bytes. However, if 4096-bit keys become required in the future, a larger MTU or protocol changes may be needed to carry CPA without fragmentation.
Nodes MUST NOT employ IPv6 fragmentation for sending Neighbor Solicitation, Neighbor Advertisement, Router Solicitation, Router Advertisement, Redirect, or Certification Path Solicitation messages.
Nodes MUST silently ignore Neighbor Solicitation, Neighbor Advertisement, Router Solicitation, Router Advertisement, Redirect, and Certification Path Solicitation messages if the packets carrying them include an IPv6 Fragmentation Header.
Nodes SHOULD normally process Certification Path Advertisement messages when the packets carrying them include an IPv6 Fragmentation Header, since CPA messages may legitimately exceed the link MTU.
Nodes SHOULD NOT employ IPv6 fragmentation for sending Certification Path Advertisement (CPA) messages, per Section 6.4.2 of RFC 3971.
SEND nodes SHOULD NOT employ keys that would result in fragmented Certification Path Advertisement messages, to avoid exposing CPA exchanges to IPv6 fragmentation-based attacks.
Neighbor Discovery Protocol (RFC 4861) messages covered by this document include: Neighbor Solicitation, Neighbor Advertisement, Router Solicitation, Router Advertisement, and Redirect. All are forbidden from using the IPv6 Fragmentation Header.
SEcure Neighbor Discovery (SEND, RFC 3971) introduces two additional message types relevant here: Certification Path Solicitation (CPS), which is forbidden from using IPv6 fragmentation, and Certification Path Advertisement (CPA), which SHOULD avoid but MAY use fragmentation when necessary.
The IPv6 Fragmentation Header can be leveraged to circumvent network monitoring tools and current implementations of RA-Guard, since layer-2 devices cannot find all necessary filtering information within a single fragment. Forbidding the Fragment Header in all ND messages except CPA greatly simplifies protection of local nodes against ND attacks.
When SEND Certification Path Advertisement messages employ IPv6 fragmentation, an attacker on the same broadcast domain can forge IPv6 fragments to cause Fragment ID collisions, causing both attack and legitimate fragments to be discarded. This can cause Authorization Delegation Discovery to fail, leading the host to fall back to unsecured mode or reject Router Advertisements, resulting in a denial of service.