Subject: Updating RFC 2461

From: Loganaden Velvindron <[email-masked]>
Date: Fri, 27 Mar 2015 11:19:21 +0400

Dear All,

There has been some comment about this section of RFC 2461:

Validation of Router Advertisement Messages

   A node MUST silently discard any received Router Advertisement
   messages that do not satisfy all of the following validity checks:

      - IP Source Address is a link-local address.  Routers must use
        their link-local address as the source for Router Advertisement
        and Redirect messages so that hosts can uniquely identify
        routers.

      - The IP Hop Limit field has a value of 255, i.e., the packet
        could not possibly have been forwarded by a router.

There is an informational RFC (RFC 3756) which states that:

  As an example, one possible approach to mitigate this threat is to
   ignore very small hop limits.  The nodes could implement a
   configurable minimum hop limit, and ignore attempts to set it below
   said limit.

I would like to propose an update to RFC 2461 along this line:

The node MUST discard any received Router Advertisement with a hop
limit lower than the current hop limit of the interface.

This change is useful because I think that it would reflect what is
being implemented in practice, and MAY log the packet.

I welcome feedback.

//Kind regards,
//Logan
C-x-C-c

-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 27 Mar 2015 19:59:51 +1100

RFC 4861 updates 2461. Please have a look at 4861.

Thanks,
Hesham

-----Original Message-----
From: Loganaden Velvindron <[email-masked]>
Date: Friday, 27 March 2015 6:19 pm
To: <[email-masked]>
Subject: Updating RFC 2461

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

---

From: Loganaden Velvindron <[email-masked]>
Date: Fri, 27 Mar 2015 16:07:46 +0400

> RFC 4861 updates 2461. Please have a look at 4861.

Hi Hesham, Thank you for the pointer.

Quote:

Narten, et al.              Standards Track                    [Page 39]

RFC 4861               Neighbor Discovery in IPv6         September 2007

      - ICMP Checksum is valid.

      - ICMP Code is 0.

      - ICMP length (derived from the IP length) is 16 or more octets.

I propose an update to that section to include:

The node MUST discard any received Router Advertisement with a hop
limit lower than the current hop limit of the interface, and MAY log
the invalid Router Advertisement packet.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Mar 2015 08:05:13 -0500

Le 27/03/2015 07:07, Loganaden Velvindron a écrit :
> [earlier]

What was the use of this practice?  What kind of usecase?

I didnt know a hop limit was configured on an interface?  How can one 
see it?

I was thinking the packet's hop limit is decremented at each router, by 
1.  And if 0 is reached then packet gets dropped.  There is no 
decrementing by other amount than 1, and there is no other drop 
condition than 0.

Alex

---

From: Loganaden Velvindron <[email-masked]>
Date: Fri, 27 Mar 2015 17:48:50 +0400

> What was the use of this practice?  What kind of usecase?

Hi Alexendru,

In From RFC 3756:

4.2.7.  Parameter Spoofing

   IPv6 Router Advertisements contain a few parameters used by hosts
   when they send packets and to tell hosts whether or not they should
   perform stateful address configuration [2].  An attacking node could
   send out a valid-seeming Router Advertisement that duplicates the

Nikander, et al.             Informational                     [Page 16]

RFC 3756            IPv6 ND Trust Models and Threats            May 2004

   Router Advertisement from the legitimate default router, except the
   included parameters are designed to disrupt legitimate traffic.  This
   is a DoS attack.

   Specific attacks include:

   1.  The attacker includes a Current Hop Limit of one or another small
       number which the attacker knows will cause legitimate packets to
       be dropped before they reach their destination.

.....
   The threat discussed in this subsection involves Router Advertisement
   messages.

....

There are counter-measures being implemented in Linux and FreeBSD
concerning this vulnerability. However, it is not in the proposed
standard. With RFC 3756, it is suggested. I believe that we need
strong wording and an update to reflect current practice, and push for
other vendors to implement it.

>
> I didnt know a hop limit was configured on an interface?  How can one see
> it?

In implementations such as Linux, it's called an interface. Perhaps my
use of word is incorrect.

Perhaps something as :

The node MUST discard any received Router Advertisement with a hop
limit lower than the current hop limit, and MAY log
the invalid Router Advertisement message

might be better ?

>
> I was thinking the packet's hop limit is decremented at each router, by 1.
> And if 0 is reached then packet gets dropped.  There is no decrementing by
> other amount than 1, and there is no other drop condition than 0.
>
> Alex
>
>
>>
>>
>>
>>>

---

From: Bob Hinden <[email-masked]>
Date: Fri, 27 Mar 2015 10:13:01 -0500

Loganaden,

> On Mar 27, 2015, at 8:48 AM, Loganaden Velvindron <[email-masked]> wrote:
> 
> 
> 

I disagree.  The current standard where the hop limit is 255, keeps ND messages from being sent off link.  Changing to a smaller hop limit would create a whole new class of attacks.

Bob

---

From: 神明達哉 <[email-masked]>
Date: Fri, 27 Mar 2015 08:26:17 -0700

At Fri, 27 Mar 2015 10:13:01 -0500,
Bob Hinden <[email-masked]> wrote:

> I disagree.  The current standard where the hop limit is 255, keeps
> ND messages from being sent off link.  Changing to a smaller hop
> limit would create a whole new class of attacks.

