Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

[Owen DeLong <[e-mail]>]

> On Oct 31, 2019, at 12:34 PM, Ted Lemon <[e-mail]> wrote:
> 
> On Oct 31, 2019, at 3:21 PM, Fernando Gont <[e-mail] <mailto:[e-mail]>> wrote:
>> On 27/10/19 09:02, Ted Lemon wrote:
>>> Indeed, this would also not actually solve the problem.   At present,
>>> the ISPs are doing something that is out of spec and causes problems.
>>> If we “fix” this by accommodating what they do, does that help, or
>>> does it just encourage them to continue doing it?
>> 
>> Did happy eyeballs encourage broken IPv6 connectivity, or did it
>> actually help IPv6 deployment?
> 
> Don’t get me wrong—I’m not saying we shouldn’t do things to improve the situation.   I am saying that we should be strategic about it.
> 
>>> What should be happening on the host with a prefix that’s deprecated
>>> is that TCP connections should be timing out.   This doesn’t take
>>> very long.  
>> 
>> ~9 minutes, IIRC.
> 
> Should be 90 seconds.

That’s for the three-way handshake… For an existing established flow, it can be much MUCH longer.

> 
> 
>>> And if there is a new prefix being advertised on the
>>> link, that address should have a valid lifetime newer than the old
>>> prefix, meaning that the next TCP connection should come from that
>>> new prefix, not the old one.
>> 
>> That's not correct. Neither the Valid Lifetime nor the Preferred
>> Lifetime affect address selection.
> 
> Okay, there’s something to fix.  Why would these not affect source address selection?

Because there are other things that do which are much better reasons for address selection.

There are enough problems with address selection (especially on platforms like MacOS
where they’ve chosen to eliminate the ability to configure SAS) as it is. Adding this as an
additional variable (let alone making it override the other tie-breakers) is not, IMHO, an
actual improvement.

>>> I think Fernando’s plan to shorten some timers makes sense, but
>>> shortening the minimum really doesn’t—it just opens up an opportunity
>>> for an easy DoS, since I can now just send out death packets to the
>>> local network and break everything all at once.
>> 
>> The reality with ND attacks are (modulo sanity checks on the packets):
>> you enforce FHS, or you don't.
> 
> What is “FHS”?

First Hop Security (e.g. RA Guard, SEND, etc.)

>>> If you Really Really want to be able to have the routers send out RAs
>>> that deprecate the default route, and, as Mark is saying here, to
>>> upgrade millions or perhaps billions of hosts, why not ask for
>>> something that’s a real improvement?
>> 
>> Every piece helps.
> 
> Right, but if the effort involved in two different options differs by epsilon, you should always choose the option that produces the better outcome, shouldn’t you?

Yes, but the better outcome must be defined not only in terms of the ideal end result if/when implemented, but also in terms of the probability of widespread implementation and the time delay between now and said wide deployment.

>>> Second, fix RA so that it’s
>>> non-repudiable by a device that doesn’t have the secret key.
>>> 
>>> SEND does this, sort of.  Nobody uses SEND because it tries to solve
>>> a too-big problem and does it using obsolete technology.   But the
>>> basic idea is good: include a public key in every RA that can be used
>>> to validate that the RA was signed with the corresponding private
>>> key.
>> 
>> What's the practical difference between that, an a network that supports
>> RA-Guard?
> 
> On a network that supports RA guard, there probably is no difference, but RA guard on some networks, as we’ve discussed in the past, will actually make the network not work.   RA guard requires an active administrator.   So the CPE case we’re talking about isn’t relevant.

RA Guard as implemented today in most existing platforms requires an active administrator.

RA Guard could be default configured on switches with particular default “plug router in here” (uplink) ports, eliminating the need for an active administrator. This could be a useful specification in the HomeNet documents, perhaps.

>>> When another RA arrives, see if it was signed with the same key.   If
>>> so, it came from the same router, and can be trusted to update
>>> whatever information that router sent, including flash-deprecating a
>>> prefix.   If not, ignore it.
>> 
>> In the non-SEND trust model, you do trust the local router. Why did you
>> trust the local router to configure your network, but not for
>> deprecating the prefix?
> 
> In the non-SEND trust model, you trust the local network.   You hope that the RA you get “from the router” is actually from the router.

That doesn’t answer the question. It merely describes the model. The question was why is bind trust in a prefix deprecation message any worse than blind trust in a network configuration message.

Owen