Re: IPv6 payload length check?

[Fernando Gont <[e-mail]>]

Hello, Aitken,

On 3/2/20 12:30, Aitken, Paul wrote:
> Can anyone point me to a standards reference for the check to validate
> that the IPv6 payload length is less than or equal to the link layer
> frame size upon forwarding a packet?

There is no standards reference for that check.

That said, years ago I worked on a consulting project where, among other 
things, we specified validation checks for IPv6 packets.

This is the relevant excerpt for the "Payload Length":

----cut here ----
The Payload Length is a 16-bit unsigned integer that indicates the 
length of the IPv6 payload (i.e., length of the rest of the packet 
following the fixed IPv6 header). Implementations should be aware that 
the IPv6 module could be handed a packet larger than that
implied by the value of the Payload Length field. Such difference in the 
packet size might have todo with legitimate padding bytes at the 
link-layer protocol, but it could also be the result of malicious 
activity by an attacker. Furthermore, even when the maximum length of an 
IPv6
datagram is 65855 bytes (40 bytes for the fixed IPv6 header, plus 65535 
bytes for the payload), if the link-layer technology in use allows for 
payloads larger than 65855 bytes, an attacker could forge such a large 
link-layer packet, and direct it to the IPv6 module. If the IPv6 module 
of the receiving system were not prepared to handle such an oversized 
link-layer payload, an unexpected failure might occur. Therefore, the 
memory buffer used to store the link-layer payload should be allocated 
according to the payload size reported by the Link layer.

The IPv6 module could also be handed a packet that is smaller than the 
actual IPv6 packet size implied by the Payload Length field. This could 
be used, for example, to produce an information leakage. Therefore, the 
following check should be performed:

           Payload Length <= LinkLayer.PayloadSize - 40

       (The length of the ‘fixed’ IPv6 header is 40 bytes.)

As stated in RFC 2675 [Borman et al, 1999], if a node that supports the 
Jumbo Payload option receives a packet with a Payload Length of 0 and 
with a Next Header of 0 (meaning that a Hop-by-Hop Options header 
follows), and the link layer indicates the presence of octets beyond the
IPv6 header, the node must proceed to process the Hop-by-hop Options 
header to determine theactual length of the payload from the Jumbo 
Payload option.

If the Payload Length is 0, but the Next Header is not 0, the packet 
should be dropped, and an ICMPv6 Parameter Problem (code 0) error 
message (with the ‘Pointer’ pointing to the high-order octet of the 
Payload Length ) should be sent to the Source Address of the offending 
packet (provided it is not a multicast address). Additionally, if the 
Payload length is 0 and the Next Header is 0, but the Hop-by-hop Options 
header does not include a Jumbo Payload option, the corresponding packet 
should be dropped, and an ICMPv6 Parameter Problem (code 0) error 
message (with the ‘Pointer’ pointing to the high-order octet of the 
Payload Length ) should be sent to the Source Address of the offending 
packet (provided it is not a multicast address).
---- cut here ----

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492