Errata for RFC4862

[Mark Smith <[e-mail]>]

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.