Subject: Re: draft-ietf-6man-slaac-renum: Honoring small Lifetime values

From: Fernando Gont <[email-masked]>
Date: Tue, 1 Sep 2020 01:37:31 -0300

Hi, David,

Thanks for your further input! In-line....

On 27/8/20 17:42, David Farmer wrote:
> 
> 
> On Thu, Aug 27, 2020 at 11:28 AM Fernando Gont <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hello, David,
> 
>     On 27/8/20 12:46, David Farmer wrote:
>     [....]
>      >
>      > Why isn't setting the Preferred Lifetime = 0 sufficient to
>     deprecate a
>      > PIO? Any new sessions will stop using that prefix and current TCP
>      > sessions will timeout eventually. Why is it necessary for
>     sessions to
>      > terminate immediately when the PIO is deprecated? Is there some
>      > advantage I'm not seeing? I don't see these questions answered in
>     the
>      > drafts.
> 
>     What the change means is that, if a router is in a position to
>     positively know that the prefix is gone, it *can* signal that condition.
> 
>     Leaving addresses lying around doesn't come for free. e.g., you cannot
>     communicate with the new owner of the address. Besides, there are
>     implementations that enforce a limit on the maximum number of
>     configured
>     addresses.
> 
>     That's the main thing. Now, if you ask me, I also think that if the
>     addresses are known to fail, it is better to terminate connections and
>     resume them afterwards. TCP timeouts can be particularly long, at which
>     point the user experience is not really good.
> 
> 
> Ok, then someplace in this group of drafts please explicitly address why 
> the current mechanism of deprecation, PL=0, is not sufficient and the 
> change of allowing hosts to accept VL = 0 is necessary, or at least the 
> advantages of accepting VL=0 over only PL=0.  Currently, you acknowledge 
> that hosts can act on PL=0, but I see nothing about why this is 
> insufficient or even what advantages accepting VL=0 will additionally 
> provide.

Fair enough. Question for you: Do you think a reference to Section 2.3 
of https://tools.ietf.org/html/draft-ietf-v6ops-slaac-renum-03 would do?
And (if necessary) maybe add an additional sentence to such Section of 
draft-ietf-v6ops-slaac-renum regarding the limit on the number of 
configured addresses enforced by most implementations.

>      > Now, imagine the following misconfiguration; A network with two
>      > routers, RTR A and RTR B. The routers each advertises two PIOs, for
>      > Prefix A and Prefix B, but each with different time out values.
>     RTR A
>      > advertises Prefix A with Preferred Lifetime = 45 minutes and a Valid
>      > Lifetime = 90 minutes and Prefix B with Preferred Lifetime = 0
>     minutes
>      > and a Valid Lifetime = 0 minutes. And, RTR B advertises Prefix A
>     with
>      > Preferred Lifetime = 0 minutes and a Valid Lifetime = 0 minutes and
>      > Prefix B with Preferred Lifetime = 45 minutes and a Valid
>     Lifetime = 90
>      > minutes.
>      >
[....]
> 
>     The real solution to this is RFC8028. As soon as you employ multiple
>     routers/prefixes on a single subnet, if you don't have RFC8028, you are
>     asking for problems.
> 
[....]
> 
> I'm sorry, but RFC8028 won't address this, at least as currently 
> specified. Again this is a perverse misconfiguration of the PIOs, where 
> each router is saying, I'm right and the other router is explicitly 
> wrong.

That's what at least Radia Perlman calls "Byzantine failures". 
Unfortunately, ND is not robust in the presence of Byzantine failures. 
If routers on the local network segment start advertising incorrect 
information, things will fail, one way or another.

> The routing problem you are talking about, that RFC8028 intends 
> to resolve, may or may not actually exist, because it involves both 
> routing and filtering of traffic, without the filtering of some kind the 
> routing problem doesn't exist.

Well... BCP38 is a BCP....

> For this situation to occur the routers, or the person managing them, 
> needs explicit knowledge of the existence of the other router, and the 
> PIO the other router is advertising. In the intended scenario that 
> RFC8028 resolves, the two routers and the people managing them 
> probably have no knowledge of, or even cares about, the existence of the 
> other router.

The idea behind RFC8028 is that SLAAC information is more or less 
"per-router" information rather than "global". That's essentially the 
only way in which multi-router/multi-prefix networks can reliably work.

> For something like this misconfiguration to occur, I expect it needs 
> manual intervention, probably in some kind of failed or misguided manual 
> renumber attempt, probably in an enterprise network.

At which point, it's virtually impossible to differentiate that from an 
outright attack -- the only difference possibly being "intent" -- but of 
course we cannot tell that from the btis and bytes...

> In that case, both 
> routers could conceivably deliver the traffic if the hosts were to 
> configure both prefixes as would currently occur.

If and only if RAs were advertised frequently enough (and not lost) for 
them to be refreshed in less than two hours. RFC7772 allows for periods 
longer than that.

> You seem to be 
> focusing only on CPE and ISPs scenarios, but changing SLAAC affects all 
> hosts whatever kind of network scenarios they are part of and their 
> particular quirks.

Not really. This changes do have in mind general scenarios.

> I don't think this perverse misconfiguration by itself is a sufficient 
> reason to not make the change you are proposing, but we need to try to 
> think of all the corner case scenarios, be they perverse or 
> simple misconfigurations, where this change could have bad results. Are 
> there other corner case scenarios that should be considered?

As noted above, similarly to the case where one considers the possible 
usage of this feature for attack, I think one should consider the 
resilience/failure properties of ND. Put another way: Can ND cope with 
node/routers sending incorrect information? And, if not, is there any 
reason for considering one particular case as "special"?

FWIW, note that we are allowing nodes to react to this signal. If a 
router doesn't know better, it won't send such RAs.

> I was thinking of another scenario, what if you were unplugging one 
> interface to move it to a new network and then plugging a new interface 
> into the old network. This is a flash renumbering scenario where you 
> don't want to deprecate the PIOs, but the router isn't going to have 
> knowledge of the change nor any reason to send a PL=0 or VL=0, so this 
> change is mute in that scenario.

 From the POV of the host, addresses configured on the old interface 
should time out (of course, the interface won't receive any RA with 
VL/PL=0).

If you were referring to router interfaces being connected/disconnected, 
then what I mentioned above comes to play: it's up to the router to send 
the correct signal to the network, or not send any signal at all.

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