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

From: Fernando Gont <[email-masked]>
Date: Fri, 21 Aug 2020 12:11:07 -0300

Folks,

Any further input?

On 28/7/20 10:17, Fernando Gont wrote:
> Folks,
> 
> As discussed at the 6man meeting, and as suggested by the wg chairs, 
> I'll be starting separate threads to discuss each of the proposals that 
> we had in draft-gont-6man-slaac-renum.
> 
> This first one is discussed in 
> https://tools.ietf.org/html/draft-gont-6man-slaac-renum-08#section-4.2
> 
> RFC4862 requires hosts to essentially disregard small PIO lifetimes 
> (smaller than two hours). This was allegedly specified as such to 
> mitigate a possible attack vector. However, if since RAs are normally 
> not authenticated there are a plethora of other (non-mitigated) vectors 
> an attacker could use (send RAs with a Router Lifetime of 0, and many 
> others).
> 
> On the other hand, this prevents a router that positively knows that a 
> prefix has become stale from signalling this condition.
> 
> Section 4.2 of 
> https://tools.ietf.org/html/draft-gont-6man-slaac-renum-08#section-4.2 
> proposes an update to RFC4862 such that small PIO Valid lifetimes are 
> honored.
> 
> The specific text of the proposal is:
> 
> ---- cut here ----
> 4.2.  Honor Small PIO Valid Lifetimes
> 
>     The entire item "e)" (pp. 19-20) from Section 5.5.3 of [RFC4862] is
>     replaced with the following text:
> 
>        e) If the advertised prefix is equal to the prefix of an address
>        configured by stateless autoconfiguration in the list, the valid
>        lifetime and the preferred lifetime of the address should be
>        updated by processing the Valid Lifetime and the Preferred
>        Lifetime (respectively) in the received advertisement.
> 
>     NOTE:  "Processing" the Valid Lifetime and Preferred Lifetime
>        includes capping the received values as specified in Section 4.1.2
>        of this document.
> 
>     RATIONALE:
> 
>        *  This change allows hosts to react to the information provided
>           by a router that has positive knowledge that a prefix has
>           become invalid.
> 
>        *  Attacks aiming at disabling an advertised prefix via a Valid
>           Lifetime of 0 are not really more harmful than other attacks
>           that can be performed via forged RA messages, such as those
>           aiming at completely disabling a next-hop router via an RA that
>           advertises a Router Lifetime of 0, or performing a Denial of
>           Service (DoS) attack by advertising illegitimate prefixes via
>           PIOs.  In scenarios where RA-based attacks are of concern,
>           proper mitigations such as RA-Guard [RFC6105] [RFC7113] should
>           be implemented.
> ---- cut here ----
> 
> 
> The aforementioned change has already been committed to the Linux kernel.
> 
> Do you have any comments/thoughts about this one?
> 
> Thanks!
> 
> Cheers,

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 22 Aug 2020 01:26:10 +0900

Updating RFC 4862 section 5.5.3 along these lines SGTM.

On Tue, Jul 28, 2020 at 10:18 PM Fernando Gont <[email-masked]>
wrote:

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: 神明達哉 <[email-masked]>
Date: Fri, 21 Aug 2020 16:00:14 -0700

At Fri, 21 Aug 2020 12:11:07 -0300,

> Any further input?

I don't necessarily oppose the decision of removing the "two hour

> >           proper mitigations such as RA-Guard [RFC6105] [RFC7113] should

If I remember the original discussion to the two hour rule correctly,
it was already well understood that RA is not very secure anyway and
there are other attack vectors.  The two hour rule was still
introduced because "Attacks aiming at disabling an advertised prefix
via a Valid Lifetime of 0 are deemed to be more harmful than other
attacks".  Just denying that previous conclusion doesn't sound like a
strong rationale, given that it at least should have achieved rough
consensus (from the fact that it's actually in the RFC).  What I would
expect to see here is a discussion on "why" it's now considered not
really more harmful.

--
jinmei

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 22 Aug 2020 12:20:33 +1200

> expect to see here is a discussion on "why" it's now considered not

Isn't the solution to state that (absent RA-Guard) a host should rate-limit
the processing of such messages? And perhaps, a router should rate-limit
the sending of such messages. This would mitigate attacks and also any
sort of oscillating failure mode.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Fri, 21 Aug 2020 21:55:21 -0300

Hi, Jinmei,

Thanks a lot for your response! IN-line....

On 21/8/20 20:00, 神明達哉 wrote:
> attacks". 

Could you please elaborate why disabling a prefix would be more harmful 
than, e.g.

1) do a ND cache poisoning attack against the default router, or,

2) Advertise, RIOs (even if ::/1 and 8000::/1) pointing to a a local 
attack-operated one, or,

3) a DAD attack
?

Does honoring all lifetime values allow an attacker to cause any harm 
that would otherwise not be possible nowadays?

> Just denying that previous conclusion doesn't sound like a

FWIW, more than "denying the previous conclusion", I think we're doing a 
re-evaluation of the analysis.

FWIW, I wasn't part of the discussion that led to RFC4861, so I've never 
been able to understand why this particular vector would/should be 
considered more harmful -- hence my question above.

Thanks!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 21 Aug 2020 22:09:36 -0300

>> Fernando Gont <[email-masked]> wrote:
[...]
> sort of oscillating failure mode.

With SLAAC as currently specified, you trust your neighbors, or you 
don't. And since SLAAC is not only "pull" but also "push", theere's a 
continuous window of attack -- not just the timeframe during which the 
initial exchange happens, as with DHCPv6.

At the end of the day, and attacker just needs one vector that works. 
That's why I think that trying to mitigate only a specific one will not 
buy you anything in practice. And, OTOH, you prevent timely response 
from hosts when the router is in a position to signal it.

Regards,

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 22 Aug 2020 10:53:34 +0100

> expect to see here is a discussion on "why" it's now considered not

If the NH GW address is changed, then traffic can be hijacked.  If rogue 
RAs on a SLAAC-only network can be injected a with the M flag set, then 
DHCP can take over and do bad things. Or if a rogue RA can be injected 
with a rogue prefix, then that could also constitute a connectivity 
compromise.  All these things could be fatal, albeit in slightly 
different ways.

The core problem is that the ND spec states that hosts should treat all 
RAs as legitimate and outside SEND, there's no protocol level security, 
not even unauthenticated nonces / tokens. It may be that individual 
attacks are a little less or a little more harmful, but if your 
connectivity is compromised and your traffic is directed elsewhere, the 
distinction is academic.

Nick

---

From: Mark Smith <[email-masked]>
Date: Sun, 23 Aug 2020 13:09:23 +1000

> connectivity is compromised and your traffic is directed elsewhere, the

The core problem is that people are allowing unauthenticated and possibly
untrustworthy nodes to connect to mutual trust, any-to-any multiaccess
links without explicit permission (e.g., an enabled LAN port sitting there
that can be plugged into without permission, or a WiFi SSID password posted
on the wall).

ND assumes nodes are going to be good actors, which is also a fundamental
assumption in multi-access LAN technologies. Being able to send to any or
all of the nodes on a LAN segment is the fundamental and specific reason
LAN technologies were designed, overcoming a limitation of their
predecessor set of point-to-point links to attach nodes.

If you can't make the assumption that nodes are going to be good actors,
then multi-access LANs are the wrong link-layer type for the job.

Regards,
Mark.

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 23 Aug 2020 12:29:49 +0100

> then multi-access LANs are the wrong link-layer type for the job.

for better or worse, we're stuck both with shared l2 domains and 
inadequate means of securing them.

This is exacerbated by the relative complexity of ND + RA, which means 
that it's not easy and it's often not possible to implement functional 
filtering at the layer 2 data plane due to hardware limitations.  This 
is one of the reasons why throwing more functionality into ND is a poor 
idea.

Nick

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 23 Aug 2020 11:45:02 -0400

And that’s why most enterprises have adopted 802.1x for endpoint security.
Even in an any-any L2 trust model there is potential for rouge devices
being connected to the network ensuing havoc on the network that also may
not have all security patches.

> is one of the reasons why throwing more functionality into ND is a poor

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 23 Aug 2020 12:12:42 -0400

Fernando

