Subject: Re: [Netconf] SSE and HTTP/2 in restcon-notif

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Mon, 1 Oct 2018 13:48:03 +0000

Hi,

From: 'Andy Bierman' <[email-masked]>
Date: Saturday, September 29, 2018 at 2:00 PM
To: Qin Wu <[email-masked]>
Cc: Martin Bjorklund <[email-masked]>, Netconf <[email-masked]>, "Reshad Rahman (rrahman)" <[email-masked]>
Subject: Re: [Netconf] SSE and HTTP/2 in restcon-notif

On Thu, Sep 27, 2018 at 8:40 PM Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:

>    I envision the variation being relatively
>    minor, something along the line of:
>
>      if 1.1, then SSE.
>      if 2.0, client MAY open a stream first.
>
> 3) resource URIs
>
>    This is likely where we need to spend the most time. We know that
>    establish-subscription returns a dynamically created URI, comparable
>    to what a client might get from ietf-restconf-monitoring:restconf-state\
>    /streams/stream/access/location.

But it is not quite comparable.  In the 8040 solution, the location
url is static, and then query parameters are provided by the client
in the POST to the SSE location.  Thus, the server can free any
resources associated with the filter when the connection is
terminated.

The RESTCONF procedure starts with the client
examining /restconf-state/streams to determine stream and its location URL
How does this monitoring information relate to the new solution?
I assume both the old and new procedures can be supported by the same server.
Is it just ignored for a new subscription?

Since all SSE data is always media type test/event-stream, each stream entry indicates
its secondary encoding format. This leaf is type string, and only 'xml' and 'json' are supported
in RFC 8040. The establish-subscription RPC has its own leaf for this purpose.

[Qin]: I am lost, should resource URIs returned by establish-subscription same as location URL obtained from
ietf-restconf-monitoring:restconf-state\/streams/stream/access/location.
My understanding is if SSE is supported, let’s say HTTP 1.1, we will use location URL returned from
ietf-restconf-monitoring:restconf-state\/streams/stream/access/location
as input parameter to trigger SSE. In case of SSE being supported, HTTP GET(URI) is not needed ? wrong?
But if SSE is not supported, let’s say HTTP/2, location URL is not needed. HTTP POST(URI) is required.
Please correct me, if I am wrong.
<RR> I don’t think there’s the option of SSE not being supported, doesn’t RESTCONF mandate SSE support?

I think sec 3.2 Discovery says use a different /streams container
https://tools.ietf.org/html/draft-ietf-netconf-restconf-notif-07#section-3.2

<RR> Right. But using RFC8040 container should also work, or are you saying we could not support RFC8040 container?

Regards,
Reshad.

There should be a sub-section added in sec. 3 about coexistence between
RFC 8040 notifications and this document. Obviously vendors need the option
of supporting both in the same server.

How do they interact, starting with the 2 different /streams data models.

It should also be clear in this draft that the "uri" leaf contents are implementation-specific
and MAY be predictable by a client application. Query parameters MAY be defined
for use with the GET operation on this uri.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 1 Oct 2018 09:18:00 -0700

On Mon, Oct 1, 2018 at 6:48 AM, Reshad Rahman (rrahman) <[email-masked]>
wrote:

> Hi,
>
>
>
>
>
> *From: *'Andy Bierman' <[email-masked]>
> *Date: *Saturday, September 29, 2018 at 2:00 PM
> *To: *Qin Wu <[email-masked]>
> *Cc: *Martin Bjorklund <[email-masked]>, Netconf <[email-masked]>,
> "Reshad Rahman (rrahman)" <[email-masked]>
> *Subject: *Re: [Netconf] SSE and HTTP/2 in restcon-notif
>
>
>
>
>
> On Thu, Sep 27, 2018 at 8:40 PM Qin Wu <[email-masked]> wrote:
>
>
>
> <RR> Right. But using RFC8040 container should also work, or are you
> saying we could not support RFC8040 container?
>
>
>

The draft mentions RFC 8040 in a few places so the reader is left to assume
that there is no relationship between /streams and /restconf-state/streams.
The RFC 8040 procedures are intentionally ignored and there is no
correlation between
these data models (e.g., same stream name in both is just coincidence with
no meaning).

If this is the intent then it should be stated in the draft.
If not, then something else should be stated in the draft.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Mon, 1 Oct 2018 18:00:59 +0000

> It should also be clear in this draft that the "uri" leaf contents
> are implementation-specific and MAY be predictable by a client 
> application. Query parameters MAY be defined for use with the GET
> operation on this URI.

I recommend against this.  

Going back to my "how does the server ensure only said client 
accesses the resource?", I've been thinking that the simplest
thing would be for the server to generate a cryptographically
random URI.  This would defend against both brute-force and
side-channel attacks.  As the URI is always communicated over
TLS (both when sent to the client, and in all the client's
subsequent HTTP requests), the URI is never exposed.  SecDir
should be fine with this.  Thoughts?

