Subject: Errata for RFC4862

From: Mark Smith <[email-masked]>
Date: Sun, 8 Jan 2017 16:30:04 +1100

Hi,

I've struggled with the Errata tool complaining about not having line
breaks at 72 characters for the last 15 or so minutes, and after
making number of failed attempts to fix that, that's enough!

Section:

5.5.3 RouterAdvertisement Processing

Original Text:

      1.  If the received Valid Lifetime is greater than 2 hours or
          greater than RemainingLifetime, set the valid lifetime of the
          corresponding address to the advertised Valid Lifetime.

      2.  If RemainingLifetime is less than or equal to 2 hours, ignore
          the Prefix Information option with regards to the valid
          lifetime, unless the Router Advertisement from which this
          option was obtained has been authenticated (e.g., via Secure
          Neighbor Discovery [RFC3971]).  If the Router Advertisement
          was authenticated, the valid lifetime of the corresponding
          address should be set to the Valid Lifetime in the received
          option.

      3.  Otherwise, reset the valid lifetime of the corresponding
          address to 2 hours.

Corrected Text:

1. If the Router Advertisement is not authenticated (e.g., via Secure
Neighbor Discovery [RFC3971]), and if the received Valid Lifetime is greater
than 2 hours, set the valid lifetime of the corresponding address to the
advertised Valid Lifetime.

2. If the Router Advertisement has been authenticated (e.g., via Secure
Neighbor Discovery [RFC3971]), the valid lifetime of the corresponding
address should be set to the Valid Lifetime in the received option
(regardless of whether it is greater than 2 hours or not).

3.  Otherwise, reset the valid lifetime of the corresponding address to 2
hours.

In other words, unless an RA is authenticated, Valid Lifetimes in RA PIOs
MUST be greater than 2 hours.

Notes:

For unauthenticated RAs, throughout the text there are numerous checks
to prevent a possible DoS attack described in the subsequent
paragraph:

"The above rules address a specific denial-of-service attack in
      which a bogus advertisement could contain prefixes with very small
      Valid Lifetimes."

Check 1 above would seem to allow a Valid Lifetime in an RA PIO that
is much less than 2 hours, as long as the value is greater than the
RemainingLifetime. For example, if a host's RemainingLifetime for an
address is 60 seconds, an RA PIO ValidLifetime of 61 seconds would be
acceptable. This would seem to contradict the DoS protection goal.

Check 2 does check to ensure that RemainingLifetime is greater than 2
hours, however Check 1 has
already accepted the RA PIO VL <2 hours (if greater than
RemainingLifetime) and set the address's Valid
Lifetime to a value possibly much less than 2 hours.

An attacker could take advantage of this by doing the following:

1. Send an initial RA with a ValidLifetime of 2 hours, which would pass Check 1.
2. Wait until around 1 hour and 59.5 minutes, and then send an RA with
a ValidLifetime of 61 seconds.
3. Send RAs every 30 or so seconds with a ValidLifetime of 61 seconds,
holding all of the victim hosts'
ValidLifetimes at a low value. These RAs would also pass Check 1 as
long as the VL in the RA was
greater than the hosts' current VL for the addresses.
4. When it could cause the most significant denial of service, stop
sending the RAs, causing the hosts'
address VLs and therefore the addresses to expire within 60 seconds or so.

Regards,
Mark.

---

From: [email-masked]
Date: Mon, 9 Jan 2017 09:53:20 +0100

Mark,

The current text is crafted both to allow renumbering and to support scenarios where the RA lifetimes are short. I.e. under two hours.
Your proposed changes appear to lock the lifetimes to no less than two hours. Is that correctly understood?

Btw, this might not be appropriate for an erratum, but I do also think we should revisit this behaviour. For the IPv6 core specifications to Internet standards work, I think the tentative conclusion was that we needed to do 4861/4862bis documents in-place before considering an advancement.

O.

> On 8 Jan 2017, at 06:30, Mark Smith <[email-masked]> wrote:
> 
> Hi,
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Fernando Gont <[email-masked]>
Date: Mon, 9 Jan 2017 08:36:55 -0300

