Subject: [Captive-portals] WGLC on draft-ietf-capport-architecture and ...-api

From: "Martin Thomson" <[email-masked]>
Date: Thu, 05 Mar 2020 17:55:26 +1100

Hi folks, 

Our fine editor teams have contributed updates to these drafts.

https://tools.ietf.org/html/draft-ietf-capport-architecture-06
https://tools.ietf.org/html/draft-ietf-capport-api-05

This starts a joint working group last call on these documents. Please respond this mail with your views regarding the suitability of these documents for publication (as Informational RFC and Proposed Standard RFC respectively) before 2020-03-23.

There are a few minor issues, but I consider those to be minor enough to require only trivial fixes. Some appear to be already addressed. If you think that major changes are needed, or have proposed resolutions to issues, adding those to your email would be helpful.

Issues are tracked here:
https://github.com/capport-wg/architecture/issues
https://github.com/capport-wg/api/issues

I encourage people to add issues to the tracker as they review these documents. Directly raising minor editorial issues on GitHub will help us focus attention on substantive issues here.

Cheers,
Martin (and Erik)

---

From: [email-masked]
Date: Sat, 07 Mar 2020 16:54:01 -0500

Regarding capport-api, in the section 4.1.1 Server Authentication, is 
this advice different than the authentication done by any other HTTPS 
client? It seems like this section should just be referencing another 
document (but I don't know).

Also, I think the API document should give some guidance about caching 
indicators from the server side (I'm not sure what this should be, 
however)

Also, I think the API document needs to explain how user equipment is to 
be identified.

I'm making editorial pull requests in github.

-Dave

On 2020-03-05 01:55, Martin Thomson wrote:
> This starts a joint working group last call on these documents. Please
> respond this mail with your views regarding the suitability of these
> documents for publication (as Informational RFC and Proposed Standard
> RFC respectively) before 2020-03-23.
> 
> There are a few minor issues, but I consider those to be minor enough
> to require only trivial fixes. Some appear to be already addressed. If
> you think that major changes are needed, or have proposed resolutions
> to issues, adding those to your email would be helpful.
> 
> Issues are tracked here:
> I encourage people to add issues to the tracker as they review these
> documents. Directly raising minor editorial issues on GitHub will help
> us focus attention on substantive issues here.
> 
> Cheers,
> Martin (and Erik)
> 
> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals

---

From: Kyle Larose <[email-masked]>
Date: Sat, 14 Mar 2020 12:21:56 -0400

Hello,

I support publication of capport-api. Thanks for all the hard work!

I have a bunch of minor comments:

Regarding Section 4.1.1:

>   If the certificates do
>   require the use of AIA, the captive network will need to allow client
>   access to the host specified in the URI.

Should this be phrased as "... the captive network MUST allow client
access..." Without this the solution won't work in this situation, so
isn't a strong requirement necessary?

Regarding this section as a whole, we are placing some requirements on
the enforcement device here... Do you think
those should be repeated in the architecture document so those
implementing only enforcement devices can consider them?

Regarding Section 4.2:

>     "bytes-remaining" (optional, integer): indicates the number of
>      bytes remaining, after which the client will be in placed into a
>      captive state.  The byte count represents the total number of IP
>      packet (layer 3) bytes sent and received by the client.  Captive
>      portal systems might not count traffic to whitelisted servers,
>      such as the API server, but clients cannot rely on such behavior.

We say that the "seconds-remaining" field should be omitted if
`captive=false`. We do
not for "bytes-remaining". That feels inconsistent. I think we should
add the following
statement to the end of this field's definition:

Added text:
"
The API server SHOULD include this value if the client is not captive
(i.e. captive=false)
and SHOULD omit this value for captive clients.
"

That brings me to another point. What should the API reply with if
there are no time or byte constraints
on the session? Should the fields be omitted in that case? The
document does not discuss that. If we do
decide to add that, do we need discussion about what the client
can/cannot infer from omission of these fields (i.e.
if bytes-remaining is not set, then there is no byte quota for the connection)?

Regarding the byte-count: we say it represents the total number of
tx/rx packets. I think it's obvious that this means
the sum of the total of each, but maybe it'd be better to make that
explicit. New text:

"The byte count represents the sum of the total number of IP packet
(layer 3) bytes sent and received by the client."

On that note, do most captive portal vendors count this way, or is
there often a distinction between tx/rx that we may
want to account for? Or is that complicating things too much, since
this is more a hint than anything else?

Finally, do we need to version the API (i.e. add a version field)? I'm
not sure what the best practice for IETF-defined HTTP APIs is.

Regarding section 6.2:

> Type:  The type of the JSON value to be stored, as one of the value
>    types defined in [RFC8259].

I don't think the types given in section 4.2 (the existing key
registry) exactly follow RFC8259.
In particular, whether or not a field is required/optional is not part
of its type in JSON.
Should we mention what the type field in the registry should include that?

E.g.:

> Type:  The type of the JSON value to be stored, as one of the value
>    types defined in [RFC8259], along with whether it is optional or required.

Or, add a new field:

> Required:  Whether or not the key is required in the document.

I guess it's unlikely that we'd add a new required field since the API
isn't versioned right now, but we should probably be explicit and
consistent
about it.

Thanks,
Kyle

---

From: Tommy Pauly <[email-masked]>
Date: Sun, 22 Mar 2020 16:41:51 -0700

Hi Kyle,

Thanks for the review! I’ve made some editorial fixes in this commit:

https://github.com/capport-wg/api/commit/fabc5994e3d7945140dd379a8b81a28b5b668bb4

> On Mar 14, 2020, at 9:21 AM, Kyle Larose <kyle=[email-masked]> wrote:
> 
> Hello,
> 

