Subject: Re: [Netconf] review of draft-ietf-netconf-call-home-11

From: Benoit Claise <[email-masked]>
Date: Mon, 12 Oct 2015 09:50:20 +0200

Hi Simon,

Thanks for your review.
One comment below.
> Hi.
>
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security
> area directors.  Document editors and WG chairs should treat these
> comments just like any other last call comments.
>
> I believe the document is ready.
>
> One main security concern is the reversal of roles that this document
> introduce, but letting TCP clients act as TLS/SSH servers, and vice
> versa, is not unheard of.  As long as proper peer authentication is
> performed, and other parts of the security protocols are properly
> performed, I see no fundamental problem with this.  I'm sure some
> implementations will need to be tweaked to deal with this, and
> terminology might confusing at times.  The 'Security Considerations'
> section does a good job discussing this, and some other issues too.
>
> Two minor questions:
>
> 1) Are non-certificate-based TLS out of scope for NETCONF/RESTCONF?  I
> see no discussion of it in this draft, and text in the document
> implicitly assumes host keys (SSH) or certificates (TLS) are used.
> Think about TLS-PSK for example, which seems like a relevant idea for
> embedded devices.  This may not be the document to adress this, but if
> there is work towards that goal already, it might be useful to align
> this document with that.
>
> 2) Section 2 says 'The term "NETCONF/RESTCONF client" can refer to the
> [RFC6241], Section 1.1 "client".'.  Shouldn't this say the term may
> refer to a RESTCONF client and reference draft-ietf-netconf-restconf?
> Or is that not intentional?  The use of the word 'can' make this text
> vague to me.  The previous section (1.5) says that 'NETCONF/RESTCONF' is
> an abbrevation for 'the NETCONF or the RESTCONF'.  The same comment
> applies to section 3.  Maybe this is a misunderstanding on my side, but
> the text confused me so it may be useful to resolve.
I mentioned this point in my AD review 
(http://www.ietf.org/mail-archive/web/netconf/current/msg10535.html).
I now realize that I made a typo in my email: NETCONF/RESTCONF client" 
_can refers_ to the RFC 6241 section 1.1 "client"
This should read:  "NETCONF/RESTCONF client" refers to the RFC 6241 
section 1.1 "client"
Ditto for NETCONF/RESTCONF server.
This takes care of the confusing "can" word. Thanks for spotting that.

Regarding the draft-ietf-netconf-restconf reference now.
https://tools.ietf.org/html/draft-ietf-netconf-restconf-07#section-1.4.1 
refers to RFC 6241 for the client.
So I believe that we're good with a single reference to RFC 6241 in this 
draft.

Regards, Benoit
> Thanks,
> /Simon

---

From: Kent Watsen <[email-masked]>
Date: Mon, 12 Oct 2015 14:22:47 +0000

Hi Simon,

Regarding your two comments:

1. Are non-certificate-based TLS out of scope for NETCONF/RESTCONF?

Yes or, more specifically, both NETCONF over TLS and and RESTCONF restrict TLS to certificates.  The relevant text is in RFC 7589, Section 1 and draft-ietf-netconf-restconf-07, Section 2.2.   Do you think there should be a note in this draft stating this as well?

2. Section 2 says 'The term "NETCONF/RESTCONF client" can refer to the [RFC6241], Section 1.1 "client".'

Does Benoit's suggestion to replace "can refer" with "refers" satisfy the language vagueness issue?   - And also, are you satisfied with having the single reference to RFC6241, since RESTCONF pulls the term from RFC6241 as well?

Thanks
Kent

From: Benoit Claise <[email-masked]<mailto:[email-masked]>>
Date: Monday, October 12, 2015 at 3:50 AM
To: Simon Josefsson <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netconf] review of draft-ietf-netconf-call-home-11

Hi Simon,

Thanks for your review.
One comment below.

Hi.

Two minor questions:

I mentioned this point in my AD review (http://www.ietf.org/mail-archive/web/netconf/current/msg10535.html).
I now realize that I made a typo in my email: NETCONF/RESTCONF client" can refers to the RFC 6241 section 1.1 "client"
This should read:  "NETCONF/RESTCONF client" refers to the RFC 6241 section 1.1 "client"
Ditto for NETCONF/RESTCONF server.
This takes care of the confusing "can" word. Thanks for spotting that.

Regarding the draft-ietf-netconf-restconf reference now.
https://tools.ietf.org/html/draft-ietf-netconf-restconf-07#section-1.4.1 refers to RFC 6241 for the client.
So I believe that we're good with a single reference to RFC 6241 in this draft.

Regards, Benoit

Thanks,
/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 16 Oct 2015 13:28:31 +0200

Hello.

Re 1: Thank you for clarification.  I don't believe there is any need
to repeat text from a normative reference.

Re 2: Benoit's suggestion would resolv the concern for me.

Thanks,
/Simon

> Yes or, more specifically, both NETCONF over TLS and and RESTCONF
> restrict TLS to certificates.  The relevant text is in RFC 7589,
> Section 1 and draft-ietf-netconf-restconf-07, Section 2.2.   Do you
> think there should be a note in this draft stating this as well?
> 
> Does Benoit's suggestion to replace "can refer" with "refers" satisfy
> the language vagueness issue?   - And also, are you satisfied with
> having the single reference to RFC6241, since RESTCONF pulls the term
> from RFC6241 as well?
> 
> 
> Thanks
> Kent
> 
> 
> To: Simon Josefsson
> <[email-masked]<mailto:[email-masked]>>,
> "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]>>,
> "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]>>,
> "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]>>,
> "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]>> Subject: Re: [Netconf]
> review of draft-ietf-netconf-call-home-11
> 
> Hi Simon,
> 
> Thanks for your review.
> One comment below.
> 
> Hi.
> 
> ongoing effort to review all IETF documents being processed by the
> IESG. These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
> 
> vague to me.  The previous section (1.5) says that 'NETCONF/RESTCONF'
> is an abbrevation for 'the NETCONF or the RESTCONF'.  The same comment
> applies to section 3.  Maybe this is a misunderstanding on my side,
> but the text confused me so it may be useful to resolve.
> 
> I now realize that I made a typo in my email: NETCONF/RESTCONF
> client" can refers to the RFC 6241 section 1.1 "client" This should
> read:  "NETCONF/RESTCONF client" refers to the RFC 6241 section 1.1
> "client" Ditto for NETCONF/RESTCONF server. This takes care of the
> confusing "can" word. Thanks for spotting that.
> 
> refers to RFC 6241 for the client. So I believe that we're good with
> a single reference to RFC 6241 in this draft.
> 
> Regards, Benoit
> 
> Thanks,
> /Simon
> 
>