I suspect this was about the "Cur Hop Limit" field of RAs:

      Cur Hop Limit  8-bit unsigned integer.  The default value that
                     should be placed in the Hop Count field of the IP
                     header for outgoing IP packets.  A value of zero
                     means unspecified (by this router).

I'm not sure if we want to include a specific validation on the
received value of Cur Hop Limit in the protocol specification.  I've
assumed that the general sense is that an on-link attacker can
generally perform various evil things (whose severity vary) and we
address a specific threat in the base protocol spec only when it's
considered to be too severe.  An example of this is the "too short a
valid lifetime attack".  In that sense, sending too small a Cur Hop
Limit value looks quite minor to me.

--
JINMEI, Tatuya

---

From: Loganaden Velvindron <[email-masked]>
Date: Fri, 27 Mar 2015 15:43:30 +0000

>                      means unspecified (by this router).

Hi Tatuya,

Indeed this is the current field, that I should have quoted in RFC 4861 !

> Limit value looks quite minor to me.

It is possible to cause a denial of service attack on a link-local
interface. A patch has been queued for inclusion in Linux:

http://www.spinics.net/lists/netdev/msg322361.html

I think that since we have running code, and and upcoming CVE, we
might want the standard to reflect what's currently happening in
production operating systems.

---

From: Jen Linkova <[email-masked]>
Date: Fri, 27 Mar 2015 20:21:13 +0100

On Fri, Mar 27, 2015 at 4:13 PM, Bob Hinden <[email-masked]> wrote:
> On Mar 27, 2015, at 8:48 AM, Loganaden Velvindron <[email-masked]>
> I disagree.  The current standard where the hop limit is 255, keeps ND
> messages from being sent off link.  Changing to a smaller hop limit would
> create a whole new class of attacks.

I think we are talking about two different things here. There is a
'Hop Limit' field in the IPv6 header of an ND packet, which must be
255 indeed. And there is a 'Current Hop Limit' field in an RA ("The
default value that should be placed in the Hop Count field of the IP
header for outgoing IP packets."

My understanding is the suggestion is to discard all RAs if its 'Cur
Hop Limit'  is less than a currently configured 'Hop Limit'.

IMHO 'MUST' is a bit strong statement. 'MAY' or 'SHOULD', probably...

AFAIK nothing requires a host to use the value specified in 'Cur Hop
Limit' - it's a default value if I'm not mistaken.
MacOS on my MacBook seems to use both '255' and '64' (advertized in
RAs) for outgoing packets.

-- 
SY, Jen Linkova aka Furry

---

From: Fernando Gont <[email-masked]>
Date: Fri, 27 Mar 2015 12:48:14 -0500

Hi, Loganaden,

> There has been some comment about this section of RFC 2461:

RFC2461 was obsoleted years ago by RFC4861. Please take a look at
RFC4861 and see if your comments still apply.

Thanks!

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

---

From: Loganaden Velvindron <[email-masked]>
Date: Fri, 27 Mar 2015 19:45:50 +0000

> RFC4861 and see if your comments still apply.

Hi Ferdando,

I checked, and the issue is still present.

---

From: Loganaden Velvindron <[email-masked]>
Date: Sat, 28 Mar 2015 05:58:39 +0000

On Fri, Mar 27, 2015 at 7:13 PM, Erik Nordmark <[email-masked]> wrote:
> On 3/27/15 7:07 AM, Loganaden Velvindron wrote:
>>
> If we are going to change this I'd suggest not discarding the RA, but
> instead ignoring the hop limit value if it is less than the current hop
> limit on the interface (thus the hop limit in the RA can be used to increase
> the hop limit but never to decrease it).
>
>    Erik
>

Hi Erik, I think that's a sensible proposal.

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 27 Mar 2015 14:13:32 -0500

If we are going to change this I'd suggest not discarding the RA, but 
instead ignoring the hop limit value if it is less than the current hop 
limit on the interface (thus the hop limit in the RA can be used to 
increase the hop limit but never to decrease it).

    Erik

---

From: 神明達哉 <[email-masked]>
Date: Mon, 30 Mar 2015 09:50:57 -0700

At Fri, 27 Mar 2015 15:43:30 +0000,

> production operating systems.

The "denial of service attack" in this case is to make a certain set
of off-link destinations unreachable, right?  If I were an attacker, I
could achieve that goal by sending RAs with valid routers's source
addresses and with the router lifetime being 0.  So, again personally,
I'm not really convinced whether we need this "defense" in the first
place - if we really want to avoid this class of "attacks" (which are
annoying but relatively minor and can only be done by an on-link
attacker - although I can imagine some cases where it can really
matter), I'd rather rely on a more comprehensive measure such as SEND
or RA guard, depending on requirement details (whether it has to work
perfectly even if hard to deploy, or we need something reasonably
workable and deployable).  And so I personally don't buy then argument
that we need to tweak the protocol just because some implementors
wanted to do something deviant.

--
JINMEI, Tatuya

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 31 Mar 2015 08:55:39 +1100

+1

Hesham

-----Original Message-----
From: 神明達哉 <[email-masked]>
Date: Tuesday, 31 March 2015 3:50 am
To: Loganaden Velvindron <[email-masked]>
Cc: Bob Hinden <[email-masked]>, Alexandru Petrescu
<[email-masked]>, IPv6 List <[email-masked]>
Subject: Re: Updating RFC 4861