For broadband users where you mentioned the the use cases in the v6ops
draft where the flash renumbering of PIO prefix can occur and hosts hang
onto old address due to default  maximums VL / PL 30 days and 7 days
respectively which impacts IPV6 access.  That’s the main premise for the 2
hour VL/PL.  I get it and that makes sense for broadband users use case.

Most providers use PD to delegate the prefix to the CPE and then the CPE
host has SLACC to its hosts directly connected wired or WIFI but there is
no coupling between WAN side renumbering event and the connected host SLAAC
prefix being sent to hosts.

What is the signaling mechanism if any so that when the PD WAN side
renumbering event happens that the slaac subnet changes its default maximum
VL/PL from 30 days and 7 days respectively down to 2 hours.  If we don’t
have one I think that maybe something to discuss so that we just don’t
ubiquitously change the default for all end hosts.

Sorry for my ignorance.

 Is the default VL/PL on a the router changing to 2 hours or is their a
signaling mechanism from the PD wan side to SLAAC to change only when a
renumbering event occurs.

There are two main buckets for end users which we have discussed in the
past “broadband” directly connected to the internet and “enterprise” users
where their is a any-any trust level and so in many cases even as I have
mentioned the RFC 4941 privacy extension is disabled as for operators host
tracking is a business imperative and not privacy where directly connected
to the internet privacy is most important.  The requirements as stated for
the two buckets are vastly different.

As there are two buckets of users or maybe more that I am missing, my worry
has always been a one size fits all approach for the renumbering event
issue and solution as it does not exist on enterprises as the address is
stable as PD is generally not deployed internally on corporate internal
networks.

I think with the 4941bis update to 2 days VL/PL is a significant
improvement for operators and can go back to keeping the privacy extension
enabled with the drastic reduction in deprecated addresses maintained and a
good balance for long lived connections as well if they exist.

I would like this renumbering draft standards update to account for every
use case out there.

Gyan

On Sun, Aug 23, 2020 at 11:45 AM Gyan Mishra <[email-masked]> wrote:

> And that’s why most enterprises have adopted 802.1x for endpoint
> security.  Even in an any-any L2 trust model there is potential for rouge
> devices being connected to the network ensuing havoc on the network that
> also may not have all security patches.
>
>

*Gyan Mishra*

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 23 Aug 2020 20:28:00 +0100

Gyan Mishra wrote on 23/08/2020 16:45:
> security.  Even in an any-any L2 trust model there is potential for 
> rouge devices being connected to the network ensuing havoc on the 
> network that also may not have all security patches.

802.1x doesn't protect a network from rogue ND injection - it just 
provides authenticated access control, which is a different problem 
space.  It won't stop someone from injecting rogue frames into a l2 
domain, even if it does give you the ability to authenticate where 
they're coming from.

Nick

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 23 Aug 2020 16:31:50 -0400

I believe as part of the 802.1x supplicant state machine is “machine
authentication” which would be windows hostname in AD however if the
machine authentication fails I believe you can script action to shutdown
the host port so then no more L2 injection.  That is usually how it’s
implemented so the rogues host that did not pass authentication are now
isolated off the network.   During that period of time prior to being
partitioned off the network the host can spew ND packets and that remains
unprotected gap.

I think Fernando had in the v6ops use case of 802.1x supplicant being
authenticated but then placed in quarantine and then once I quarantined if
a renumbering event happened the device would lose access.

Gyan

*Gyan Mishra*

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 24 Aug 2020 08:36:59 +1200

> domain, even if it does give you the ability to authenticate where 

Isn't that the point, though? Although knowing for sure who the sender
is doesn't stop the traffic, it does provide an out of band mechanism
for identifying and physically removing the offending box.

That led me to another thought. There seems to be a basic difference
between managed networks where 802.1x or other authentication methods
can be enforced, and offending systems can be traced, and unmanaged
networks (SOHO or public access) where BYOD is the rule and anything
can happen. Should the slaac-renum mitigations be different for the
two cases?

   Brian

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 23 Aug 2020 16:51:16 -0400

I completely agree with the management (aka enterprise other) and unmanaged
(SOHO or Public access) we don’t want a single bucket solution as the
requirements as well as tools available in each case is not the same.

*Gyan Mishra*

---

From: Fernando Gont <[email-masked]>
Date: Sun, 23 Aug 2020 17:44:02 -0300

Hi, Gyan,

I think you're confusing two unrelated issues:

1) default values for PIO PL/VL (*not* discussed in this thread)

2) Processing of RAs with PIOs that have a VL smaller than 2 hours.

Regarding #2 (the one being discussed in this thread), the current specs 
prevent hosts from reacting to such packets. So, if a local router is in 
a position to signal that a prefix has become invalid (via an RA with a 
PIO with VL=0), hosts will only reduce the VL to no less that 2 hours.

The default values are completely unrelated to this. i.e., no matter 
whether the default values are appropriate or not, #2 will prevent 
timely reaction from local hosts.

That's the specific mitigation being discussed in this thread.

Hope this helps.

Thanks!
Fernando

On 23/8/20 13:12, Gyan Mishra wrote:
> respectively which impacts IPV6 access.  That’s the main premise for the 
> 2 hour VL/PL.  I get it and that makes sense for broadband users use case.
> 
> host has SLACC to its hosts directly connected wired or WIFI but there 
> is no coupling between WAN side renumbering event and the connected host 
> SLAAC prefix being sent to hosts.
> 
> renumbering event happens that the slaac subnet changes its default 
> maximum VL/PL from 30 days and 7 days respectively down to 2 hours.  If 
> we don’t have one I think that maybe something to discuss so that we 
> just don’t ubiquitously change the default for all end hosts.
> 
> Sorry for my ignorance.
> 
> past “broadband” directly connected to the internet and “enterprise” 
> users where their is a any-any trust level and so in many cases even as 
> I have mentioned the RFC 4941 privacy extension is disabled as for 
> operators host tracking is a business imperative and not privacy where 
> directly connected to the internet privacy is most important.  The 
> requirements as stated for the two buckets are vastly different.
> 
> 
> As there are two buckets of users or maybe more that I am missing, my 
> worry has always been a one size fits all approach for the renumbering 
> event issue and solution as it does not exist on enterprises as the 
> address is stable as PD is generally not deployed internally on 
> corporate internal networks.
> 
> improvement for operators and can go back to keeping the privacy 
> extension enabled with the drastic reduction in deprecated addresses 
> maintained and a good balance for long lived connections as well if they 
> exist.
> 
> I would like this renumbering draft standards update to account for 
> every use case out there.
> 
> Gyan
> 
> On Sun, Aug 23, 2020 at 11:45 AM Gyan Mishra <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     On Sun, Aug 23, 2020 at 7:30 AM Nick Hilliard <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         [email-masked] <mailto:[email-masked]>
> 
>     /Network Solutions A//rchitect /
> 
>     /M 301 502-1347
>     13101 Columbia Pike
>     /Silver Spring, MD
> 
> 
> 
> 
> -- 
> 
> /Network Solutions A//rchitect /
> 
> /M 301 502-1347
> 13101 Columbia Pike
> /Silver Spring, MD
> 
>

---

From: Fernando Gont <[email-masked]>
Date: Sun, 23 Aug 2020 17:54:08 -0300

> for identifying and physically removing the offending box.

Still, that wouldn't prevent the attack, though.

> can happen. Should the slaac-renum mitigations be different for the

IMO, the crux of the issue is the trust model. Do you trust local nodes, 
or you don't?

If you do, then modulo basic sanity checks on packets, and enforcement 
of limits on data structures (both of which you should always do, no 
matter what), you trust ND packets (including RAs).

OTOH, if you don't trust local nodes... well... you do SEND, or you get 
rid of ND (manual configuration, static NC entries, etc.)

The discussion in this thread seems to boil down to whether one should 
be extra careful about one specific option of RA packets, whereas the 
same attack effect can be achieved with multiple other options that are 
still blindly trusted/honored.

Thanks,

---

From: Mark Smith <[email-masked]>
Date: Mon, 24 Aug 2020 07:12:55 +1000

> also may not have all security patches.

A potential rogue device is by definition a bad actor. Why are you allowing
it to connect as though and treating it like it is a good actor?

There is no requirement that all IPv6 hosts must be considered good actors
by default, and must be connected to a LAN where if they are a bad actor
they can disrupt others.