Agreed, changed the wording as suggested.
> implementing only enforcement devices can consider them?

Filed https://github.com/capport-wg/architecture/issues/50
> and SHOULD omit this value for captive clients.

Added clarification as suggested.

> if bytes-remaining is not set, then there is no byte quota for the connection)?

I added some clarification that these fields only SHOULD be included when the client session is indeed limited in the fashion described.

> (layer 3) bytes sent and received by the client."

Fair clarification! Added as suggested.
> this is more a hint than anything else?

This is a strategy that some portals use at least, based on previous discussion. More complex strategies (which are harder to describe in the API, and harder for the client to be able to estimate) could always be added later.

> not sure what the best practice for IETF-defined HTTP APIs is.

My impression is that we don’t need any version field at the moment. We always could add a new field that would indicate a re-interpretation of fields, etc.

> isn't versioned right now, but we should probably be explicit and

To note, we already did have the following comment:

“All keys other than the ones defined in this document as "required" will be considered optional.”

I think the main issue was that the list was one list with the (requirement, type) tuple being listed together. I rearranged the text into two lists: a list of one entry for the only required field, and a list following of the optional fields. I think this should address your comment.

Best,
Tommy

---

From: Tommy Pauly <[email-masked]>
Date: Sun, 22 Mar 2020 16:44:37 -0700

> On Mar 7, 2020, at 1:54 PM, [email-masked] wrote:
> 
> Regarding capport-api, in the section 4.1.1 Server Authentication, is this advice different than the authentication done by any other HTTPS client? It seems like this section should just be referencing another document (but I don't know).

I think the advice is only different with regards to how the captive network allows certificate validation (and related traffic) through, for which I am not aware of a description elsewhere. If anyone has a suggestion for a reference, I’d be happy to add it!

> 
> Also, I think the API document should give some guidance about caching indicators from the server side (I'm not sure what this should be, however)

Will add this in follow-up to:
https://github.com/capport-wg/api/issues/33 <https://github.com/capport-wg/api/issues/33>
> 
> Also, I think the API document needs to explain how user equipment is to be identified.

Will add this in follow-up to:
https://github.com/capport-wg/api/issues/34 <https://github.com/capport-wg/api/issues/34>

Thanks for the comments!
Tommy

---

From: Gurshabad Grover <[email-masked]>
Date: Tue, 24 Mar 2020 08:22:26 +0530

On 3/5/20 12:25 PM, Martin Thomson wrote:> This starts a joint working
group last call on these documents. Please respond this mail with your
views regarding the suitability of these documents for publication (as
Informational RFC and Proposed Standard RFC respectively) before 2020-03-23.

Thanks for all the great work, authors and editors! I have reviewed
capport-architecture, and I support its publication as an RFC. Some
comments below.

On capport signal
-----------------
The Captive Portal Signal section (2.5) was a bit confusing to me.

Is 'signal' only meant to be binary information, i.e. whether traffic is
restricted or not? (pt. 3 in the section) If yes, the inclusion of a
'pending expiry' notification in the same section seems contradictory.
(It also assumes that some information is available since "On receipt of
preemptive notification, the User Equipment can prompt the user to
refresh.")

I think the clearest explanation of it is offered in the Security
Considerations rather than the section itself, i.e. the signal should
not carry any information at all, that it just acts as a prompt for the
User Equipment to contact the API. (This explanation makes other things
fall in line as well: the 'pending expiry' notification is just a
timed-signal that is no different from any other except for when it was
triggered.)

I would suggest rephrasing sentences in the Captive Portals section to
make them as clear as the security considerations text. If my
understanding is correct, please let me know and I'm happy to submit a
PR to this effect.

Pull request
------------
I have submitted a pull request with some editorial suggestions; happy
to elaborate on them if the motivation is not clear from the changes.
<https://github.com/capport-wg/architecture/pull/51>

Privacy considerations
----------------------
Since we're dealing with unique identifiers and traffic information,
would love to hear people's thoughts on whether a brief privacy
considerations section would be useful. If yes, happy to help with that.

Thank you.
-Gurshabad

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 25 Mar 2020 15:53:03 +1100

Thanks for doing this Gurshabad.

I think we've debated the removal of the signaling section on a number of occasions.  Could this text perhaps be reduced to something simpler, especially in light of our decision not to specify anything?

Perhaps:

--->8--
When User Equipment first connects to a network, or when there are changes in status, the Enforcement Device could generate a signal toward the User Equipment.  This signal indicates that the User Equipment might need to contact the API Server to receive updated information.  For instance, this signal might be generated when the end of a session is imminent.

An Enforcement Device MUST rate limit any signal; User Equipment MUST rate limit attempts to contact the API Server; see Section 7.4.
--8<---

That loses a lot of text, but I don't know that any of what is presently there is critical.  For instance, the current text recommends against a spoofable signal, but doesn't really say what it means to spoof.

What do the editors of the spec think?

---

From: Kyle Larose <[email-masked]>
Date: Mon, 30 Mar 2020 08:17:16 -0400

Thanks Martin,

It's unfortunate that we weren't able to better expand on the signals
section, but if the section is confusing or misleading, we probably
should reduce it to something like you've suggested. I think that text
captures the essence of the signal. I'll submit an issue to change it.

---

From: Kyle Larose <[email-masked]>
Date: Mon, 30 Mar 2020 08:18:53 -0400

Thanks for the feedback and PR Gurshabad!

I've replied to Martin's reply regarding the signal section.

As for the privacy considerations, it's probably a good idea. Did you
have some suggestions for content?

Thanks,

Kyle