On 01/09/2017 05:53 AM, [email-masked] wrote:
> 
> The current text is crafted both to allow renumbering and to support
> scenarios where the RA lifetimes are short. I.e. under two hours. 
> Btw, this might not be appropriate for an erratum, but I do also
> think we should revisit this behaviour. 

+1.

Note, however, that there are other values to be sanity-checked in a
similar way.

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

---

From: [email-masked]
Date: Mon, 9 Jan 2017 13:51:54 +0100

Fernando,

> Note, however, that there are other values to be sanity-checked in a

Quite possibly. For this particular one it is arguable of its value though.
If the attacker is controlling a node on a BMA link you have a problem regardless.

O.

---

From: 神明達哉 <[email-masked]>
Date: Mon, 9 Jan 2017 09:39:10 -0800

At Sun, 8 Jan 2017 16:30:04 +1100,

> a ValidLifetime of 61 seconds.

I guess the unstated assumption behind this defense of RFC4862 is that
at least some legitimate RA containing a PIO with a sufficiently long
valid lifetime updates the lifetime during this 1-hour-and-59.5-minute
period.  Of course, we cannot always assume this, but as I believe
everyone understands, this defense is supposed to be quite basic and
weak anyway, and does not intend to prevent all kinds of DoS attempt
by most sophisticated attackers under all possible circumstances.

In that sense the current text of RFC4862 actually does what it
intended to do with originally perceived limitations, so I don't see
the need for the proposed update.

At the very least I don't think this is an editorial error.  If we now
agree that the currently described defense is too weak, it should be
addressed as a protocol update to the RFC.

--
JINMEI, Tatuya

---

From: Mark Smith <[email-masked]>
Date: Tue, 10 Jan 2017 06:13:45 +1100

Hi Ole,

> The current text is crafted both to allow renumbering and to support scenarios where the RA lifetimes are short. I.e. under two hours.

Check/Rule 2 seems to be the only check/rule specifically permitting
less than 2 hours, but it is only doing so if the RA is authenticated.
So non-authenticated RAs with a Valid Lifetime of 2 hours should be
ignored. The text seems to be stating and enforcing this 2 hour
minimum a number of times:

 1.  If the received Valid Lifetime is greater than 2 hours, ... set
the valid lifetime of the
        corresponding address to the advertised Valid Lifetime.

2.  If RemainingLifetime is less than or equal to 2 hours, ignore
          the Prefix Information option with regards to the valid
          lifetime, unless the Router Advertisement from which this
          option was obtained has been authenticated ...

3.  Otherwise, reset the valid lifetime of the corresponding address to 2 hours.

Perhaps in the the first check/rule, it should have been an 'and'
rather than an 'or':

      1.  If the received Valid Lifetime is greater than 2 hours and
         greater than RemainingLifetime, set the valid lifetime of the
         corresponding address to the advertised Valid Lifetime.

Flipping the perspective around, if less than 2 hour Valid Lifetimes
are acceptable from non-authenticated RAs, then this set of 3
checks/rules could be much simpler and a single statement:

"If the received Valid Lifetime is greater than the RemainingLifetime,
reset the valid lifetime to the received Valid Lifetime."

However, I don't think that would protect against the DoS described.

> Your proposed changes appear to lock the lifetimes to no less than two hours. Is that correctly understood?

For unauthenticated RAs, yes. That would seem to be the solution to
the DoS attack mentioned.

where small seems to be viewed as < 2 hours by the previous check/rule text.

I've mentioned it because I believed where was a minimum VL in an RA
PIO of 2 hours for unauthenticated RAs, and have recently heard of an
ISP sending VLs of 1 hours. Those RAs should be failing the very first
> 2 hour check (the very first part of check/rule 1), however they're
not, and the receiving implementation is not using the VL correctly
(so there look to be two problems).

Regards,
Mark.

---

From: Tim Chown <[email-masked]>
Date: Tue, 10 Jan 2017 12:45:27 +0000

> On 9 Jan 2017, at 08:53, [email-masked] wrote:
> 
> Mark,
> 

Do you mean Preferred or Valid Lifetimes?

