Subject: RFC2460 problem - error processing of Routing Header

From: OOTOMO Hiroyuki <[email-masked]>
Date: Tue, 18 May 2004 17:52:53 +0900

Hi, all.

I found a problem in RFC2460, about error processing of Routing Header.
It does not define the behavior of End Node when the End Node received
the packet which has odd Hdr.Ext.Len.

(Section 4.4)
>    A Routing header is not examined or processed until it reaches the
>    node identified in the Destination Address field of the IPv6 header.
>    In that node, dispatching on the Next Header field of the immediately
>    preceding header causes the Routing header module to be invoked,
>    which, in the case of Routing Type 0, performs the following
>    algorithm:
> 
>    if Segments Left = 0 {
>       proceed to process the next header in the packet, whose type is
>       identified by the Next Header field in the Routing header
>    }
>    else if Hdr Ext Len is odd {
>          send an ICMP Parameter Problem, Code 0, message to the Source
>          Address, pointing to the Hdr Ext Len field, and discard the
>          packet
>    }
<<< snip >>>

When the IPv6 packet with the Routing Header is as follows (example):

   [IPv6 Header]
      Source Address: host-0
      Destination Address: host-4
      Next Header: Routing Header
   [Routing Header]
      Next Header: ICMPv6
      Hdr.Ext.Len: 5
      Routing Type: 0
      Segment Left: 0
      Address: router-1
      Address: router-2
      Address: router-3
   [ICMPv6]
      ICMPv6 Echo Request

The Routing Header in this packet has Hdr.Ext.Len with invalid odd number
and Segment Left with 0.

RFC says that the End Node (host-4) will process the Next Header (ICMPv6),
but Hdr.Ext.Len has inaccurate value, so Host-4 does not have the way
to get the correct starting point of the Next Header.

   [Routing Header processing]
      Segment Left == 0
          -> goes to Next Header

   [Between the Routing Header and the Next Header (not defined)]
      Header Ext. Length == 5 (odd)
          -> discards the packet and transmits ICMP Parameter Problem?
          -> or seeks 5*8 = 40 octets without considering HdrExtLen is odd?
             (There is not the starting point of the Next Header.
              There is the middle of Address[3] in Routing Header.)

   [Next Header processing]
      (What will happen?)

I think that End Node should also check like Intermediate Node
that the Hdr.Ext.Len is not odd number, because Hdr.Ext.Len is
used by not only Intermediate Node but End Node.

So I propose to replace the first two items of the algorithm.

>    if Hdr Ext Len is odd {
>          send an ICMP Parameter Problem, Code 0, message to the Source
>          Address, pointing to the Hdr Ext Len field, and discard the
>          packet
>    }
>    else if Segments Left = 0 {
>       proceed to process the next header in the packet, whose type is
>       identified by the Next Header field in the Routing header
>    }

Thank you.

-- 
OOTOMO Hiroyuki <[email-masked]>
Gr. 1, Engeneering department 1, Development center, ATE headquarters
Yokogawa Electric Corporation
URL: http://www.yokogawa.com/

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

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 20 May 2004 00:43:29 -0400 (EDT)

Hi Ootomo,
  See comments inline.

Regards
Suresh

>The Routing Header in this packet has Hdr.Ext.Len with invalid odd number

This packet will NEVER reach host-4. Consider the packet when it 
reaches router-1

   [IPv6 Header]
      Source Address: host-0
      Destination Address: router-1
      Next Header: Routing Header
   [Routing Header]
      Next Header: ICMPv6
      Hdr.Ext.Len: 5
      Routing Type: 0
      Segment Left: 3
      Address: router-2
      Address: router-3
      Address: host-4
   [ICMPv6]
      ICMPv6 Echo Request
   
router-1 will follow the algorithm for RH processing. The Segments Left is 
greater than 0. So it will check the header ext len and find it to be odd. 
It will drop the packet and send an ICMP message back to host-0. I guess 
the general idea is that the first destination node will detect the 
problem with the header ext len.

<snipped>

---

From: OOTOMO Hiroyuki <[email-masked]>
Date: Thu, 20 May 2004 18:38:07 +0900

Hi Shresh.

> This packet will NEVER reach host-4. Consider the packet when it 
<<< snipped >>>
> problem with the header ext len.

Of course what you said is true, but it is the case
when the first destination node (and all intermediate nodes)
was normal.

What I said in previous mail is the case when the packet
reached to End Node unfortunately.

e.g., If all routers via which the packet goes have broken
(although it is a very rare case) and overlook the invalid
Hdr.Ext.Len, the trouble will happen.

e.g., If an evil node transmit the packet with odd Hdr.Ext.Len
and zero Segment Left suddenly, the trouble will happen.

Isn't it connected with other vulnerabilities and become
a security hole etc.?

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 20 May 2004 20:19:49 -0400 (EDT)

Hi Ootomo
	See comments inline.

Regards
Suresh

>Hdr.Ext.Len, the trouble will happen.

Even if we check the header length before checking the segments left we 
can still have a problem.

>and zero Segment Left suddenly, the trouble will happen.

The evil node can transmit the packet with an EVEN header ext len which is 
WRONG and the new algorithm can still not catch it. So I guess it is not 
worth it trying to change the algorithm as the cons outweigh the pros.

---

From: OOTOMO Hiroyuki <[email-masked]>
Date: Fri, 21 May 2004 19:07:45 +0900

Hi, Suresh.

> worth it trying to change the algorithm as the cons outweigh the pros.

I understand.
My proposal will solve a half of this problem,
but it will not clear the remaining half.
It was not a wonderful solution to deserve to correct RFC.

I will consider the better methods.

Thank you.