Re: draft-ietf-6man-slaac-renum: Heuristics to deprecate stale information

[Fernando Gont <[e-mail]>]

Hi, Ted,

On 12/8/22 13:52, Ted Lemon wrote:
> FWIW, I would like to see the points made in item 1 addressed in
> slaac-renum. 

Regarding #1, nodes that change their address or that "disappear", I'd 
say that's not really renumbering.

That said, we could clarify in a separate section noting that, e.g.:

   When the Router Lifetime of a router expires, Neighbor Discovery
   information advertised by such router should be disassociated with
   said router -- hence the faith of such information will depend on
   whether such information is advertised by other routers.

Thoughts?




> These heuristics seem straightforward, and with unicast
> RS, they seem low-cost. I am somewhat concerned that a cleverly-timed
> attack while a router is known to be down could result in bogus
> prefixes being preferred on the link until the router comes back, and
> that this could break connections on the link that would otherwise
> survive. But this seems like a fairly useless denial-of-service
> attack.

At the end of the day, you trust the link, or you don't.

An attacker that wants to e.g. cause connections to be reset could do 
things such as:

* Spoof RAs from every router advertising the victim prefix, with a PIO
   valid lifetime of 0, which would make the corresponding addresses
   invalid, and cuase the connections using such addresses to be reset.

* Perform a MITM attack (via spoofed NS, NA, Redirects, or RA), and then
   do traditional TCP RST attacks.

  etc.


> I don’t agree with point 2, mostly because I don’t understand why
> this is good and Eduard’s draft doesn’t say, at least not in section
> 6.5. I’m not entirely clear on what is being said—are we talking
> about prefixes acquired via prefix delegation?

What Eduard is saying wrt #2 is that RFC9096 recommends CPE routers to 
record delegated prefixes on stable storage, but the same recommendation 
should probably apply to routers in general (not just CPE).

In that light, we could borrow the relevant section from RFC9096, such 
that it applies to all routers.

Thoughts?


> I also agree with point 3—it would be good to specify this behavior
> in the document.

Fair enough. I'll craft some text and send it to the list for review.

As always, thanks a lot for your input!

Regards,
-- 
Fernando Gont
e-mail: [e-mail]
PGP Fingerprint: 7F7F 686D 8AC9 3319 EEAD C1C8 D1D5 4B94 E301 6F01

-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494