They are plenty of bad actor preventions that have been deployed at scale -
PPPoE, N:1 VLANs, Private VLANs, Q-in-Q isolation, Wifi Station Isolation.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 24 Aug 2020 11:11:10 +1200

On 24-Aug-20 08:54, Fernando Gont wrote:
...
> still blindly trusted/honored.

How about this:

"If the network does not use a technique that prevents malicious RA
packets being delivered and processed, a bad actor can exploit any
existing vulnerability. There is therefore no point in eliminating
a known vulnerability unless all others are also eliminated."

Or if that's not true, the document needs to say why.

    Brian

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 23 Aug 2020 19:15:48 -0400

Overall the question I posed was that Managed networks such as enterprises
have more tools at their fingertips to mitigate L2 rogue ND packets where
Unmanaged networks such as SOHO broadband or public hotspot users do not.

Any rogue device by definition would be considered a bad actor in any
managed network of which 802.1x is one mitigation technique as there are
others as you mentioned.

The bigger question which I posed is that managed networks such enterprises
do not have flash renumbering events as PD is not used as is used by
broadband carriers to delegate prefixes to customers.  Enterprises have
static dual stacking across the enterprise so the prefix is stable.

What are the side effects of the changes being proposed for managed
networks that do not require this change.

On Sun, Aug 23, 2020 at 5:13 PM Mark Smith <[email-masked]> wrote:

> A potential rogue device is by definition a bad actor. Why are you
> allowing it to connect as though and treating it like it is a good actor?
>

> They are plenty of bad actor preventions that have been deployed at scale
> - PPPoE, N:1 VLANs, Private VLANs, Q-in-Q isolation, Wifi Station Isolation.
>
>
>>
>> *M 301 502-134713101 Columbia Pike
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>*Silver
>> Spring, MD
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>
>>
>>
>>
>>
>
> --

*Gyan Mishra*

---

From: Fernando Gont <[email-masked]>
Date: Sun, 23 Aug 2020 17:55:37 -0300

On 23/8/20 17:51, Gyan Mishra wrote:
> 
> I completely agree with the management (aka enterprise other) and 
> unmanaged (SOHO or Public access) we don’t want a single bucket solution 
> as the requirements as well as tools available in each case is not the 
> same.

Could you spell out what are the different requirements for this 
particular case?  (Note: both sets of networks employ the same 
of-the-shelf ND)

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 23 Aug 2020 22:12:14 -0300

> a known vulnerability unless all others are also eliminated."

I'd like to stress that the trust model for the same protocol allows for 
similar attacks (i.e., same outcome).  i.e., removing vulnerabilities 
that do imply different trust models does make sense. OTOH, removing one 
particular vulnerability while leaving all others "in" in the same trust 
model, does not.

(i.e., obviously, it does make sense to mitigate e.g. RHTO while not 
addressing any ND issues...). This is obvious to all of us, but I 
wouldn't like the text to be interpreted in a different way :-)

Thoughts?

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 24 Aug 2020 15:20:30 +1200

> wouldn't like the text to be interpreted in a different way :-)

I agree. It sounds like a good general principle for threat analysis, in fact.

   Brian

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 24 Aug 2020 08:06:25 +0000

Hi Fernando, Hi all,
I have seen already a few times on this alias that: because ND has so many DoS attack vectors, then 1 more would not hurt.
It is a very wrong approach to security. We should try to cut the number of attack vectors under any opportunity. We should deep dive into details for every attack vector.
Hence, this type of generalization I do not like: if DAD is DoS vulnerable anyway then we could omit security analysis in relation to RA.

Hi Brian,
I have not understood how rate limiting could help against rogue router. Even 1 RA could poison Prefix List or Destination Cache on hosts.
IMHO: it is extremely critical for IPv6 to have security assistance from L2 (IEEE) in the form of RA-Guard. IPv6 is not capable to survive without help from L2 - this particular security hole has the size of "black hole".
Hence, we could assume that RA-guard is always present, then no problem with shorter timer.

Eduard
-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Fernando Gont
Sent: 22 августа 2020 г. 4:10
To: Brian E Carpenter <[email-masked]>; 神明達哉 <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-ietf-6man-slaac-renum: Honoring small Lifetime values

[...]
> 
> Isn't the solution to state that (absent RA-Guard) a host should 
> rate-limit the processing of such messages? And perhaps, a router 
> should rate-limit the sending of such messages. This would mitigate 
> attacks and also any sort of oscillating failure mode.

With SLAAC as currently specified, you trust your neighbors, or you don't. And since SLAAC is not only "pull" but also "push", theere's a continuous window of attack -- not just the timeframe during which the initial exchange happens, as with DHCPv6.

At the end of the day, and attacker just needs one vector that works. 
That's why I think that trying to mitigate only a specific one will not buy you anything in practice. And, OTOH, you prevent timely response from hosts when the router is in a position to signal it.

Regards,

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 24 Aug 2020 08:33:17 +0000

It is not a good security principle: "all or nothing".
It would create "chicken and egg problem":
we would not try to fix any security problem in ND because one fix would not protect from all attack vectors,
But we would never have any progress because we have refused to start.
IMHO: we need to look details and try to fix any attack vector that is possible to fix, even if it is not last one of particular type (DoS?).

PS: I do not believe that shortening PIO would create new attack vector. It is still the same "rogue RA", that is solved by IEEE "RA-Guard".
Ed/
-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: 24 августа 2020 г. 6:21
To: Fernando Gont <[email-masked]>; Nick Hilliard <[email-masked]>; Gyan Mishra <[email-masked]>
Cc: [email-masked]; 神明達哉 <[email-masked]>
Subject: Re: draft-ietf-6man-slaac-renum: Honoring small Lifetime values

On 24-Aug-20 13:12, Fernando Gont wrote:
>>> The discussion in this thread seems to boil down to whether one 
>>> should be extra careful about one specific option of RA packets, 
>>> whereas the same attack effect can be achieved with multiple other 
>>> options that are still blindly trusted/honored.
>>
>> How about this:
>>
>> existing vulnerability. There is therefore no point in eliminating a 
>> known vulnerability unless all others are also eliminated."
> 
> I'd like to stress that the trust model for the same protocol allows 
> for similar attacks (i.e., same outcome).  i.e., removing 
> vulnerabilities that do imply different trust models does make sense. 
> OTOH, removing one particular vulnerability while leaving all others 
> "in" in the same trust model, does not.
> 

   Brian

---

From: Mark Smith <[email-masked]>
Date: Mon, 24 Aug 2020 19:15:31 +1000

On Mon, 24 Aug 2020, 18:33 Vasilenko Eduard, <[email-masked]>
wrote:

> IMHO: we need to look details and try to fix any attack vector that is
> possible to fix, even if it is not last one of particular type (DoS?).
>

So the question is (and its always a good question to ask often) "What
problem are you trying to solve?"

Is it safely from good actor implementation bugs and accidental actions?

Or is it security from bad actors who have malicious intent?

Confusing safety with security can mean declaring safety measures failures
because they don't adequately provide security - which they were never
intended to.

> PS: I do not believe that shortening PIO would create new attack vector.
> It is still the same "rogue RA", that is solved by IEEE "RA-Guard".
>

RA Guard doesn't solve that problem and never will, because it is asking a
layer 2 device to try to perform layer 3 validation of a packet. It can be
bypassed because a layer 2 device is not designed to perform full layer 3
packet processing (where as a layer 3 router or firewall is).

RA Guard is mainly a safety measure.

If you want RA security, you don't let a node send a malicious RA to any
other nodes - you make it so that to the only node it can damage with a
malicious RA is itself.

Regards,
Mark.

Ed/

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 24 Aug 2020 09:34:56 +0000

Hi Mark,
Looks like you are concerned about safety, not security: bad ND implementation in CPE could send “0” time by mistake, then host would discontinue prefix.
Are you serious?
I could imagine additional 100 bugs with similar behavior. May be it is better for vendor to fix the bug?

“RA-Guard” is blocking RA on any L2 port except manually appointed as “Router”. It does block the possibility to send rogue PIO, including the one with 0 timer.
Hence, 0 timer does not introduce new attack vector.