FWIW, I'm distinguishing between the URI that should be 
receiver-specific, and the subscription/id that may be shared 
by multiple receivers.

Kent // contributor

---

From: Andy Bierman <[email-masked]>
Date: Mon, 1 Oct 2018 11:26:08 -0700

> receiver-specific, and the subscription/id that may be shared

I think the URI should be implementation-specific.
There is a standard mechanism to discover the correct URI to use
so there should not be any client issues.

If the URI just happens to match /streams/<stream-name>/<subscription-id>
then so what?  It is just an implementation detail right?
And if the URI happens to support configured subscriptions this way
that should not cause a problem either.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 01 Oct 2018 20:35:08 +0200 (CEST)

> so there should not be any client issues.

+1

> then so what?  It is just an implementation detail right?

Exactly.  It might actually be on the form
/streams/<stream-name>/<subscription-id>?filter="..."

In this case there are no resources to free for the server, so the
"lifetime" problem is trivial to handle.

> that should not cause a problem either.

Yes.  Except that we're not doing configured subscriptions now...

/martin

---

From: Kent Watsen <[email-masked]>
Date: Mon, 1 Oct 2018 19:35:12 +0000

>> If the URI just happens to match /streams/<stream-name>\
>> /<subscription-id> then so what?  It is just an implementation
>> detail right?

I thought the concern was for preventing access by other
clients.  One way is through obfuscation (e.g., random URI).
Another is through access control, but we wouldn't want
dynamically-generated NACM rules, in <intended> at least,
so then is the idea for dynamically-generated NACM rules
to be in <operational>?  Perhaps someone can post text?

Kent // contributor

---

From: Andy Bierman <[email-masked]>
Date: Mon, 1 Oct 2018 12:45:53 -0700

> to be in <operational>?  Perhaps someone can post text?
I don't know why changes to NACM would be needed.
The server just needs to remember the username of the client that
did the <establish-subscription> and only allow that username
to do the GET on the SSE URI.

Andy

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 2 Oct 2018 23:41:03 +0000

Hi,

Since we’ve agreed on SSE/RESTCONF, should we change the “POST to URI” (URI returned in the create-subscription response) to a GET as in 6.3 of RFC8040? Actually the current section 3.5 has text which says POST but Figure 2 has GET.

Regards,
Reshad.

From: 'Andy Bierman' <[email-masked]>
Date: Monday, October 1, 2018 at 12:18 PM
To: "Reshad Rahman (rrahman)" <[email-masked]>
Cc: Qin Wu <[email-masked]>, Martin Bjorklund <[email-masked]>, Netconf <[email-masked]>
Subject: Re: [Netconf] SSE and HTTP/2 in restcon-notif

On Mon, Oct 1, 2018 at 6:48 AM, Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

From: 'Andy Bierman' <[email-masked]<mailto:[email-masked]>>
Date: Saturday, September 29, 2018 at 2:00 PM
To: Qin Wu <[email-masked]<mailto:[email-masked]>>
Cc: Martin Bjorklund <[email-masked]<mailto:[email-masked]>>, Netconf <[email-masked]<mailto:[email-masked]>>, "Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netconf] SSE and HTTP/2 in restcon-notif

The draft mentions RFC 8040 in a few places so the reader is left to assume
that there is no relationship between /streams and /restconf-state/streams.
The RFC 8040 procedures are intentionally ignored and there is no correlation between
these data models (e.g., same stream name in both is just coincidence with
no meaning).

Regards,
Reshad.

Andy

Andy

---

From: Kent Watsen <[email-masked]>
Date: Tue, 2 Oct 2018 23:55:11 +0000

> Since we’ve agreed on SSE/RESTCONF, should we change the “POST to URI”
> (URI  returned in the create-subscription response) to a GET as in 6.3
> of RFC8040? Actually the current section 3.5 has text which says POST
> but Figure 2 has GET.

Good catch.  Yes, that makes sense.  IIRC, the POST was
only there to align with some HTTP/2 stream convention.

Kent // contributor

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 3 Oct 2018 13:37:00 +0000

> Good catch.  Yes, that makes sense.  IIRC, the POST was only there to align with
> some HTTP/2 stream convention.

That should be fine.  (POST was initially selected for GRPC compatibility.)

Eric

> Kent // contributor
> 
> 
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Kent Watsen <[email-masked]>
Date: Thu, 4 Oct 2018 16:01:28 +0000

Regarding this URI issue, I’m okay if it’s implementation specific for how the security is ensured.  Let’s be sure this is clearly called out in the Security Considerations section.

Kent

On 10/1/18, 3:46 PM, "Andy Bierman" <[email-masked]<mailto:[email-masked]>> wrote:

Kent // contributor

Andy