Re: A common problem with SLAAC in "renumbering" scenarios

[Fernando Gont <[e-mail]>]

On 3/2/19 12:26, Ole Troan wrote:
>>>>
>>>> Well, the problem is that you are making a contract on the LAN side for
>>>> a contract you may not have on the WAN side. If the router reboots and
>>>> the CEP no longer "owns" some prefix, then that contract is void.
>>>
>>> You have the contract on the WAN side. What makes you think not. E.g via PD learns that given prefix is valid until March 1 2020.
>>> A reboot doesn’t change that. 
>>>
>>>> Ideally, the CPE will advertise that the contract is void. But it is
>>>> clear that for most deployed CPEs, that will not happen.
>>>
>>> So a bug. 
>>> What you are talking about is the case where the ISP breaks the contract. While it previously promised to delegate you a prefix until 20200301, all trace of that has gone. 
>>
>> The CPE is the middle-man between the ISP and the LAN. No matter what
>> you may *expect* the CPE to do, the CPE is currently not actually
>> required to e.g. clean after the contract that the ISP broke (if you
>> assume/think there's such a thing), or even adjust prefix timers
>> according to the DHCPv6 lease times -- talk about under-specification of
>> the glue between e.g. DHCPv6-PD and SLAAC.
> 
> RFC3633:
>    Each prefix has an associated valid and preferred lifetime, which
>    constitutes an agreement about the length of time over which the
>    requesting router is allowed to use the prefix.  A requesting router
>    can request an extension of the lifetimes on a delegated prefix and
>    is required to terminate the use of a delegated prefix if the valid
>    lifetime of the prefix expires.
> 
> This really isn’t hard.

It's not hard. But it just doesn't happen in crash-and-reboot scenarios
for most CPEs nowadays.



>> Besides, the layer-8 contract between the user and the ISP may be that
>> you get dynamic prefixes. This means that whenever you request a lease,
>> you get a different prefix. You might say that if you don't do another
>> DHCPv6-PD request, you should be able to use the same prefix. But if you
>> do ask a new prefix, you might indeed get a new one -- and this is what
>> normally happens after reboots.
> 
> Not normally. That’s ISP allocation policy.
> And not recommended.

The RIPE document does not recommend it. In Germany, that's the expected
default.

At the end of the day, it's a policy.



> But sure a correctly behaving DHCP PD implementation will include the current prefixes in it’s request message.

But they may just not know what they were (unless the previously-leased
prefix was recorded on stable storage). Or the DHCPv6 server might lease
something else.



>>>>> What you seem to be talking about is either a bug a misconfiguration or both. 
>>>>
>>>> It's neither of those. If anything, it's the result of
>>>> under-specification of the necessary glue between automatic
>>>> configuration on the WAN side, and automatic configuration on the LAN side.
>>>>
>>>> e.g., there were no requirements for CPEs to keep track of prefixes that
>>>> they have been leased in the past -- if at all possible.
>>>
>>> DHCP PD will give you the old prefix back. 
>>
>> Not necessarily. In fact, it may intentionally not do that. If you no
>> longer own the addresses, the sessions will have to be torn down.
> 
> That’s not how IPv6 addressing and renumbering is intended to work.
> I take it your goal isn’t to change that, but to improve the situation where it unfortunately happens.

Exactly. We are trying to improve the situation when that happens. If
possible, we'd like the situation to be avoided -- e.g., if you want
dynamic prefixes, do so in an ordered way.

But since we cannot rely on others behaving nicely, we want to make
hosts more robust to these scenarios.



> (Which of course might encourage ISPs to do just that.)
> 
>>>>> If you want something like session survivability,
>>>>> that’s not a trivial problem to solve.
>>>>
>>>> Not sure what you mean by "session survivability"
>>>
>>> Try to keep a TCP session active while changing addresses. 
>>
>> Of course that's not what we're trying to solve here.
> 
> No, but it is important to understand the implications of your work.

Not sure what you mean. You mean the goal its not clearly stated?
Something else?




>>>>> Currently the network will give an ICMP destination unreachable code 5 and deprecate the invalid prefix if it has information to do so.
>>>>
>>>> Where in RFC4443 do ICMP unreach code 5 get to invalidate prefixes?
>>>>
>>>> Answer: Nowhere. They don't get to do that. All ICMPv6 error messages
>>>> are soft errors. And it would be a huge mistake (and huge
>>>> vulnerability!) to behave otherwise.
>>>
>>> It’s a strong hint to the host stack to pick a different source address. 
>>
>> You said "deprecate the invalid prefix if it has information to do so."
>> -- selecting a different address is a very different thing than
>> deprecating an address. In fact, for connection-less protocols that
>> might not even make sense -- since it implies resending stuff that you
>> might not even be able to resend (send buffer is gone).
> 
> No, I didn’t say that.
> I said the network will deprecate the prefix if it has information to do. I.e. send a PIO with preferred lifetime = 0.

Who would be sending that, and in response to what?



> And that the network will respond with a type 5 destination unreachable, if an invalid source address is used. See BCP38.

Again: does this happen *in practice*?

Besides:
fgont@laptop:~$ curl -s https://tools.ietf.org/rfc/bcp/bcp38.txt | grep
-P '(icmp|ICMP)'
   Similar attacks have been attempted using UDP and ICMP flooding.
   domain to reach their systems. The latter attack (ICMP flooding),



>> Besides,
>>
>> * You are assuming somebody will send an ICMPs. But they may not.
> 
> Is it interesting discussion assumptions that aren’t part of the specifications?
> 
>>
>> * You are assuming that if they do, they will send code 5. But they may not.
> 
> See above.
> 
>>
>> * You are assuming that code 5 is an indication of wrong address... but
>> it may be an indication of incorrect route.
> 
> No.

If the address failed ingress/egress policy you may have picked the
wrong address or e.g. default route.




>> * You are assuming that nodes will process icmp code 5 in one specific
>> way. I don't know of any implementation that behaves in the way you
>> describe.
> 
> Hosts can improve.
> My point was that it isn’t obivous that very much more can be done from the network side.

CPEs can be required to advertise previously-advertised prefixes that
are not valid anymore. And hosts can be improved so that they can detect
that a prefix is no longer advertised, and hence shouldn't be used --
or, at the very least, should no longer be preferred.




>> One (more complex) way to achive this would be to e.g., wait for N *
>> ROUTE_ADV_INTERVAL (I've just made up the parameter name), and if at
>> least M RAs with PIOs have been received, but none of them contain PIOs
>> for the (now invalid) prefix, deprecate the prefix.
>>
>> The solution we currently propose in the I-D is simpler, and just
>> involves one additional bit per prefix in the local data structures.
>>
>> For a sample scenario, please check Appendix B of our draft. THe idea is
>> simple: if two consecutive RAs with PIOs don't contain the
>> previously-advertised prefix, un-prefer addresses for such prefix.
>> Subsequently, once addresses have already been un-preferred, if you
>> receive two additional RAs with PIOs that don't advertise the
>> previously-advertised prefix, remove (invalidate) the corresponding
>> addresses.
>>
>> So, after two RAs, the lagging addresses are not preferred anymore.
>> After four RAs, you get rid of them.
> 
> So the proposal is that an address is marked as not preferred after anywhere between 6 and 20 minutes?

No. It is marked as not preferred in less than one minute (RFC4861):

   For the first few advertisements (up to
   MAX_INITIAL_RTR_ADVERTISEMENTS) sent from an interface when it
   becomes an advertising interface, if the randomly chosen interval is
   greater than MAX_INITIAL_RTR_ADVERT_INTERVAL, the timer SHOULD be set
   to MAX_INITIAL_RTR_ADVERT_INTERVAL instead.  Using a smaller interval
   for the initial advertisements increases the likelihood of a router
   being discovered quickly when it first becomes available, in the
   presence of possible packet loss.



> I am not saying that we can’t and shouldn’t improve on SLAAC… but I think we can do better. And existing heuristics are better than this.

What are the existing heuristics? If there was such a thing, there
shouldn't be a problem in the first place.

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