Eduard
From: Mark Smith [mailto:[email-masked]]
Sent: 24 августа 2020 г. 12:16
To: Vasilenko Eduard <[email-masked]>
Cc: Brian E Carpenter <[email-masked]>; Fernando Gont <[email-masked]>; Nick Hilliard <[email-masked]>; Gyan Mishra <[email-masked]>; [email-masked]; 神明達哉 <[email-masked]>
Subject: Re: draft-ietf-6man-slaac-renum: Honoring small Lifetime values

On Mon, 24 Aug 2020, 18:33 Vasilenko Eduard, <[email-masked]<mailto:[email-masked]>> wrote:

So the question is (and its always a good question to ask often) "What problem are you trying to solve?"

Confusing safety with security can mean declaring safety measures failures because they don't adequately provide security - which they were never intended to.

RA Guard doesn't solve that problem and never will, because it is asking a layer 2 device to try to perform layer 3 validation of a packet. It can be bypassed because a layer 2 device is not designed to perform full layer 3 packet processing (where as a layer 3 router or firewall is).

If you want RA security, you don't let a node send a malicious RA to any other nodes - you make it so that to the only node it can damage with a malicious RA is itself.

Regards,
Mark.

Ed/
-----Original Message-----
From: ipv6 [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Brian E Carpenter
Sent: 24 августа 2020 г. 6:21
To: Fernando Gont <[email-masked]<mailto:[email-masked]>>; Nick Hilliard <[email-masked]<mailto:[email-masked]>>; Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; 神明達哉 <[email-masked]<mailto:[email-masked]>>
Subject: Re: draft-ietf-6man-slaac-renum: Honoring small Lifetime values

   Brian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Philip Homburg <[email-masked]>
Date: Mon, 24 Aug 2020 11:48:01 +0200

> I
> have seen already a few times on this alias that: because ND has
> so many DoS attack vectors, then 1 more would not hurt.  It is a
> very wrong approach to security. We should try to cut the number
> of attack vectors under any opportunity. 

I'm very much against increasing code complexity for a security mitigation
that doesn't actually slow down an attacker.

In my opinion, this feature (rejecting small lifetime values) seemed like a 
good idea at the time, but operational reality is that it is mostly irrelevant.

Of course we should not make random changes, but Fernando has a good argument
why this feature needs to go.

The only thing this feature does is to prevent a high specific type of denial
of service attack. An attacker can easily work around this and create different
types of DoS attacks.

The only realistic mitigation at the moment is to connect all hosts using
point-to-point links to the router. 

On networks where these type of DoS are not acceptable it is easy enough to
run the network as a series of point to point links.

In other networks, fast detection is more than enough. The spectrum of DoS
attacks is just too big to close every last one of them. And an attacker only
needs one to distrupt a system.

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 24 Aug 2020 10:48:04 +0100

Vasilenko Eduard wrote on 24/08/2020 10:34:
> “RA-Guard” is blocking RA on any L2 port except manually appointed as 
> “Router”. It does block the possibility to send rogue PIO, including the 
> one with 0 timer.
> 

This is a bit academic.  Technically there is a new attack vector. 
Practically, it makes no difference because the RA component of ND was 
not designed with security in mind, and the moment you allow RAs on a 
port, you're fully abuse from that port.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 24 Aug 2020 10:50:04 +0100

> port, you're fully abuse from that port.

*fully open to abuse

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 24 Aug 2020 10:32:50 +0000

Hi Phillip,
I was against generalization: "we would not consider security, because ND security is broken anyway". Fernando did such type of generalization in a few responses on this thread (mentioned DAD - that is not relevant).

For particular correction that Fernando proposes (small timer) - I do not see new attack vector. It is already inside Rogue RA, that is mandatory to protect anyway.
As you said : "high specific type of denial of service attack". That I believe is not separate attack vector.
Ed/
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Philip Homburg
Sent: 24 августа 2020 г. 12:48
To: [email-masked]
Cc: Vasilenko Eduard <[email-masked]>
Subject: Re: draft-ietf-6man-slaac-renum: Honoring small Lifetime values 

> I
> have seen already a few times on this alias that: because ND has so 
> many DoS attack vectors, then 1 more would not hurt.  It is a very 
> wrong approach to security. We should try to cut the number of attack 
> vectors under any opportunity.

I'm very much against increasing code complexity for a security mitigation that doesn't actually slow down an attacker.

In my opinion, this feature (rejecting small lifetime values) seemed like a good idea at the time, but operational reality is that it is mostly irrelevant.

Of course we should not make random changes, but Fernando has a good argument why this feature needs to go.

The only thing this feature does is to prevent a high specific type of denial of service attack. An attacker can easily work around this and create different types of DoS attacks.

The only realistic mitigation at the moment is to connect all hosts using point-to-point links to the router. 

On networks where these type of DoS are not acceptable it is easy enough to run the network as a series of point to point links.

In other networks, fast detection is more than enough. The spectrum of DoS attacks is just too big to close every last one of them. And an attacker only needs one to distrupt a system.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 24 Aug 2020 07:39:48 -0300

> Hence, this type of generalization I do not like: if DAD is DoS vulnerable anyway then we could omit security analysis in relation to RA.

We're not omitting the security analysis. Where simply saying that the 
trust model is that local nodes are trusted. If they are not, then, you 
do SEND and/or FHS, or you are toast.  -- Pretending that you're 
improving security because you "mitigate" one single vector while you 
leave a few other dozen vectors open, is lying to yourself.

[...]
> Hence, we could assume that RA-guard is always present, then no problem with shorter timer.

If the trust model is that local nodes are trusted, then you can live 
with plain ND (as we live with DHCP and ARP in the IPv4 world). If the 
trust model is that local nodes are not trusted, then you need SEND 
and/or FHS.

It's okay to do basic *sanity* check on packets. But if you are going to 
ignore information in incoming RAs to mitigate attacks, eventually 
you'll end up in a situation where you fire the initial RA, configure 
your box, and then ignore all other RAs until "Router Lifetime - 
delta_t"  (where delta_t is a small value), such that you reduce the 
attack window to just the timespan when you poll the router (and apply 
the same kind of logic to all other options/info).

At which point you will have switched from push/pull SLAAC/ND to only 
pull -- and thus would have lost all responsiveness, and have a bad 
version of DHCPv6.

Thanks,

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 24 Aug 2020 12:00:42 +0000

I do not like when somebody gives the special name to the problem (like "trust model"),
Then claim that "it is well known - nothing to discuss",
Despite that problem still persists.
I mean: "trust model" should not be an excuse. But it look like it is used for this purpose in this mail list (by many people).
The reality is: cryptography did not fly. No point to discuss different "trust models". There is only one: no any prove of ownership.
Hence, no point to discuss, but for different reason: "other trust model has failed business case".

I prefer: "use cases", "business cases", something more relevant to real life.

PS: By the way, RFC on ND trust model have forgotten to discuss the most dangerous attack vector: MITM.

Ed/
-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: 24 августа 2020 г. 13:40
To: Vasilenko Eduard <[email-masked]>; Brian E Carpenter <[email-masked]>; 神明達哉 <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-ietf-6man-slaac-renum: Honoring small Lifetime values

> Hence, this type of generalization I do not like: if DAD is DoS vulnerable anyway then we could omit security analysis in relation to RA.

We're not omitting the security analysis. Where simply saying that the trust model is that local nodes are trusted. If they are not, then, you do SEND and/or FHS, or you are toast.  -- Pretending that you're improving security because you "mitigate" one single vector while you leave a few other dozen vectors open, is lying to yourself.

[...]
> Hence, we could assume that RA-guard is always present, then no problem with shorter timer.

If the trust model is that local nodes are trusted, then you can live with plain ND (as we live with DHCP and ARP in the IPv4 world). If the trust model is that local nodes are not trusted, then you need SEND and/or FHS.

It's okay to do basic *sanity* check on packets. But if you are going to ignore information in incoming RAs to mitigate attacks, eventually you'll end up in a situation where you fire the initial RA, configure your box, and then ignore all other RAs until "Router Lifetime - delta_t"  (where delta_t is a small value), such that you reduce the attack window to just the timespan when you poll the router (and apply the same kind of logic to all other options/info).

At which point you will have switched from push/pull SLAAC/ND to only pull -- and thus would have lost all responsiveness, and have a bad version of DHCPv6.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 24 Aug 2020 09:12:34 -0300

Hello, Eduard,

> I mean: "trust model" should not be an excuse. But it look like it is used for this purpose in this mail list (by many people).

You're probably misunderstanding what I said.

Let me ask:
If you don't trust the VL of incoming PIOs, why do you trust the PL? Why 
do you trust RIOs? Why do you trust incoming RDNSS? (and the same for 
all others).

Modulo sanity checks, you trust incoming packets, or you don't. -- 
that's the trust model I'm referring to.

> I prefer: "use cases", "business cases", something more relevant to real life.

A "business case" is not something you'd use in a security analysis.

Thanks,

---

From: Philip Homburg <[email-masked]>
Date: Mon, 24 Aug 2020 15:08:00 +0200

> I do not like when somebody
> gives the special name to the problem (like "trust model"), Then
> claim that "it is well known - nothing to discuss", Despite that
> problem still persists.  

Somethings are indeed well-known. That does not rule out new solutions, 
but typically a fundamental change is needed.

For example, on a typical ethernet any node can use any source MAC address
in outgoing packets. Typically a self learning bridge will then adjust its
forwarding table to send traffic destined for the spoofed source MAC to the
port where the attacker is.

This creates an L2 DoS and MITM attack vector that cannot be prevented by
changes to ND.

Obviously some multi-access networks do not have this problem. For example,
some ethernet installations lock MAC addresses to ports so spoofing a MAC
address is not an option. However, a discussion of those networks should be
clearly separated from the 'normal' ethernet and wifi networks we encouter
in day to day life.

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 24 Aug 2020 13:28:05 +0000

Probably our chairs are busy, because typically they come and rightfully remind that
Discussion of fundamental changes under tittle "draft-ietf-6man-slaac-renum" - is not the right approach.
It was not a point to review "trust model" again and return back to the full list of ND security problems.
It was only the point to judge: is it a new attack vector or old one? (inside draft-ietf-6man-slaac-renum)
My opinion: old one. Hence, no problem to proceed with draft-ietf-6man-slaac-renum.
Ed/
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Philip Homburg
Sent: 24 августа 2020 г. 16:08
To: [email-masked]
Cc: Vasilenko Eduard <[email-masked]>
Subject: Re: draft-ietf-6man-slaac-renum: Honoring small Lifetime values 

> gives the special name to the problem (like "trust model"), Then claim 
> that "it is well known - nothing to discuss", Despite that problem 
> still persists.

Somethings are indeed well-known. That does not rule out new solutions, but typically a fundamental change is needed.

For example, on a typical ethernet any node can use any source MAC address in outgoing packets. Typically a self learning bridge will then adjust its forwarding table to send traffic destined for the spoofed source MAC to the port where the attacker is.

This creates an L2 DoS and MITM attack vector that cannot be prevented by changes to ND.

Obviously some multi-access networks do not have this problem. For example, some ethernet installations lock MAC addresses to ports so spoofing a MAC address is not an option. However, a discussion of those networks should be clearly separated from the 'normal' ethernet and wifi networks we encouter in day to day life.

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 24 Aug 2020 13:36:04 +0000

Hi Fernando,
One do not need to reference to any "model".
Because what you are asking is very basic logic that could be presented in different way:
If somebody would trust 32bit integer (it is not important that it has name "Preferred Lifetime"), then why the one would not trust other 32bit integer that is in the same packet?
I agree to you: no new attack vector. Hence, no problem.
Eduard
-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: 24 августа 2020 г. 15:13
To: Vasilenko Eduard <[email-masked]>; Brian E Carpenter <[email-masked]>; 神明達哉 <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-ietf-6man-slaac-renum: Honoring small Lifetime values

Hello, Eduard,

On 24/8/20 09:00, Vasilenko Eduard wrote:
> I do not like when somebody gives the special name to the problem 
> (like "trust model"), Then claim that "it is well known - nothing to 
> discuss", Despite that problem still persists.

Let me ask:
If you don't trust the VL of incoming PIOs, why do you trust the PL? Why do you trust RIOs? Why do you trust incoming RDNSS? (and the same for all others).

Modulo sanity checks, you trust incoming packets, or you don't. -- that's the trust model I'm referring to.

Thanks,

---

From: Ted Lemon <[email-masked]>
Date: Mon, 24 Aug 2020 09:52:32 -0400

> Discussion of fundamental changes under tittle "draft-ietf-6man-slaac-renum" - is not the right approach.

A fundamental change would be “let’s use something other than ND.” This is not a fundamental change.

Eduard, one question you have not considered here is that if I want to attack the network by making a prefix not work, and I’m in a position to do an active attack, I can just falsify RAs for destinations that are advertised by other routers, and achieve the same effect as sending a zero lifetime RA.

Another thing you have not considered is that shutting down network connectivity isn’t a very useful attack. At a hospital, sure, but hopefully a hospital has L2 access control; if they don’t, with all the vulnerable machines they have, they are doomed.

In a home, a device that shuts down IPv6 connectivity has just broken the network. What has the attacker gained?

I'm not saying that some attacker won’t do this for lulz, but how would they do it? It would have to be some kind of virus or worm. If it’s that sort of attack, then the problem is not that your network has been shut down—actually that’s good, if you have an infected host on the network. The problem is /that you have an infected host on the network/. Go fix that problem, and the RA problem goes away.

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 24 Aug 2020 15:30:47 +0000

Hi Ted,
Yes, to all that you said.
But all these examples are not related to draft-ietf-6man-slaac-renum, because draft-ietf-6man-slaac-renum does not introduce new attack vector – it does not have influence on what you have shown below.
It was possible to abuse RA – it is still possible. IEEE assistance (RA-Guard) is the must anyway.
Hence, my comment: it is better to change subject of this e-mail thread.
I do agree that ND needs revolution.
But at the same time I believe that ND would be with us for decades to come (does not matter who would push transition). Hence, it make sense to improve whatever possible to improve.
Eduard
From: Ted Lemon [mailto:[email-masked]]
Sent: 24 августа 2020 г. 16:53
To: Vasilenko Eduard <[email-masked]>
Cc: Philip Homburg <[email-masked]>; [email-masked]
Subject: Re: draft-ietf-6man-slaac-renum: Honoring small Lifetime values

On Aug 24, 2020, at 9:28 AM, Vasilenko Eduard <[email-masked]<mailto:[email-masked]>> wrote:
Discussion of fundamental changes under tittle "draft-ietf-6man-slaac-renum" - is not the right approach.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 24 Aug 2020 11:44:56 -0400

> It was possible to abuse RA – it is still possible. IEEE assistance (RA-Guard) is the must anyway.

This is a really bad idea. RA Guard would break an unmanaged network, because there is no network operator who can decide which devices are allowed to advertise RAs and which aren’t. RA Guard should never be enabled other than by operator configuration.

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 24 Aug 2020 15:53:54 +0000

Hi Ted,
What you could propose instead of RA-Guard?
What else could patch this huge vulnerability of “rogue RA”? (that if perfect for any type of attack: DoS, MITM)

Just one warning if you would propose to scrape ND – it could not happen overnight. 7B of hosts already use it. It would need 10+ years.
May be it is better to permit small ND modifications meanwhile?
Ed/
From: Ted Lemon [mailto:[email-masked]]
Sent: 24 августа 2020 г. 18:45
To: Vasilenko Eduard <[email-masked]>
Cc: Philip Homburg <[email-masked]>; [email-masked]
Subject: Re: draft-ietf-6man-slaac-renum: Honoring small Lifetime values

On Aug 24, 2020, at 11:30 AM, Vasilenko Eduard <[email-masked]<mailto:[email-masked]>> wrote:
It was possible to abuse RA – it is still possible. IEEE assistance (RA-Guard) is the must anyway.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 24 Aug 2020 11:57:30 -0400

> What else could patch this huge vulnerability of “rogue RA”? (that if perfect for any type of attack: DoS, MITM)

This is a silly question. What you’re saying is that we have a vulnerability due to rogue RAs, and we must do something. RA Guard is something. So we must do that.

This is just bad reasoning (sorry!).

As I said, if you have a device on the link doing rogue RAs, then you need to get that device off the link or get it to stop sending rogue RAs. Since it’s likely compromised, that’s the actual problem, and you should solve that problem, rather than crippling your network and still not solving the actual problem that you have.

Separately, if you are concerned about rogue RAs sending zero valid lifetimes, then what you need is a way to validate that the advertisement you are getting came from the same router as the advertisement it updates. RA guard doesn’t do that.

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 24 Aug 2020 16:03:29 +0000

Hi Ted,
You are trying to knock out the open door. I do agree that it is better to solve IPv6 issues in IETF, not in IEEE.
But how? It looks like you have an idea. Would you develop draft?
Eduard
From: Ted Lemon [mailto:[email-masked]]
Sent: 24 августа 2020 г. 18:58
To: Vasilenko Eduard <[email-masked]>
Cc: Philip Homburg <[email-masked]>; [email-masked]
Subject: Re: draft-ietf-6man-slaac-renum: Honoring small Lifetime values

On Aug 24, 2020, at 11:53 AM, Vasilenko Eduard <[email-masked]<mailto:[email-masked]>> wrote:
What you could propose instead of RA-Guard?
What else could patch this huge vulnerability of “rogue RA”? (that if perfect for any type of attack: DoS, MITM)

---

From: Ted Lemon <[email-masked]>
Date: Mon, 24 Aug 2020 12:06:37 -0400

This is what various wgs are already doing, e.g. TEEP, RATS, SUIT, OPSAWG (MUD).

> On Aug 24, 2020, at 12:03 PM, Vasilenko Eduard <[email-masked]> wrote:
> 
> Hi Ted,
> On Aug 24, 2020, at 11:53 AM, Vasilenko Eduard <[email-masked] <mailto:[email-masked]>> wrote:

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 24 Aug 2020 16:09:32 +0000

Hello Ted:

2 things here:

- we introduced RA guard not as a response to observed attacks but as a response to frequent cases of misconfiguration. Not in routers, mind you. On PCs. People would install a distro of their choice and play with the IPv6 configuration for the fun of it, not really knowing that they enabled their stack to send RAs with distressful effects. So yes it is a feasible response to attacks but most of its usefulness is elsewhere.

- An even simpler attack against the router consists in letting the router do the job of sending RAs and all, and then steal his (L3) Link Local or his (L2) Link Layer address. A gratuitous broadcast does not trick is many networks. With FHS we do protect both types of addresses.

All in all, IPv6 ND seems designed for (by?) good willing and educated people. For anything else we can you some police.

Take care,

Pascal

From: ipv6 <[email-masked]> On Behalf Of Ted Lemon
Sent: lundi 24 août 2020 17:58
To: Vasilenko Eduard <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-ietf-6man-slaac-renum: Honoring small Lifetime values

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 24 Aug 2020 16:12:41 +0000

Oups typos, please read
- A gratuitous broadcast does the trick in many networks.
- For anything else we can use some police.

From: Pascal Thubert (pthubert)
Sent: lundi 24 août 2020 18:10
To: 'Ted Lemon' <[email-masked]>; 'Vasilenko Eduard' <[email-masked]>
Cc: [email-masked]' <[email-masked]>
Subject: RE: draft-ietf-6man-slaac-renum: Honoring small Lifetime values

Hello Ted:

2 things here:

Take care,

Pascal

From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Ted Lemon
Sent: lundi 24 août 2020 17:58
To: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: draft-ietf-6man-slaac-renum: Honoring small Lifetime values

---

From: Ted Lemon <[email-masked]>
Date: Mon, 24 Aug 2020 12:17:36 -0400

> - we introduced RA guard not as a response to observed attacks but as a response to frequent cases of misconfiguration. Not in routers, mind you. On PCs. People would install a distro of their choi…

In this case you have a network operator, and they can configure RA guard.
 
> - An even simpler attack against the router consists in letting the router do the job of sending RAs and all, and then steal his (L3) Link Local or his (L2) Link Layer address. A gratuitous broadca…

FHS?
 
> All in all, IPv6 ND seems designed for (by?) good willing and educated people. For anything else we can you some police. 

But on an unmanaged network, there are no police. RA guard is not a good tool to solve this problem on such networks.

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 24 Aug 2020 16:25:11 +0000

Encryption again?
How to distribute key materials? -> Certification Authority again?
I am off. Not interesting to participate.
Market would not accept it yet.

But 5 years later,
when “digital totalitarizm” would be over whole planet and everybody should have his “digital passport” to survive - It would become possible. Every thing (and every body) connection to certification authority (or it should be called regulation authority) would be mandatory.
Ted, wait a few years – you would be on mainstream.
Ed/
From: Ted Lemon [mailto:[email-masked]]
Sent: 24 августа 2020 г. 19:07
To: Vasilenko Eduard <[email-masked]>
Cc: Philip Homburg <[email-masked]>; [email-masked]
Subject: Re: draft-ietf-6man-slaac-renum: Honoring small Lifetime values

On Aug 24, 2020, at 12:03 PM, Vasilenko Eduard <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ted,
Cc: Philip Homburg <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 24 Aug 2020 16:51:53 +0000

Sorry; First Hop Security.

I saw the acronym used in this thread so I took that for granted.

This is the generic name of the function we place on the first hop (typically a switch or a wireless controller) that checks how the addresses are assigned and used. Bottom line is that bad things happen when there is no police, and policing requires and exact state of the network like which device owns what address and where it is connected to the network.

As it goes FHS builds a lot of state to protect the address ownership (SAVI) and the device role (like RA Guard). We obtain that state by snooping the protocols like ND and DHCPv6. But as I said repeatedly in this mailer, the information that we can glean by observing the protocols is only partial. E.g., we lack information for the expected lifespan of a newly seen address, or the order in which an address change sits point of attachment.

Also, policing means affecting the operation of the protocols when an unwanted operation is detected. Sadly this may affect the capability to introduce a change in the protocol, which could also be detected as an infringement.

It would be a lot better if the protocol provides FHS with the information it needs to do the policing well. RFC 8505 comes from years and years of experience doing that sort of games and finding the limitation of the Woodstock (good willing and educated) approach.

I never said I did not agree with your points about unmanaged. I do agree. FHS is not designed for home. Now, Murphy's law applied to IP says that if you let a user configure something that will break his network, some user will do it. For unmanaged, the only thing we can do is reduce the options left to the user (outside an "expert" mode). There's a lot to be done there in all boxes.

I recently introduced an issue in my home network (the IPv4 side) when I added new home-style APs. These babies can be used as relays, APs or routers. And guess what, the DHCP server was active by default in all the above modes. I did not even check the DHCP setting when I installed the boxes as APs. The result was that the AP gave out addresses and presented self as the router. Very similar to the RA guard problem.

I'm sure we can do better that that. We have security consideration but that does not really include misuse. Maybe we could do more management and setting considerations in the future.

Take care,

Pascal

From: Ted Lemon <[email-masked]>
Sent: lundi 24 août 2020 18:18
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: Vasilenko Eduard <[email-masked]>; [email-masked]
Subject: Re: draft-ietf-6man-slaac-renum: Honoring small Lifetime values

On Aug 24, 2020, at 12:09 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
- we introduced RA guard not as a response to observed attacks but as a response to frequent cases of misconfiguration. Not in routers, mind you. On PCs. People would install a distro of their choice and play with the IPv6 configuration for the fun of it, not really knowing that they enabled their stack to send RAs with distressful effects. So yes it is a feasible response to attacks but most of its usefulness is elsewhere.

FHS?

---

From: Ted Lemon <[email-masked]>
Date: Mon, 24 Aug 2020 13:02:23 -0400

> Ted, wait a few years – you would be on mainstream.

What I’m saying is that you can’t solve a “my computer has been pwned” problem or, to Pascal’s point, a “computer user is just smart enough to be dangerous” problem with small network protocol filtering hacks. If you want the network to be secure, you need for there to be a way to arrange for that to happen. If you want it to be automatic, that’s going to involve some kind of attestation and automatic device classification.  This can and should be under the control of the user to the extent that that’s possible.

Separately, using SEND to validate that an RA is updating a previous RA from the same router, and is not from a different router, should be possible now and should significantly mitigate “rogue RA” attacks.

Responding to my observations by accusing me of being a totalitarian is inappropriate and unhelpful.

---

From: 神明達哉 <[email-masked]>
Date: Mon, 24 Aug 2020 11:14:58 -0700

At Fri, 21 Aug 2020 21:55:21 -0300,

> that would otherwise not be possible nowadays?

I don't remember the precise original discussion, but found a
reference to old minutes of a meeting when this topic seems to be
discussed first time:
https://www.ietf.org/proceedings/38/97apr-final/xrtftr47.htm
(see the "ND Zero Lifetime advertisement issue")

I guess that answers your question at least at some high level.  Maybe
you can find more discussions in the email archive around that time (I
didn't do it myself).

I won't go into more details in that sense here, though, because
that's not really the main point of my feedback.  My point is that
what's written as a "rationale" in the current draft reads to me like
that was something not considered in the introduction of the two hour
rule, and that didn't sound like a strong argument as it was actually
considered.  IMO, it's largely a judgement call to assess the severity
of this particular attack and the cost-benefit balance of mitigating
it (while leaving others open).  Sometimes changes in the technology
trend or feedback from deployment experiences (like the more
ubiquitous deployment of wireless network, as it actually affects
other discussions in this wg) can provide somewhat more objective
points to revisit the previous judgement call.  What I'd primarily
expect is such a "rationale".  Sometimes the current members of the wg
may just happen to agree on a different judgement call without a
particular change of facts.  If so, I'm fine with that too - it's not
surprising people mind change in 20+ years.  But in that case I'd
expect the "rationale" to be written as such.  The current text
doesn't seem to be either of them and thus looks weak to me.

Is my point now clearer?

--
JINMEI, Tatuya

---

From: Fernando Gont <[email-masked]>
Date: Mon, 24 Aug 2020 20:38:17 -0300

On 24/8/20 12:53, Vasilenko Eduard wrote:
> What else could patch this huge vulnerability of “rogue RA”? (that if 
> perfect for any type of attack: DoS, MITM)

At the end of the day, it all boils down to the trust model.

For example, I run a network with multiple systems at home, connected 
via multiple switches, and the trust model is that local nodes are trusted.

Based on that premise, I run plain off-the-shelf Neighbor Discovery (no 
SEND, no FHS).

The trust model is clear, so are the implications.

If the trust model is different, you may have to mitigate ND-based 
attacks, though.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 24 Aug 2020 23:41:25 -0300

On 24/8/20 15:14, 神明達哉 wrote:
[....]
> (see the "ND Zero Lifetime advertisement issue")

Thanks a lot for the pointer!  Please see below...

> doesn't seem to be either of them and thus looks weak to me.

Yes. And sorry for not seeing your point earlier.

How about tweaking the text as follows:

---- cut here ----

    RATIONALE:

       *  The behavior described in RFC4862 had been incorporated during
          the revision of the original IPv6 Stateless Address
          Autoconfiguration specification ([RFC1971]). At the time, the
          IPNG working group decided to mitigate the attack vector
          represented by Prefix Information Options with very short
          lifetimes, on the premise these packets represented a bigger
          risk than other ND-based attack vectors [IPNG-minutes].

          While reconsidering the trade-offs represented by such
          decision, we conclude that the drawbacks of mitigating the
          aforementioned attack vector outweigh the possible benefits.

          Namely, an attacker may achieve similar effects via a
          number for ND-based attack vectors, such as directing traffic
          to a non-existing node until ongoing TCP connections time out,
          or performing a ND-based man-in-the-middle (MITM) attack and
          subsequently forging TCP RST segments to cause on-going TCP
          connections to be aborted. Thus, for all practical purposes,
          this attack vector does not really represent a greater risk
          than other ND attack vectors.

          On the other hand, IPv6 deployment experience suggests that
          the behavior specified in item "e)" (pp. 19-20) from Section
          5.5.3 of [RFC4862] results in reduced responsiveness by IPv6
          hosts, preventing a more timely reaction to flash renumbering
          events [draft-ietf-v6ops-slaac-renum].

	 In scenarios where RA-based attacks are of concern, proper
          mitigations such as RA-Guard [RFC6105] [RFC7113] should be
          implemented.
---- cut here ----

Thoughts?

(Please feel free to suggest tweaks, if necessary).

Thanks!

Cheers,

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 25 Aug 2020 07:33:35 +0000

The "trust model" is misleading. It create an illusion that there are different options.
It is a pure theoretical abstract that does not have any relationship to reality.
Hence, completely useless.
I would say: it is harmful.
Because in reality, only one option exist: untrusted. Trusted (or better to say "encrypted") has been refused by the market.
Does not make sense to discuss it again and again.

For the only real model that exist - I know only one mechanism (related to rogue RA) that accepted by market: RA-Guard.

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: 25 августа 2020 г. 2:38
To: Vasilenko Eduard <[email-masked]>; Ted Lemon <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-ietf-6man-slaac-renum: Honoring small Lifetime values

For example, I run a network with multiple systems at home, connected via multiple switches, and the trust model is that local nodes are trusted.

Based on that premise, I run plain off-the-shelf Neighbor Discovery (no SEND, no FHS).

If the trust model is different, you may have to mitigate ND-based attacks, though.

Thanks,

---

From: Mark Smith <[email-masked]>
Date: Tue, 25 Aug 2020 18:06:59 +1000

On Tue, 25 Aug 2020, 17:34 Vasilenko Eduard, <[email-masked]>
wrote:

> Because in reality, only one option exist: untrusted. Trusted (or better
> to say "encrypted") has been refused by the market.
> For the only real model that exist - I know only one mechanism (related to
> rogue RA) that accepted by market: RA-Guard.
>

ISPs don't use RA Guard, yet some how they don't have rogue RA problems
between different customers. Maybe they're just lucky?

> For example, I run a network with multiple systems at home, connected via
> multiple switches, and the trust model is that local nodes are trusted.
>

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 25 Aug 2020 08:24:25 +0000

RA-guard is not needed for Point-to-Point link (that is ISP).
If ISP is selling FBB services, then every subs typically isolated up to BNG/BRAS. BNG would not accept RA from subscriber.
If ISP has Campus (for ISP employees) they do not use RA-guard just because they do not use IPv6 for OSS/BSS and IT in general.

From: Mark Smith [mailto:[email-masked]]
Sent: 25 августа 2020 г. 11:07
To: Vasilenko Eduard <[email-masked]>
Cc: Fernando Gont <[email-masked]>; Ted Lemon <[email-masked]>; [email-masked]
Subject: Re: draft-ietf-6man-slaac-renum: Honoring small Lifetime values

On Tue, 25 Aug 2020, 17:34 Vasilenko Eduard, <[email-masked]<mailto:[email-masked]>> wrote:

ISPs don't use RA Guard, yet some how they don't have rogue RA problems between different customers. Maybe they're just lucky?

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 25 августа 2020 г. 2:38
To: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>; Ted Lemon <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: draft-ietf-6man-slaac-renum: Honoring small Lifetime values

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

---

From: Philip Homburg <[email-masked]>
Date: Tue, 25 Aug 2020 11:50:24 +0200

>(see the "ND Zero Lifetime advertisement issue")

I think the key thing is that advertising a prefix with VL zero would
cause all connections on all hosts to be closed (for addresses based on
that prefix). In general, the effects of a malicious RA can be undone by
sending an RA with correct information, however closed connections cannot
be undone.

This is a valid technical argument. However:
1) on networks where we expect malicious hosts, connections are typically
short lived. I.e., we expect malicious hosts on public wifi networks. People
who want a stable ssh connection on such network will probably run that over
a VPN. Or combine autossh with tmux.
2) In theory the effect of a malicious RA can be undone. In practice, there is
no way anyone can handcraft an RA in reasonable time. For example malicious
RAs could max out hosts with addresses that have infinite lifetime.

