Subject: IPv6 payload length check?

From: "Aitken, Paul" <[email-masked]>
Date: Mon, 3 Feb 2020 15:30:43 +0000

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?

Thanks,
Paul

---

From: Erik Kline <[email-masked]>
Date: Mon, 3 Feb 2020 14:05:42 -0800

Interestingly, 8200 contains this text in the Routing Header section (4.4):

"""
   If, after processing a Routing header of a received packet, an
   intermediate node determines that the packet is to be forwarded onto
   a link whose link MTU is less than the size of the packet, the node
   must discard the packet and send an ICMP Packet Too Big message to
   the packet's Source Address.
"""

Really that text would seem to apply even if a routing header is absent.
4443 on PTBs (3.2) has the text you might be looking for:

"""
   A Packet Too Big MUST be sent by a router in response to a packet
   that it cannot forward because the packet is larger than the MTU of
   the outgoing link.
"""

On Mon, Feb 3, 2020 at 7:31 AM Aitken, Paul <[email-masked]>
wrote:

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: "Aitken, Paul" <[email-masked]>
Date: Tue, 4 Feb 2020 07:43:04 +0000

Thanks Eric.

In this case the packet is *not* larger than the MTU of the outgoing link. Rather a packet has been received (or possibly generated locally) with an IPv6 payload length greater than the link layer frame size.

Probably this packet should not be forwarded. However, I couldn't find anything to say that it's invalid.

Thanks,
P.

On 03/02/2020 22:05, Erik Kline wrote:
Interestingly, 8200 contains this text in the Routing Header section (4.4):

"""

Really that text would seem to apply even if a routing header is absent.  4443 on PTBs (3.2) has the text you might be looking for:

"""

On Mon, Feb 3, 2020 at 7:31 AM Aitken, Paul <[email-masked]<mailto:[email-masked]>> 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?

Thanks,
Paul
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=ZfTZz_O9E1tN4KFtMYO2ZkKk5U5-6SlI-21vZEhzDuU&m=qBignlV2D2HjQ1OG98CXIFMbZryHbieyfesxKE4ZOfg&s=Hcp5fCXJd8pXcMtmqOUaw179roZQXSQntvE-zFdQYbY&e=>
--------------------------------------------------------------------

---

From: Mark Smith <[email-masked]>
Date: Tue, 4 Feb 2020 19:40:45 +1100

On Tue, 4 Feb 2020, 18:43 Aitken, Paul, <[email-masked]> wrote:

> Thanks Eric.
>
> In this case the packet is *not* larger than the MTU of the outgoing link.
> Rather a packet has been received (or possibly generated locally) with an
> IPv6 payload length greater than the link layer frame size.
>
> Probably this packet should not be forwarded.
>

It's better to forward it without checking.

These packets with this fault are going to be rare. Checking each and every
packet for this rare problem at each forwarding hop would impact forwarding
performance.

The fault with the packet will be detected at the final destination and
dealt with there.

However, I couldn't find anything to say that it's invalid.

When could it ever be valid?

With protocol specs, everything unspecified is implicitly invalid, because
it is out of specification or unspecified behaviour.

>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=ZfTZz_O9E1tN4KFtMYO2ZkKk5U5-6SlI-21vZEhzDuU&m=qBignlV2D2HjQ1OG98CXIFMbZryHbieyfesxKE4ZOfg&s=Hcp5fCXJd8pXcMtmqOUaw179roZQXSQntvE-zFdQYbY&e=>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 04 Feb 2020 14:45:09 +0100

Mark Smith <[email-masked]> wrote:
    >> Thanks Eric.
    >>
    >> In this case the packet is *not* larger than the MTU of the outgoing link..

    > The fault with the packet will be detected at the final destination and

Yes, I agree that it will get discarded.  Maybe... Probably?

When the hardware sends the packet, will it send it with the correct L2 frame
size? (i.e. equal to the L3 packet length)
If so, what will it put at the end of the packet?
Will it clear those bytes?

If it doesn't, then it might send stuff from a previous transmission.

Note that the inverse case, where L3.length < L2.length is also interesting,
because if forwarded according to L2.length, then there is a covert channel
opportunity.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Mark Smith <[email-masked]>
Date: Wed, 5 Feb 2020 01:13:43 +1100

> Yes, I agree that it will get discarded.  Maybe... Probably?

