Re: [Netconf] Kathleen Moriarty's Discuss on draft-ietf-netconf-yang-patch-12: (with DISCUSS and COMMENT)

[Kathleen Moriarty <[e-mail]>]

Hello,

Thanks for your responses, inline.

On Fri, Nov 11, 2016 at 12:08 PM, Andy Bierman <[e-mail]> wrote:

>
>
> On Fri, Nov 11, 2016 at 6:04 AM, Mahesh Jethanandani <
> [e-mail]> wrote:
>
>> Andy,
>>
>> I am looking at -13 version of the document and following up on all the
>> DISCUSS on the document to make sure they have been addressed. In
>> particular -
>>
>> On Nov 3, 2016, at 9:35 PM, Kathleen Moriarty <
>> [e-mail]> wrote:
>>
>> Hi Andy,
>>
>> Thanks for your response and sorry I didn't see it sooner.  Inline
>>
>> On Tue, Nov 1, 2016 at 5:21 PM, Andy Bierman <[e-mail]> wrote:
>>
>>>
>>>
>>> On Tue, Nov 1, 2016 at 7:15 AM, Mahesh Jethanandani <mjethanandani@gm
>>> ail.com> wrote:
>>>
>>>> Authors,
>>>>
>>>> Can we address Kathleen's comments?
>>>>
>>>> Mahesh Jethanandani
>>>> [e-mail]
>>>>
>>>> > On Oct 31, 2016, at 8:28 AM, Kathleen Moriarty <
>>>> [e-mail]> wrote:
>>>> >
>>>> > Kathleen Moriarty has entered the following ballot position for
>>>> > draft-ietf-netconf-yang-patch-12: Discuss
>>>> >
>>>> > When responding, please keep the subject line intact and reply to all
>>>> > email addresses included in the To and CC lines. (Feel free to cut
>>>> this
>>>> > introductory paragraph, however.)
>>>> >
>>>> >
>>>> > Please refer to https://www.ietf.org/iesg/s
>>>> tatement/discuss-criteria.html
>>>> > for more information about IESG DISCUSS and COMMENT positions.
>>>> >
>>>> >
>>>> > The document, along with other ballot positions, can be found here:
>>>> > https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-patch/
>>>> >
>>>> >
>>>> >
>>>> > ------------------------------------------------------------
>>>> ----------
>>>> > DISCUSS:
>>>> > ------------------------------------------------------------
>>>> ----------
>>>> >
>>>> > This should be easy to resolve through discussion or some text tweaks.
>>>> > In the security considerations section, I see some text that hints at
>>>> my
>>>> > questions below, but isn't clear enough, so I'd like to discuss it to
>>>> see
>>>> > if these things are covered, or why they are not, and to see if we can
>>>> > tweak the text a bit.
>>>> >
>>>> > The following text is helpful, is PATCH described in
>>>> > [I-D.ietf-netconf-restconf]?
>>>> >   This document defines edit processing
>>>> >   instructions for a variant of the PATCH method, as used within the
>>>> >   RESTCONF protocol.
>>>> >
>>>> > I see section 2.7 discusses error handling and validating the YANG
>>>> > module, but is there a way that the hash (or some other mechanism) of
>>>> the
>>>> > patch could be validated to ensure the patch was not altered.  Is that
>>>> > already described for PATCH?
>>>>
>>>
>>> The YANG Patch requests are not signed.
>>> These messages are sent within the RESTCONF protocol, which MUST use TLS.
>>>
>>> Sec 1. says:
>>>
>>>    It may be possible to use YANG Patch with other protocols besides
>>>    RESTCONF.  This is outside the scope of this document.  It may be
>>>    possible to use YANG Patch with datastore types other than a
>>>
>>>        configuration datastore. This is outside the scope of this
>>> document.
>>>
>>> The security requirements for protocols other than RESTCONF are not
>>> discussed.
>>> Should I add text somewhere to make it clear the document applies only
>>> to RESTCONF use of YANG Patch?
>>>
>>
>> Yes, that text would be good.  It might be good to mention that there is
>> no capability to sign or validate patches with RESTCONF as well so this is
>> clear in the considerations.
>>
>>
>> Is this addressed somewhere? I looked at Section 1 and Security
>> Considerations, but could not find any explicit mention.
>>
>
> sec. 1, para 2:
>
> This document only specifies the use of
>
>    the YANG Patch media type with the RESTCONF protocol.
>

OK, could you make the point clear that answers my question specific to
RESTCONF usage?  This would mean a little text added to clarify that there
is no capability to validate the patch had not been altered from my
original question.




>
>
>>
>>
>>>
>>> >
>>>> > I also see this text in the security considerations section:
>>>> >   It is important for RESTCONF server implementations to carefully
>>>> >   validate all the edit request parameters in some manner.
>>>> >
>>>> > Is the source of the patch authenticated?  Can the client receiving
>>>> the
>>>> > patch be authenticated?  Is this handled through RESTCONF?  Since YANG
>>>> > modules could add in write capabilities, unauthenticated patches could
>>>> > result in opening backdoors or revealing information that was not
>>>> > intended.  You are covering it with that statement, but it's not
>>>> clear if
>>>> > both ends can be authenticated and there are attacks if they are not
>>>> > authenticated.
>>>> >
>>>> >
>>>>
>>>
>>>
>>> It is covered by RESTCONF. Both client and server are authenticated.
>>>
>>
>> Great, can you re-word the sentence to make sure it is clear that this is
>> done with RESTCONF, but maybe not other protocols?
>>
>>
>> And this.
>>
>
>
> sec 5, para 3
>
>  For RESTCONF, both the client and server MUST be authenticated,
>
>    according to section 2 of [I-D.ietf-netconf-restconf
> <https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-13#ref-I-D.ietf-netconf-restconf>
> ].
>

OK, thank you.

Best regards,
Kathleen


>
> Andy
>
>
>
>>
>>
>>
>>>
>>> However, security considerations sec. has this text
>>> similar to sec. 1:
>>>
>>>   It may be possible to use YANG Patch with other protocols besides
>>>
>>>     RESTCONF, which is outside the scope of this document.
>>>
>>> Regarding this text:
>>>
>>> > Since YANG
>>> > modules could add in write capabilities, unauthenticated patches could
>>> > result in opening backdoors or revealing information that was not
>>> > intended.
>>>
>>> I am not aware how YANG allows this vulnerability.
>>> The patch represents instance data which is supposed to conform to
>>> the schema nodes in the YANG modules advertised by the server.
>>>
>>
>> RESTCONF doing server and client auth covers this.  Thank you.
>>
>>>
>>>
>>>
>>>
>>>> > ------------------------------------------------------------
>>>> ----------
>>>> > COMMENT:
>>>> > ------------------------------------------------------------
>>>> ----------
>>>> >
>>>> > Nit: In section 2.2
>>>> >
>>>> >   YANG Patch does not provide any access to specific datastores.  It
>>>> is
>>>> >   am implementation detail
>>>> >
>>>> > s/am/an/
>>>>
>>>
>>> fixed
>>>
>>>
>>>> >
>>>> >
>>>>
>>>
>>>
>>> Andy
>>>
>>>
>>
>> Thank you!
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>>
>>
>> Mahesh Jethanandani
>> [e-mail]
>>
>>
>>
>>
>


-- 

Best regards,
Kathleen