So this is a about the trade-off. The ability to remove a prefix quickly is in
my opinion more important than protecting against a really obscure attack. 

So in my opinion, the best text for the draft should be to summarize the
arguments in xrtftr47 and then write that at this time the wg considers
the ability to quickly invalidate address more important than protecting
against the described attack.

---

From: 神明達哉 <[email-masked]>
Date: Tue, 25 Aug 2020 13:52:00 -0700

At Mon, 24 Aug 2020 23:41:25 -0300,

[...]
>           mitigations such as RA-Guard [RFC6105] [RFC7113] should be

This one now makes much more sense.  If I were the author, though, I'd
revise the 3rd paragraph of the second bullet.  What is described in
the paragraph was basically understood at the time of [IPNG-minutes],
but the consensus at that time was that the wg still agreed on
mitigating this particular vector for reasons like the nature of
affecting all local hosts with a single forged RA.  Showing another,
more complicated way of causing the same effect doesn't seem to be a
strong counter argument against it.

As I see it, this draft (and the WG, assuming it already reached a
consensus for the proposal) makes the change because it has changed
the view on the tradeoff regarding this attach as described in the
second paragraph, rather than because there are other attacks
including one that has the same effect.  In that sense I might even
suggest removing the third paragraph.

If we still want to mention the fact that there are other attack
vectors, maybe we could combine it with the last paragraph.  Then the
third paragraph will be something like this:

  As was recognized in [IPNG-minutes], this particular attack vector
  is not the only ND-based attacks.  It might still make sense to
  consider a defense against just one of them with no other viable
  measure at that time, but more comprehensive mitigations such as
  RA-Guard [RFC6105] [RFC7113] has been developed and deployed since
  then.  It is therefore much less critical to counter just one type
  of attack today.