The upper transport layer checksum catches it at the destination because
the transport layer payload has been truncated at the fault point.

> If it doesn't, then it might send stuff from a previous transmission.

Probably. Those bytes cause the transport layer checksum to fail.

That is a potential information leak, which is why you shouldn't trust the
network and you should encrypt at least your transport layer payloads.

> because if forwarded according to L2.length, then there is a covert channel

Yes it would be.

Who polices Ethernet padding bytes being all zeros?

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 5 Feb 2020 11:40:38 +1300

> In this case the packet is *not* larger than the MTU of the outgoing link. Rather a packet has been received (or possibly generated locally) with an IPv6 payload length greater than the link layer…

'generated locally' would surely be a coding bug (probably in the socket API), since such a case should simply be impossible. Either the packet would have been fragmented or IPV6_DONTFRAG is set and the send() will fail. In any case it wouldn't be a protocol issue.

> Probably this packet should not be forwarded. However, I couldn't find anything to say that it's invalid.

I don't see a fast-path switch checking for this condition, so I think it can only be detected at the final destination, as others have said. But it seems like an implementation issue, not part of a protocol spec.

   Brian

>> On Mon, Feb 3, 2020 at 7:31 AM Aitken, Paul <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     [email-masked] <mailto:[email-masked]>
>>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=ZfTZz_O9E1tN4KFtMYO2ZkKk5U5-6SlI-21vZEhzDuU&m=qBignlV2D2HjQ1OG98CXIFMbZryHbieyfesxKE4ZOfg&s=Hcp5fCXJd8pXcMtmqOUaw179roZQXSQntvE-zFdQYbY&e=>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 4 Feb 2020 18:04:11 -0500

I am not sure I understand the situation.

Let us ignore the locally generated case, as that requires sseveral 
really strange errors.

You seem to be describing a case where a node N receives an IPv6 packet 
with a claimed IPv6 length longer than the actual received packet.  This 
implies someone else making some sort of error, but errors do happen.

It certainly seems that this packet needs to be dropped.  Otherwise, one 
will end up in a situation where the IP forward code tries to send a 
packet whose IP length is longer than the buffer it is attempting to 
send.  It better not do that.

Whether it checks on receive or send seems to be an implementation choice.

Yours,
Joel

---

From: Mark Smith <[email-masked]>
Date: Wed, 5 Feb 2020 10:14:12 +1100

On Tue, 4 Feb 2020, 19:40 Mark Smith, <[email-masked]> wrote:

>> In this case the packet is *not* larger than the MTU of the outgoing
>> link. Rather a packet has been received (or possibly generated locally)
>> with an IPv6 payload length greater than the link layer frame size.
>>
> These packets with this fault are going to be rare. Checking each and
> every packet for this rare problem at each forwarding hop would impact
> forwarding performance.
>

Thinking a bit more, they'll be rare at forwarding nodes.

However as Brian said it would be a bug at the API layer or below on the
sending node. Either the outgoing MTU vs. the packet size check failed to
occur correctly, or that check passed and then something broke within the
link layer encapsulation.

That would probably mean most if not all packets emitted by this node on
this interface would be effected by the bug, making it obvious where the
fault is occurring. Signs would be high or entire packet loss from this
node, and application connection failures visible to the end-user.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 6 Feb 2020 11:55:35 -0300

Hello, Aitken,

> 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: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 10 Feb 2020 00:17:41 -0500

> packet (provided it is not a multicast address).

  Agreed their is not any check in the IPv6 module for link layer MTU size
comparison to Layer 3 MTU.

>From a physical standpoint of the packet the last encapsulation before the
packet is transmitted onto the wire is the link layer Ethernet
encapsulation of 14 bytes + CRC 26 bytes.  So the IPv6 MTU would be 1500
and the link layer MTU after the final L2 encapsulation is done would be
1500+ 26 = 1526

Since the link layer encapsulation is the final encapsulation before the
packet is placed on the wire it is impossible for the IPv6 L3 MTU to be
greater then the link layer Ethernet encapsulation MTU.  This is for non
Jumbo but even for Jumbo frames L3 MTU greater then 1500 this would apply
as well.  If the outgoing interface L3 MTU is less then the packets L3 MTU
a ICMPv6 type 2 code 0 Packet to big would be sent back to the source.

-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]