Re: SLAAC protocol improvements for flash renumbering (Fwd: New Version Notification for draft-gont-6man-slaac-renum-02.txt)

[Fernando Gont <[e-mail]>]

Hello, Michael,

Thanks for the great feedback and timely response! In-line....


On 20/2/20 07:50, Michael Richardson wrote:
> 
> Hi, thank you for this.
> 
> I want to suggest that you move the section 4.3/4.4 to
> draft-gont-v6ops-cpe-slaac-renum, but I can't find this document to be sure.
> Maybe you are still posting it.
> 
> Then, this document is all about updates to the Host side only.

Note:
Section 4.4 is a host-side update. It does benefit from the router-side 
change proposed in Section 4.3, though.



> Note the section 4.1.1 updates what the valid values are, and while that seems
> like advice to routers, it's rather advice to hosts as to what they should
> accept as valid.

Indeed, the default values are to be employed by routers. That said, 
Section 4.1.2 is about processing of such values by hosts, where we 
suggest to cap them.

At the end of the day, when routers use more appropriate values, even 
legacy systems would benefit from that. And even if routers don't use 
appropriate values, a host can do better by capping the received value 
to something that makes more sense.



> I think that 4.2, in the section about attacks, could suggest that when a
> suspicious RA is seen (such as Lifetime=0), that the host might want to check
> with a unicast RS (with a randomized delay).

My take is that modulo some sanity checks you can perform on some ND 
packets, since the protocol is inherently insecure, you trust the 
router, or you don't.

Note that, e.g. when you receive an RA with a Router Lifetime of 0, you 
just honor it without cheking with a unicast RS....



> I like section 4.4, and I really think it's actually the meat of this
> document.  I think that the title of the document should be less about Flash
> Renumbering, and just about "Improved Host Behaviour for Router Advertisements"
> or some such.

I'd agree that most of the meet is in Section 4.4. That said, at the end 
of the day the goal is to improve the behaviour of SLAAC in renumbering 
scenarios... and doing the right thing at routers does help a bit. So 
I'd rather keep the router parts, too.

But we're certainly open for the wg to change our mind ;-)

Thanks!

Cheers,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1