Wording details aside, a "rationale" like this is much less awkward to
me, in that it explains how/why the wg now changes the view on the
tradeoff with a new fact that didn't exist at the time of the original
discussion.

That said, I guess it's more or less editorial at this point.  With a
reference to [IPNG-minutes], your proposed new text is probably clear
enough.  If you think my proposed text above makes the overall
rationale better, feel free to use it; otherwise I'm fine with just
dismissing it and closing this thread.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Aug 2020 09:06:37 +1200

On 25-Aug-20 21:50, Philip Homburg wrote:
...
> against the described attack. 

I still haven't understood the argument against rate limiting. If a host
is coded to ignore at most one small lifetime announcement per minute (or
whatever rate seems best), doesn't that mitigate such attacks?

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Wed, 26 Aug 2020 07:37:04 -0300

Hello, Tatuya,

On 25/8/20 17:52, 神明達哉 wrote:
> revise the 3rd paragraph of the second bullet.  > What is described in
>    measure at that time, but more comprehensive mitigations such as >    RA-Guard [RFC6105] [RFC7113] has been developed and deployed since

Did you mean "It might have made sense.."? (I'm having trouble parsing 
the sentence)

Anyway...based on your comments, how about tweaking the text as (I've 
essentially removed the third and fourth paragraphs of the second bullet):

---- cut here ----

    RATIONALE:

---- cut here ----

Question: should we list SEND as one of the "proper mitigations"?  -- 
in most cases it's not deployable. But I guess this will be brought up 
sooner or later... so one might list it, and then it's up to the reader 
to make the judgement of whether it's deployable.

and then add this to the Security Considerations Section:
---- cut here ----
	 The protocol update in Section 4.2 could allow an on-link
          attacker to perform a Denial of Service attack againts local 
hosts,
          by sending a forged RA with a PIO with a Valid Lifetime of 0.
          Upon receipt of that packet, local hosts would invalidate the
          corresponding prefix, and therefore remove any addresses
          configured for that prefix, possibly terminating e.g. TCP
          connections employing such addresses. However, an attacker may
          achieve similar effects via a number for ND-based attack
          vectors, such as directing traffic
          to a non-existing node until ongoing TCP connections time out,
          or performing a ND-based man-in-the-middle (MITM) attack and
          subsequently forging TCP RST segments to cause on-going TCP
          connections to be aborted. Thus, for all practical purposes,
          this attack vector does not really represent a greater risk
          than other ND attack vectors.

          As noted in Section 4.2, in scenarios where RA-based attacks
          are of concern, proper
          mitigations such as RA-Guard [RFC6105] [RFC7113] should be
          implemented.
