Subject: [netconf] I-D Action: draft-ietf-netconf-https-notif-03.txt

From: [email-masked]
Date: Fri, 10 Jul 2020 10:41:22 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration WG of the IETF.

        Title           : An HTTPS-based Transport for Configured Subscriptions
        Authors         : Mahesh Jethanandani
                          Kent Watsen
	Filename        : draft-ietf-netconf-https-notif-03.txt
	Pages           : 27
	Date            : 2020-07-10

Abstract:
   This document defines a YANG data module for configuring HTTPS based
   configured subscription, as defined in RFC 8639.  The use of HTTPS
   maximizes transport-level interoperability, while allowing for
   encoding selection from text, e.g.  XML or JSON, to binary.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netconf-https-notif/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netconf-https-notif-03
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-https-notif-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-https-notif-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 14 Jul 2020 16:50:40 +0000

Hi Mahesh,

Hi Kent,

It is good to see the updates and simplifications made.  A few questions /
thoughts on the latest:

(1) For ietf-https-notif.yang why did you choose "uses x509c2n:cert-to-name"
rather than linking to ietf-truststore.yang's

     grouping truststore-grouping

       +-- certificate-bags! {certificates}?

          +-- certificate-bag* [name]

             +-- name?          string

             +-- certificate* [name]

                +-- name?                            string

(2) Do you plan any functionality which inter-related with the receiver
action 'reset' from SN?  Right now this SN action resets the subscription.
Whether this actually does anything to any underlying connection is
undefined in SN.  So I think what you have is fine as you define no actions
on receiver-instances.  But I figured I would ask: is there anything
connection related which you might expose for the receiver as a whole?

(3) I have a question on receiver capability discovery prior to sending
notifications.  Section 2.1 says that a publisher 'can' issue an HTTP GET
for the capabilities.  This also suggests that it can choose not to send
such a request.  What is the required behavior for an HTTPS publisher and
receiver when the targeted receiver doesn't support the expected
capabilities?

(4) Extending the question (3), the  <subscription-started> notification
from SN can be used for this functionality.   Looking at the example you
have in pipelining Section 1.5.1, the second POST of a YANG notification
occurs is shown before the "Send 204 (No Content) is returned" for the first
notification.   Could you explicitly add the <subscription-started>
notification to section 1.5.1 to disambiguate things?  For example:   

       -------------                               --------------

       | Publisher |                               | Receiver   |

       -------------                               --------------

       Establish TCP             ------>

       Establish TLS             ------>

       Send HTTPS POST message

       with <subscription-       ------>

       started> notification 

                                                   Send 200 (OK)

                                 <------           for
<subscription-started>

       Send HTTPS POST message

       with YANG defined         ------>

       notification #1

       Send HTTPS POST message

       with YANG defined         ------>

       notification #2

                                                   Send 204 (No Content)

                                 <------           for notification #1

                                                   Send 204 (No Content)

                                 <------           for notification #2

There were some earlier discussions on these overall interactions in threads
like:

https://mailarchive.ietf.org/arch/msg/netconf/oUxidvvW95lmxS1LLqyvuivuRcA/

Thanks,
Eric

>  <https://datatracker.ietf.org/doc/draft-ietf-netconf-https-notif/>

>  <https://tools.ietf.org/html/draft-ietf-netconf-https-notif-03>

>  <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-https-notif-03>

>  <https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-https-notif-03>

> Please note that it may take a couple of minutes from the time of

> submission until the htmlized version and diff are available at
tools.ietf.org.

>  <ftp://ftp.ietf.org/internet-drafts/> ftp://ftp.ietf.org/internet-drafts/

> _______________________________________________

> netconf mailing list

>  <mailto:[email-masked]> [email-masked]

>  <https://www.ietf.org/mailman/listinfo/netconf>
https://www.ietf.org/mailman/listinfo/netconf

---

From: Kent Watsen <[email-masked]>
Date: Wed, 15 Jul 2020 23:21:32 +0000

Hi Eric,

> (1) For ietf-https-notif.yang why did you choose "uses x509c2n:cert-to-name" rather than linking to ietf-truststore.yang's

I’m unclear about the issue.  Cert-to-name performs a mapping that doesn't exist anywhere else...

> (2) Do you plan any functionality which inter-related with the receiver action 'reset' from SN?  Right now this SN action resets the subscription.  Whether this actually does anything to any underlying connection is undefined in SN.  So I think what you have is fine as you define no actions on receiver-instances.  But I figured I would ask: is there anything connection related which you might expose for the receiver as a whole?

No SN-relation is planned. I’m unsure exactly what the ask is.  Please advise.

> (3) I have a question on receiver capability discovery prior to sending notifications.  Section 2.1 says that a publisher 'can' issue an HTTP GET for the capabilities.  This also suggests that it can choose not to send such a request.  What is the required behavior for an HTTPS publisher and receiver when the targeted receiver doesn't support the expected capabilities?

IIRC, the encoding MAY be configured in the SN model.  If it is not *and* the publisher doesn’t probe the receiver’s capabilities, and thus blindly sends whatever it wants, it risks the receiver returning an HTTP 4xx error.  Makes sense?

>  (4) Extending the question (3), the  <subscription-started> notification from SN can be used for this functionality.   Looking at the example you have in pipelining Section 1.5.1, the second POST of a YANG notification occurs is shown before the "Send 204 (No Content) is returned" for the first notification.   Could you explicitly add the <subscription-started> notification to section 1.5.1 to disambiguate things?  For example:   
>  
>                                  <------           for <subscription-started>
>  
>  
>        Send HTTPS POST message

