Subject: Re: [OPSAWG] WG LC for draft-ietf-opsawg-sdi-02

From: Warren Kumari <[email-masked]>
Date: Wed, 4 Mar 2020 19:07:02 -0500

Apologies for the delay in responding, I was traveling and then got
sidetracked into other things.

On Tue, Feb 11, 2020 at 4:40 PM Joe Clarke (jclarke) <[email-masked]>
wrote:

>
>
> On Feb 11, 2020, at 15:41, Warren Kumari <[email-masked]> wrote:
>
> On Tue, Feb 11, 2020 at 10:19 AM Joe Clarke (jclarke) <[email-masked]>
> wrote:
>
>
> As a contributor, I think this document is mostly ready (and as previously
> stated, I like and support the work).  That said, after another read I
> found a few spelling nits and some comments:
>
> In Section 2, you paint the picture of a scenario, but “break the fourth
> wall” to explain what is existing and what is new functionality as well as
> state that the document prescribes using the SN as the unique identifier.
> In the spirit of a scenario with additional context, I think you should
> clarify that the DHCP boot of an out-of-the-box device is _typically_
> existing functionality.  Some vendors’ devices may not do this.
>
>
> Good point. I have just submitted a new version which I think
> addresses this (and your other comments below) -- I broke section 2
> ("Overview / Example Scenario") into 2 sections, "Overview" and
> "Example Scenario". This required moving some text around, but I think
> addresses your concern (and improves the document).
>
>
> Thanks.  I like these changes.
>

Yay!

>
> Yes -- unfortunately there doesn't seem to be any sort of standard way
> to add a comment device configs - these all work on different devices:
> # I'm a comment
> ! I'm also a comment
> ; Yet another comment format
> : This is getting silly
> ' Ugh, who thought apostrophes was a sane comment character?!
>
>
> I was actually thinking about the opposite.  Could your encrypted blob
> have a header?  Like a PEM encoded certificate has "-----BEGIN
> CERTIFICATE——“.  This way if you have that, you try to decrypt, else you
> assume a regular config.
>

Ah, I has misunderstood, see below.

>
> How about some text along the lines of: "Unfortunately there is no
> standard way to identify if a config file has been successfully
> decrypted, as different vendors use different configuration languages,
> with different forms of comments, etc.
> It is recommended that each vendor documents a standard header or
> magic which devices can use to determine if the configuration seems
> largely correct.
> As an example, Cisco IOS configuration files use the '!' character as
> a comment, and so Cisco IOS files could be expected to start with
> something like '! This is a Cisco IOS configuration file'. Juniper
> Network's JunOS uses '#' as a comment character, and so Juniper could
> adopt the convention of using '## JunOS device configuration file' (or
> some other string, to be chosen and documented by the vendor)."
>
> Note that I have *not* included this is the newly posted version yet,
> as I think it needs some polishing...
>
>
> Sure.  This text works as a means to know if decryption works.  But (and I
> haven’t tried this), if I point IOS to just some random bytes via option
> 150, I think it will try to load it (I know that some file extensions like
> .tcl and .py will be considered).  So you might not need to worry so much
> about what if decryption works as to know what should be attempted to be
> decrypted.
>

So, I've added some text saying the vendors could do things like use a
specific file extension (e.g if the file ends in .enc, it is encrypted),
have a magic string header, or use a different DHCP options -- these are
much better options than what I originally had (try parse, and if that
doesn't work, try decrypt).
Thank you, this has significantly improved the document / mechanism.

W

> Joe

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

---

From: Warren Kumari <[email-masked]>
Date: Wed, 4 Mar 2020 19:22:44 -0500

On Wed, Feb 19, 2020 at 7:45 PM Joe Clarke (jclarke) <[email-masked]>
wrote:

> A bit late, but we did get some good review from Gen Art and some opsawg
> members.  This yielded a rev 03 and will certainly lead to an 04.  With
> that, we will push this draft forward to the IESG after all pending
> comments are addressed.
>

Thank you,  I have just posted -04, and think that this addresses the open
comments.

Joe's comments suggesting a magic header led to a significant improvement
-- I now suggest vendors expect a file extension, header, or use a
different DHCP codepoint for encrypted configs. I'm intentionally not being
too prescriptive, so vendors can choose other solutions if they fit their
deployment model better.

I've also addressed Tom's comments by including additional text on the
applicability, and that this issue is common in other industries /
environments as well.

If / when this gets sent to the IESG, I will obviously not be the
responsible AD - I will conscript^W politely ask for someone else to carry
it, and will recuse myself from balloting (as is standard practice).

W

>
> Who in opsawg would be interested in serving as shepherd for this draft?
> @Tom Petch, I know you called out some prior art concern.  Would you have
> an interest in shepherding?  In general, I think the draft is (or very soon
> will be) in good shape.  I would have liked to see a security directorate
> review, but no current reviews have called out serious security issues.
>
> Joe
>
> > On Feb 4, 2020, at 12:41, Joe Clarke (jclarke) <[email-masked]>
> wrote:
> >
> > With the publication of -02 of this draft, it seems to have reached
> stability.  There has been interest in both usage an implementation of this
> draft expressed in the past, but discussion has been quiet lately.
> >
> > This email serves as a two-week start of a WG LC for this document.
> Please [re-]read this draft and comment on its content as well as whether
> or not you feel it’s ready.  WG LC will conclude on February 18, 2020.
> >
> > Authors and contributors, please reply on-list as to whether or not you
> are aware of any intellectual property attributed to this work.  Reply that
> either you are not aware of any such IP, or reply with the details of known
> IP while also making sure you complete any IPR disclosures in data tracker.
> >
> > Joe and Tianran
> > _______________________________________________
> > OPSAWG mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/opsawg
>
>