---- cut here ----

FWIW, the inclusion of the text in the Sec Cons serves a different 
purpose -- the mandatory security analysis, so to speak.

Thanks!

Regards,

---

From: Philip Homburg <[email-masked]>
Date: Wed, 26 Aug 2020 13:46:08 +0200

>whatever rate seems best), doesn't that mitigate such attacks?

I'm not sure how that would work. Suppose a router sends a RA every 10 
minutes with a prefix that has a valid time of 1 day.

An attacker sends a RA every 10 seconds with the same prefix and a valid
time of 0 seconds. How does a host know that it should only process the RAs
that have a valid time of 1 day?

I think the ability to quickly invalidate prefixes comes inherently with
an attack vector.  But RA already has many DoS vectors.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 26 Aug 2020 13:49:16 +0200

> Question: should we list SEND as one of the "proper mitigations"?
> -- in most cases it's not deployable. But I guess this will be
> brought up sooner or later... so one might list it, and then it's
> up to the reader to make the judgement of whether it's deployable.

I think the texts are good.

As long as SEND is not formally deprecated it makes sense to add reference.

---

From: 神明達哉 <[email-masked]>
Date: Wed, 26 Aug 2020 16:49:45 -0700

At Wed, 26 Aug 2020 07:37:04 -0300,

> Did you mean "It might have made sense.."? (I'm having trouble parsing

"might have made sense" would indeed be more grammatically accurate.

> essentially removed the third and fourth paragraphs of the second bullet):

That one also works for me.

> to make the judgement of whether it's deployable.

I thought about SEND while writing my response, too, but chose to not
mention it because there's virtually no serious deployment and so it's
unrealistic to refer to it in this context.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Aug 2020 13:56:16 +1200

> that have a valid time of 1 day?

Fair question. The heuristic would have to be more complex than I suggested
and involve an element of learning (normal frequency & source of RAs, etc.). I agree
that this isn't appropriate for the draft, but might make an interesting
little research project.
 
> an attack vector.  But RA already has many DoS vectors.

Yes, certainly, as Fernando has said.

    Brian

---

From: David Farmer <[email-masked]>
Date: Thu, 27 Aug 2020 10:46:14 -0500

I've reread this group of drafts and have a few comments on the issue of
honoring small lifetime values;

I think in general I support making the change here, however, I going to
play the devil's advocate a bit first.

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.

Now, imagine the following perverse 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.

With RFC 4862 as currently specified, both prexies will be valid and the
hosts on the network will have stable IPv6 addresses in each prefix, as
long as the RAs are advertised more than every two hours, which is pretty
common. However, if changed as proposed, hosts will not have stable IPv6
addresses and will oscillate between addresses on Prefix A and Prefix B as
the RAs are received from each router.

As I said, this is a perverse misconfiguration and is not likely to occur
on a real operational network, but people make mistakes or do stupid
things. So while perverse, this configuration is possible, maybe warn
people not to do it, it will be bad!

Thanks.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Fernando Gont <[email-masked]>
Date: Thu, 27 Aug 2020 13:22:22 -0300

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.

> 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.
> 
> long as the RAs are advertised more than every two hours, which is 
> pretty common. However, if changed as proposed, hosts will not have 
> stable IPv6 addresses and will oscillate between addresses on Prefix A 
> and Prefix B as the RAs are received from each router.

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.

In the scenario you describe, without RFC8028 both routers will compete 
for being the default router. If the host keeps the prefix (as in the 
scenario you describe), but it happens to send its packets to the other 
router, packets would likely be egress-filtered.

With RFC8028, one would expect that the host knows that both routers can 
route that prefix. When the host receives an RA from RTB with VL=0, it 
will simply disassociate the prefix with this particular router. BUt 
since there was another router advertising the same prefix, addresses 
would not me removed.

Thanks!

Regards,

---

From: David Farmer <[email-masked]>
Date: Thu, 27 Aug 2020 15:42:55 -0500

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

> > Now, imagine the following misconfiguration; A network with two

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

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.

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. In that case, both routers
could conceivably deliver the traffic if the hosts were to configure both
prefixes as would currently occur. 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.

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?

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.

Thanks

---

From: Philip Homburg <[email-masked]>
Date: Fri, 28 Aug 2020 15:24:21 +0200

>there other corner case scenarios that should be considered?

I don't follow this line of reasoning. There is an endless number of ways to
configure a router, or collection of routers such that network connectivity
is broken.

Of course it is possible that some misconfigurations are common enough that
we need to do something, either publish more guidance or in specification
changes.

However, that should start with scenarios that are likely to occur.
Do we really want to speculate on what errors operators of enterprise
networks are going to make?