Re: Errata for RFC4862

[[e-mail]]

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 <[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
> --------------------------------------------------------------------