My recollection of running renumbering experiments is that it’s the Preferred Lifetime that matters, i.e. when that is set to zero for a prefix, the prefix is marked as deprecated.  So when renumbering, you run with two prefixes advertised, old and new, setting the Preferred Lifetime to 0 on the old prefix (even though the Valid Lifetime is set to 2+ hours), so that the address with the new prefix is used for newly initiated communications (as per RFC 6724, Rule 3).

Tim

---

From: 神明達哉 <[email-masked]>
Date: Tue, 10 Jan 2017 11:31:45 -0800

At Tue, 10 Jan 2017 12:45:27 +0000,
Tim Chown <[email-masked]> wrote:

> My recollection of running renumbering experiments is that it’s the
> Preferred Lifetime that matters, i.e. when that is set to zero for a
> prefix, the prefix is marked as deprecated.  So when renumbering,
> you run with two prefixes advertised, old and new, setting the
> Preferred Lifetime to 0 on the old prefix (even though the Valid
> Lifetime is set to 2+ hours), so that the address with the new
> prefix is used for newly initiated communications (as per RFC 6724,
> Rule 3).

Yes, but I guess what Ole tried to point out (which I agree with) is
that the valid lifetime will also have to decrease to 0 eventually,
and this original text of RFC4862 allows such decrease operation

--
JINMEI, Tatuya

---

From: Mark Smith <[email-masked]>
Date: Wed, 11 Jan 2017 08:45:48 +1100

On 11 Jan. 2017 6:32 am, "神明達哉" <[email-masked]> wrote:

If that is the case (and I don't think it is, it creates the DoS
opportunity that all other >2 hr checks attempt to defeat), then I think it
needs to be far better and more explicitly explained, including the
sequence of events.

What is the use case that can't be achieved by setting the preferred
lifetime to zero, immediately deprecating the addresses (and a VL of 2
hours to cause them to disappear shortly).

If it is to remove addresses immediately from a host by setting the RA PIO
VL to zero - actually that's not going to work, because seeing VL to zero
will fail the greater than remaining time check.

It would be very laborious to try to remove an address by only being able
to send a VL greater than the address's remaining time. Letting the address
age out/expire naturally by itself by stopping sending the RA PIO for the
prefix wolf be easier and I think quicker.

Regards,
Mark.

--
JINMEI, Tatuya

---

From: Tim Chown <[email-masked]>
Date: Thu, 12 Jan 2017 14:29:33 +0000

Hi Mark,

On 10 Jan 2017, at 21:45, Mark Smith <[email-masked]<mailto:[email-masked]>> wrote:

On 11 Jan. 2017 6:32 am, "神明達哉" <[email-masked]<mailto:[email-masked]>> wrote:
At Tue, 10 Jan 2017 12:45:27 +0000,

If that is the case (and I don't think it is, it creates the DoS opportunity that all other >2 hr checks attempt to defeat), then I think it needs to be far better and more explicitly explained, including the sequence of events.

What is the use case that can't be achieved by setting the preferred lifetime to zero, immediately deprecating the addresses (and a VL of 2 hours to cause them to disappear shortly).

If it is to remove addresses immediately from a host by setting the RA PIO VL to zero - actually that's not going to work, because seeing VL to zero will fail the greater than remaining time check.

It would be very laborious to try to remove an address by only being able to send a VL greater than the address's remaining time. Letting the address age out/expire naturally by itself by stopping sending the RA PIO for the prefix wolf be easier and I think quicker.

Yes, the process you describe is exactly what RFC 4192 recommends for renumbering, and which was tested on common OSes at the time that RFC was written. To begin the renumbering process, you run with PL 0 and VL 2hrs on the “old” prefix, and with normal values on the “new” prefix.  To transition to just the new prefix in use, you stop advertising the old prefix, such that addresses formed from it will become invalid and be removed, and during which time the address generated from the new prefix will be used due to RFC 6724 Rule 3.

So from that perspective, there’s no need to change RFC 4862 to allow an unauthenticated VL < 2hrs.

Tim

Regards,
Mark.

--
JINMEI, Tatuya

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