I think that this is proper.  Guidance welcomed.  But not that, beyond HTTP [N}ACKs, this is a one-way flow of content, so whatever needs to fit into those HTTP responses.

Kent // as co-author

> There were some earlier discussions on these overall interactions in threads like:
> https://mailarchive.ietf.org/arch/msg/netconf/oUxidvvW95lmxS1LLqyvuivuRcA/ <https://mailarchive.ietf.org/arch/msg/netconf/oUxidvvW95lmxS1LLqyvuivuRcA/>
>  
> Thanks,
> Eric

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 16 Jul 2020 13:20:56 +0000

Hi Kent,

> From: Kent Watsen, July 15, 2020 7:22 PM
> 
> Hi Eric,
> 
> 

No action is needed on this one, but let me give you my original thinking.  I was trying to understand the relationship between  RFC7407 certificate names 

       (below is an the extract from RFC7405, Appx A.7)
             <cert-to-name>
               <id>2</id>
               <fingerprint>11:0A:05:11:00</fingerprint>
               <map-type>x509c2n:specified</map-type>
               <name>
                 Joe Cool
               </name>
            </cert-to-name>

and the certificate name ietf-truststore.yang's certificate name (per above).   It took me a while, but I found the relationship by drilling down through the client/server drafts to the example of draft-ietf-netconf-restconf-client-server, Section 3.1.2.1:

     grouping restconf-server-grouping
       +-- client-identity-mappings
          +---u x509c2n:cert-to-name

> (2) Do you plan any functionality which inter-related with the receiver action
> 'reset' from SN?  Right now this SN action resets the subscription.  Whether
> this actually does anything to any underlying connection is undefined in SN.
> So I think what you have is fine as you define no actions on receiver-
> instances.  But I figured I would ask: is there anything connection related
> which you might expose for the receiver as a whole?
> 

SN allows a configured subscription to be reset.   Will there be anything in https-receiver to reset a type of transport connection to a receiver?  Based on the current model, I am assuming no.    

> notifications.  Section 2.1 says that a publisher 'can' issue an HTTP GET for
> the capabilities.  This also suggests that it can choose not to send such a
> request.  What is the required behavior for an HTTPS publisher and receiver
> when the targeted receiver doesn't support the expected capabilities?
> 
> IIRC, the encoding MAY be configured in the SN model.  If it is not *and* the
> publisher doesn’t probe the receiver’s capabilities, and thus blindly sends
> whatever it wants, it risks the receiver returning an HTTP 4xx error.  Makes
> sense?

Let's say that IP addresses change, and there is an unintentionally targeted receiver which can accept a TLS connection, but cannot/will not reply with an HTTP error.  Are there scenarios where this could be used as a DOS attack?

>  (4) Extending the question (3), the  <subscription-started> notification from
> SN can be used for this functionality.   Looking at the example you have in
> pipelining Section 1.5.1, the second POST of a YANG notification occurs is
> shown before the "Send 204 (No Content) is returned" for the first
> I think that this is proper.  Guidance welcomed.  But not that, beyond HTTP
> [N}ACKs, this is a one-way flow of content, so whatever needs to fit into
> those HTTP responses.

This works for me.  I believe it helpful to show the <subscription-started> in the diagram: SN says that the <subscription-started> needs to be confirmed before other notifications are pushed.

Eric

---

From: Kent Watsen <[email-masked]>
Date: Fri, 17 Jul 2020 10:45:39 +0000

Hi Eric.

Cherry-picking, since the rest resolved.

> SN allows a configured subscription to be reset.   Will there be anything in https-receiver to reset a type of transport connection to a receiver?  Based on the current model, I am assuming no. 

As an SN author and expert, I’m hoping that you can advise us on the what SHOULD be in the I-D.  Happy to accommodate.

> Let's say that IP addresses change, and there is an unintentionally targeted receiver which can accept a TLS connection, but cannot/will not reply with an HTTP error.  Are there scenarios where thi…

The receiver can return HTTP 200, which normal operation would require, but can’t return 4xx?  This seems unlikely, given that the receiver’s TLS cert was configured and thus presumably trusted (i.e., proofed before deployed).  The scenario described seems to be purely operator error - agreed?   Besides, what could this draft define to defend/detect such a case?

> This works for me.  I believe it helpful to show the <subscription-started> in the diagram: SN says that the <subscription-started> needs to be confirmed before other notifications are pushed.

Okay.

K.

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 17 Jul 2020 13:40:44 +0000

Hi Kent,

From: Kent Watsen <[email-masked]> 
Sent: Friday, July 17, 2020 6:46 AM
To: Eric Voit (evoit) <[email-masked]>
Cc: Mahesh Jethanandani <[email-masked]>; [email-masked]
Subject: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-03.txt

Hi Eric.

<eric> I am fine with receiver-wide subscription resets being undefined right now.  

<eric> Answer combined with the one to (4) below.

      Establish TCP             ------>

      Establish TLS             ------>

      Send HTTPS POST message

      Send HTTPS POST message

      Send HTTPS POST message

                                                  Send 204 (No Content)

Okay.

<eric> Since you are explicitly acknowledging with an "ok" the <subscription-started> message before doing any notification pipelining, I am completely good with the answer to (3).   In early conversations with Mahesh, I remember (perhaps incorrectly) that a <subscription-started> might not be sent.  With <subscription-started>, we have protections against configured subscriptions being used for DOS attacks against unwilling receivers which will accept TLS, but for whatever reason won't/can't send an HTTP 4xx error.

Eric

K.