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

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Tue, 4 Feb 2020 17:41:14 +0000

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

---

From: Warren Kumari <[email-masked]>
Date: Tue, 4 Feb 2020 14:55:27 -0500

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

I'm not aware of any IPR associated with this document.

W

-- 
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: Colin Doyle <[email-masked]>
Date: Thu, 6 Feb 2020 17:48:25 +0000

Thank you, Joe. 

As an author, I support adoption and am not aware of any IPR related to this draft.

C

___________________________________________
Colin Doyle
Juniper Networks | Senior Systems Engineer
C. 503.810.2129 | E. [email-masked]

On 2/4/20, 9:41 AM, "Joe Clarke (jclarke)" <[email-masked]> wrote:

    
    
    Joe and Tianran

---

From: Warren Kumari <[email-masked]>
Date: Sun, 9 Feb 2020 16:49:02 -0500

Dear OpsAWG,

As there has been no feedback, I have to assume that you think that
this document is **absolutely** perfect, and contains nothing unclear,
inaccurate or confusing. Franky, this surprises me - I'd thought that
the bit about the penguins was somewhat vague...

W
(Yes, this is just a thinly veiled attempt to try and get more review
and feedback :-))

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Tue, 11 Feb 2020 15:01:48 +0000

With a week left, I was hoping for more discussion.  This draft is relatively short (14 pages) and very readable.  I encourage members to read through it again.

Thanks.

Joe

> On Feb 4, 2020, at 12:41, Joe Clarke (jclarke) <[email-masked]> wrote:
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Tue, 11 Feb 2020 15:19:03 +0000

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.

===

Section 3.1:

s/intially/initially/

s/contrained/constrained/

s/certifcates/certificates/

===

Section 3.2:

s/identfiers/identifiers/

s/certificat/certificate/

s/certifcates/certificates/

===

Section 4.2:

s/certifcate/certificate/

===

Section 4.3:

s/certifcate/certificate/

s/it never need/it never needs/

I think you need some definition of “garbage” when doing config “tasting”.  It may be required that you standardize a header to indicate that the config file is encrypted so the device doesn’t try to process what could potentially be _lots_ of true garbage.  You have a sentence here about the exact detection method being out of scope (which is true for what is a config), but saying anything else is decryptable may not please the security folks too much.

Joe

---

From: Warren Kumari <[email-masked]>
Date: Tue, 11 Feb 2020 15:41:30 -0500

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

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

> s/intially/initially/

DONE. Thank you!

> s/contrained/constrained/

DONE. Thank you!

> s/certifcates/certificates/

DONE. Thank you, there were 2 instances of this.

> s/identfiers/identifiers/

DONE. Thanks!

> s/certificat/certificate/

DONE.

> s/certifcates/certificates/

DONE.

> s/certifcate/certificate/

DONE. Well, this is getting embarrassing....

> s/certifcate/certificate/

DONE. My old tooling would automagically spellcheck - I've just added
a spellcheck to VS Code (my new ID tooling editor).

> s/it never need/it never needs/

DONE.

> I think you need some definition of “garbage” when doing config “tasting”.  It may be required that you standardize a header to indicate that the config file is encrypted so the device doesn’t try…

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

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

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Tue, 11 Feb 2020 21:39:59 +0000

On Feb 11, 2020, at 15:41, Warren Kumari <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Feb 11, 2020 at 10:19 AM Joe Clarke (jclarke) <[email-masked]<mailto:[email-masked]>> wrote:

Thanks.  I like these changes.

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.

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.

Joe

---

From: tom petch <[email-masked]>
Date: Wed, 12 Feb 2020 12:36:48 +0000

I cannot remember if I made this comment before but the I-D seems a bit weak when it comes to prior art.  I came across this issue over 30 years ago and recall a consultant advising a customer that while they had 100 PC their approach of sending out engineers to each installation was viable but when it went up to 1000 and on to 10,000 the costs would bankrupt the firm.   A lot of effort went into avoiding employee travel and that has grown ever more sophisticated.  Latterly much effort has been put into avoiding support calls, another major drain on resources.

And when this was applied to machines that deliver cash, not sure best term for them is (ATM? cashpoint? ..), then the level of security was very high.

It is a long time since I was involved in developing or deploying the technology but see it regularly as a user of PC, such as the upgrade of thousands of PC from Windows 7 to Windows 10 with zero visits or the configuring of PC with key pairs to support public network access or ...  So, much has been done on this topic in the PC arena and it seems to me that networking is a decade or two behind the times.

I have masses of material about the state-of-the-art in the 1990s but nothing current.

Tom Petch
________________________________________
From: OPSAWG <[email-masked]> on behalf of Warren Kumari <[email-masked]>
Sent: 09 February 2020 21:49
To: Joe Clarke (jclarke)
Cc: opsawg; [email-masked]
Subject: Re: [OPSAWG] WG LC for draft-ietf-opsawg-sdi-02

Dear OpsAWG,

W

---

From: tom petch <[email-masked]>
Date: Thu, 13 Feb 2020 09:50:43 +0000

a second separate concern I have about this I-D is the Security Considerations which seem to me to be weak.  I would expect more about the hazards of key pairs, keeping the private private, who is the TA for the chain, who generated the key pair and how.

I see a lot of private certificates and key pairs these days driven by the requirements of PC to connect to networks and suspect that there is a disaster there waiting to happen because the risks are not understood and believe that what is being recommended here may fall in the same category.

Tom Petch

Dear OpsAWG,

W

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Thu, 20 Feb 2020 00:45:35 +0000

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.

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