Re: Errata for RFC4862

[Mark Smith <[e-mail]>]

Hi Ole,

On 9 January 2017 at 19:53,  <[e-mail]> wrote:
> 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.

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.

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

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.

> 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 <[e-mail]> wrote:
>>
>> 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.
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>