Re: [OPSAWG] draft-ietf-opsawg-sdi status

From: OPSAWG <opsawg-bounces@ietf.org> on behalf of Warren Kumari <warren@kumari.net>
Sent: 02 April 2020 23:24
On Fri, Mar 6, 2020 at 8:17 PM Michael Richardson <mcr+ietf@sandelman.ca> wrote:
>
>
> I have posted a shepherd write-up.
>
> Some suggestions that I have, one of which came from the idnits:
>
> 1) IPv6 example maybe?  How would IPv6 work at all?
>    Can it work in a SLAAC-only environment?

Good catch - the only IPv4 address was in the example in the Appendix
('tftp 192.0.2.1 -c get SN19842256.enc') -- I've changed this to
instead be 'tftp 2001:0db8::23 -c get SN19842256.enc'.

I've also clarified that the document is more of a framework, and that
things like how devices perform their autoboot is background and
describes existing vendor functionality.

Currently the autoboot implementations mostly / all use DHCP. There
was a 6MAN document to add a "Boot File URL option" to RAs
(draft-qin-6man-nb-option), but this work seems to have been abandoned
- but, whatever the case, this functionality should work with any sort
of autoboot that delivers something that looks like a config file,
regardless of how that files is discovered...

>
> 2) no references for DHCP are there at all.  Probably there should be a few?
>    at least to RFC2131?

Gadzooks, yes, definitely! Fixed and pushed to github...
Thank you...

>
> Some questions about how the keys would be generated, kept, distributed,
> etc. were asked during WG adoption discussion (tom perch and other), and I'm
> not sure that those comments/questions were dealt with fully at the time.
> I don't think that this is blocking though.

I've added some (admittedly handwavey) text to an earlier commit, but
am expecting that I'll get some feedback during LC / SecDir / Security
AD reviews.

<tp>
I said months ago that I would provide text linking to previous practices and every time I have sat down to write it have gone round in circles and was reminded of that when my MUA told me to logon as administrator so that it could overwrite my PC -  NO!   So- apologies

I do think that the Security Considerations needs more. Like the padlock on the web page which could mean an encrypted connection with an entropy of 40 bit, having a private public key pair is useless unless it is strong enough and used in a good algorithm.  Lifting recommended values from TLS1.3 or, given the context, SSH is the sort of thing I have in mind.  I note that the example uses RSA.  I would be disappointed if a Security AD thought that this was ok:-)

Also the cert needs checking if only for the correct serial number or other fields that should match but also for the other standard cert checks

I think that more references are needed.  DHCP yes, but also RADIUS, TFTP, HTTPS, 802.1AR, SMIME

Tom Petch

Thank you for the shepherd writeup / review,
W

P.S: Apologies all for the terseness of this email (and other emails)
- I am attempting to improve my typing, and so am trying a split,
ortholinear keyboard, and am having a REALLY hard time adjusting...

>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg

--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg