Re: [Captive-portals] Capport return of experience and... questions :(

[Tommy Pauly]

Hi Xavier,

Yes — I’ll follow up with you off-list to collect the right logs from your 
machine.

Best,
Tommy

> On Jul 19, 2022, at 4:39 AM, Xavier BEAUDOUIN  wrote:
> 
> Hello,
> 
> 
>> Le 19 juil. 2022 à 12:13, Martin Thomson > > a écrit :
>> 
>> On Mon, Jul 18, 2022, at 17:37, Michael Richardson wrote:
>>> I'm hoping we'll find soneone replying here about this, perhaps offering to
>>> debug this with you.  (This might be a job for the IETF Hackathon
>>> VPN... which does L2 stuff)
>> 
>> Tommy probably knows what is going on.  Or at least can help with working it 
>> out.
> 
> 
> Well we are really looking forward some help. Because the good part was 
> really fast captive portal window on devices.
> 
> Anyway will take the suggestion of Michael and will do some other tests.
> 
> We will be pleased to have any input we can have to fix that…
> 
> Kind regards,
> Xavier
> 
> --
> 
> 
>   
> ​Xavier ​Beaudouin | ​System & Network Engineer
> 11, Avenue Guillaume 
>  | 
> L-1651 Luxembourg
> Phone: (+352) 2663 2661  <>| Fax: (+352) 2663 2665 <>
> Facebook  | Twitter 
> 
> 
> 

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] [Technical Errata Reported] RFC8910 (6620)

[Tommy Pauly]

> On Jun 23, 2021, at 8:42 AM, Michael Richardson  wrote:
> 
> 
> RFC Errata System  wrote:
>> -
>> In RFC8908 the relevant Content-Type is defined as
>> "application/captive+json" and not "application/capport+json".
> 
> Wow, thank god for the summary, and even with it, I had to read four times to
> really see the difference!
> 
> Sounds legit, and a great way to show off the XML patcher!

Yes, a definitely good fix to make. Let’s approve it.
> 
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>   Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Martin Duke's Discuss on draft-ietf-capport-architecture-09: (with DISCUSS and COMMENT)

[Tommy Pauly]

Hi Martin,

I think the DISCUSS indeed is resolved by the -09 version.

The text now says:

“At minimum, the API MUST provide the state of captivity. Further, the
   API MUST be able to provide a URI for the User Portal.”

That is in line with what the API document provides. It is *able* to provide a 
URI for a user portal, via the optional user-portal-url key. The API satisfies 
this requirement, and the requirement does not go as far as saying the value 
must always be provided—only that it is able to be provided.

Thanks,
Tommy

> On Aug 8, 2020, at 11:58 AM, Martin Duke via Datatracker  
> wrote:
> 
> Martin Duke has entered the following ballot position for
> draft-ietf-capport-architecture-09: 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/statement/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-capport-architecture/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> AFAICT this Discuss still applies to draft-09.
> 
> Sec 2.3  says:
> At minimum, the API MUST provide: (1) the state of captivity and (2) a URI for
> the Captive Portal Server.
> 
> But in section 5 of capport-api, user-portal-url is an optional field.
> 
> Both a capport-api author and a WG chair agreed that the architecture doc
> should be fixed, so I'm moving the DISCUSS here.
> 
> 
> --
> COMMENT:
> --
> 
> I found the terminology around “Captive Portal API server” and “Captive Portal
> Server” to be a little confusing, as these are similar terms. The latter also
> doesn’t get its own discussion in Section 2 and is confusingly called the “web
> portal server” in Figure 1.
> 
> After Figure 1, this seems to be consistently called the “web portal” (sec 2.6
> and 4). In the API doc it is called a "user portal." It would be great to 
> unify
> the terminology across the documents as a whole.
> 
> 
> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] CAPPORT support in iOS 14 and macOS Big Sur betas

[Tommy Pauly]

Hi Steve,

Glad you’re testing is going well so far.

> On Jul 7, 2020, at 6:03 AM, Steve Haskew  wrote:
> 
> Hi Tommy,
> 
> I have now been doing some testing of our solution with iOS 14 and it has 
> been fairly straightforward in getting it all working at a basic level!
> 
> I have a couple of observations/queries:
> 
> Just to confirm, are you not yet supporting any of the informational elements 
> (venue info URL, seconds remaining etc) since you say the user experience is 
> not changing? Despite setting these values I am not seeing any difference.

That’s expected. The iOS 14 beta doesn’t include any changes to the Wi-Fi 
settings. There are ways to check for the values being parsed in system logs if 
you want to confirm, however. 

> 
> Secondly I have on a few occasions been directed by probe instead of via the 
> API. I am working to replicate this with packet capture etc so that I can 
> determine whether it’s variation in my setup or any kind of bug, but it is 
> also likely just because I am repeatedly logging in and out and jumping on 
> and off the network in question! Do you know what the criteria is (timeout 
> values on the API request, any retries on the API request? etc.) for fallback 
> to probe method?

If you can submit a feedback/bug with system logs attached when you see this 
behavior, we can look into it. There are various error heuristics for when we 
fail to receive a valid API connection. Likely we’re hitting one of those, but 
it would be good to confirm which.

> 
> Thanks for your efforts in getting this implemented!

Thanks for implementing it too!

Best,
Tommy
> 
> Steve
> 
> 
> 
>> On 22 Jun 2020, at 22:30, Tommy Pauly  wrote:
>> 
>> 
>> Hello CAPPORT,
>> 
>> I wanted to highlight an announcement we’ve made for the betas of iOS and 
>> macOS released today:
>> 
>> How to modernize your captive network 
>> <https://developer.apple.com/news/?id=q78sq5rv>
>> 
>> The betas for iOS and macOS support both draft-ietf-capport-rfc7710bis and 
>> draft-ietf-capport-api by default. This doesn’t change the user experience 
>> of logging onto captive networks, but the system will request the DHCP 
>> options and handle the RA option, and will prefer using the Captive Portal 
>> API Server interaction over having a probe that is intercepted.
>> 
>> If you have a portal system that is already implementing the CAPPORT 
>> features, please test out these betas and let us know if you see any issues! 
>> And if you have a captive portal solution, we’d encourage you to start 
>> supporting this soon.
>> 
>> Best,
>> Tommy
>> 
> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] CAPPORT support in iOS 14 and macOS Big Sur betas

[Tommy Pauly]

> On Jul 2, 2020, at 11:55 AM, Michael Richardson  wrote:
> 
> 
> Not really a CAPPORT protocol problem... but...
> 
> Tommy Pauly  wrote:
>> One point I wanted to clarify: the iOS and macOS betas support for
>> CAPPORT discovery and APIs still goes through the standard and existing
>> UI flow for captive portals. The times in which the captive portal UI
>> is shown is limited, for example to times when the user is in WiFi
>> settings.
> 
> Is there a simple way for the user to get back to the portal page from the
> notification bar?  Can the user choose to keep it open longer?

One of the goals of having the portal URL be transmitted in the API is to aid 
ways of getting back to that URL. We don’t have any such way in the beta UI, 
but such an experience is possibility in the future if networks adopt the API.

Thanks,
Tommy

> 
> I noticed on the Thalys train that if you closed the portal page that it
> tended to kick you off the network.  That is definitely an anti-pattern!!!
> I don't know how we will cope with it, while at the same time, making it
> clear that it's a bad design.
> 
> Worse was that the portal page had a nice tiled map with the current
> location... AND THE TILES WERE NOT LOCAL.  So as more and more people learnt
> to keep the page open... the network got significantly slower.
> 
>> Thus, while adoption should indeed be easy and only require
>> adding a small bit of infrastructure in order to provide a flow that
>> doesn’t require redirects, the set of circumstances in which a network
>> can display content to the user is not increased.
> 
> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] CAPPORT support in iOS 14 and macOS Big Sur betas

[Tommy Pauly]

> On Jul 1, 2020, at 4:22 PM, Erik Kline  wrote:
> 
> +1
> 
> Out of curiosity, does the implementation handle the 7710bis options'
> urn:ietf:params:capport:unrestricted value?

That doesn’t yet stop us from sending out the probe, no. That can be something 
added later, based on how networks adopt it.

Thanks,
Tommy

> 
>> On Mon, Jun 22, 2020 at 5:00 PM Martin Thomson  wrote:
>> 
>> Tommy, this is great!  Thanks for all your work here, it's good to see this 
>> turn into something concrete.
>> 
>>> On Tue, Jun 23, 2020, at 07:30, Tommy Pauly wrote:
>>> Hello CAPPORT,
>>> 
>>> I wanted to highlight an announcement we’ve made for the betas of iOS
>>> and macOS released today:
>>> 
>>> How to modernize your captive network
>>> <https://developer.apple.com/news/?id=q78sq5rv>
>>> 
>>> The betas for iOS and macOS support both draft-ietf-capport-rfc7710bis
>>> and draft-ietf-capport-api by default. This doesn’t change the user
>>> experience of logging onto captive networks, but the system will
>>> request the DHCP options and handle the RA option, and will prefer
>>> using the Captive Portal API Server interaction over having a probe
>>> that is intercepted.
>>> 
>>> If you have a portal system that is already implementing the CAPPORT
>>> features, please test out these betas and let us know if you see any
>>> issues! And if you have a captive portal solution, we’d encourage you
>>> to start supporting this soon.
>>> 
>>> Best,
>>> Tommy
>>> ___
>>> Captive-portals mailing list
>>> Captive-portals@ietf.org
>>> https://www.ietf.org/mailman/listinfo/captive-portals
>>> 
>> 
>> ___
>> Captive-portals mailing list
>> Captive-portals@ietf.org
>> https://www.ietf.org/mailman/listinfo/captive-portals
> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

[Captive-portals] CAPPORT support in iOS 14 and macOS Big Sur betas

[Tommy Pauly]

Hello CAPPORT,

I wanted to highlight an announcement we’ve made for the betas of iOS and macOS 
released today:

How to modernize your captive network 


The betas for iOS and macOS support both draft-ietf-capport-rfc7710bis and 
draft-ietf-capport-api by default. This doesn’t change the user experience of 
logging onto captive networks, but the system will request the DHCP options and 
handle the RA option, and will prefer using the Captive Portal API Server 
interaction over having a probe that is intercepted.

If you have a portal system that is already implementing the CAPPORT features, 
please test out these betas and let us know if you see any issues! And if you 
have a captive portal solution, we’d encourage you to start supporting this 
soon.

Best,
Tommy___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Robert Wilton's No Objection on draft-ietf-capport-api-07: (with COMMENT)

[Tommy Pauly]

Hi Rob,

Thanks for the example text for user consent, etc. I believe that at this point 
in how the CAPPORT API will be used, the main way that personal information is 
transmitted is in the web portal. The privacy text in -08 was updated from the 
-07 version to not imply that it is the API JSON itself:

"Information passed between a client and the user-facing web portal may 
include a user's personal information…”

My interpretation of requirements like GDPR is that they’d be then applying to 
what shows on the web portal that the API server points to, at which point the 
consent and terms can and should be shown in a normal web page flow.

However, for future extensions to the CAPPORT API that could allow captive 
portal interaction without a webpage, but done more “automatically”, I do think 
this kind of text will be necessary. So, I think for now, we leave this for 
future updates?

Best,
Tommy

> On Jun 22, 2020, at 9:18 AM, Rob Wilton (rwilton) 
>  wrote:
> 
> Hi Tommy,
> 
> Just one (belated) comment at the end ...
> 
>>> 
>>> 7.1.  Privacy Considerations
>>> 
>>> Possibly worth adding a comment about the necessity to keep personal
>>> information secure.   In addition, should there be any comments about
>> GDPR like
>>> constraints (if they apply)?
>> 
>> This section has also be reworded slightly to make this more clear. I’m
>> not sure if there’s anything we can state for GDPR or similar constraints
>> here. I think that would mainly apply to what is shown in the user portal,
>> not the API interaction.
> [RW] 
> 
> FWIW, I saw this text in another document that I'm reviewing now, and is was 
> something along these lines that I was originally thinking of when I posted 
> the original comment:
> 
>   When sharing personally identifiable information or information that
>   is otherwise considered confidential to affected users, SET
>   Transmitters and Recipients MUST have the appropriate legal
>   agreements and user consent or terms of service in place.
>   Furthermore, data that needs confidentiality protection MUST be
>   encrypted, at least with TLS and sometimes also using JSON Web
>   Encryption (JWE) [RFC7516].
> 
>   In some cases, subject identifiers themselves may be considered
>   sensitive information, such that their inclusion within a SET may be
>   considered a violation of privacy.  SET Issuers should consider the
>   ramifications of sharing a particular subject identifier with a SET
>   Recipient (e.g., whether doing so could enable correlation and/or de-
>   anonymization of data) and choose appropriate subject identifiers for
>   their use cases.
> 
> I.e. if user identifiable information is being carried over the CAPPORT API, 
> then IANAL, etc, but I think that GDPR would require that the user had given 
> consent in some way before any personally identifiable information is 
> transmitted.
> 
> I'll leave it to you to decide if that is a valid consideration for the 
> privacy section.
> 
> Regards,
> Rob
> 
> 
>> 
>> Best,
>> Tommy
>>> 
>>> Thanks,
>>> Rob
>>> 
>>> 
>>> 
> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org 
> https://www.ietf.org/mailman/listinfo/captive-portals 
> 
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Magnus Westerlund's Discuss on draft-ietf-capport-api-07: (with DISCUSS)

[Tommy Pauly]

Hi Magnus,

I’ve published the proposed text in the -08 version of the draft: 

https://datatracker.ietf.org/doc/html/draft-ietf-capport-api 
<https://datatracker.ietf.org/doc/html/draft-ietf-capport-api>

Please take a look, and update your evaluation if it looks good!

Best,
Tommy

> On Jun 15, 2020, at 9:15 AM, Tommy Pauly  
> wrote:
> 
> Thanks all for the input. The text in our working copy now reads:
> 
> The API server endpoint MUST be accessed over HTTP using an https URI 
> {{!RFC2818}}, and SHOULD use the default https port.
> 
> (https://capport-wg.github.io/api/draft-ietf-capport-api.html#name-api-connection-details
>  
> <https://capport-wg.github.io/api/draft-ietf-capport-api.html#name-api-connection-details>)
> 
> 
>> On Jun 12, 2020, at 7:43 AM, Magnus Westerlund 
>> > <mailto:magnus.westerlund=40ericsson@dmarc.ietf.org>> wrote:
>> 
>> Hi,
>> 
>> I fully understand the simplicity from one perspective to not define the
>> version of HTTP. And I think the proposed language was an improvement. Using
>> default port I think has an advantage due to the multi transport protocol
>> nature we have here. 
>> 
>> On the question about versions I think it has likely interesting
>> implications for CAPPORT implementations. I expect that servers will
>> actually be deployed and potentially not be upgraded after having been
>> installed in a network over significant times in some cases. This will force
>> the clients to actually support the full set of HTTP protocols to support to
>> ensure interoperability over many networks. I guess this is similar for
>> other deployments of HTTP beyond the web. 
> 
> As a client implementer, I think this is both entirely standard and entirely 
> necessary. Any device that is currently interacting with a user-facing 
> captive portal needs to support generic browser-style webpages, which means 
> that support for older versions HTTP for compatibility reasons is a 
> necessity. I agree with Mark that the text here shouldn’t specify anything 
> about the wire format version, since it has no requirements on capabilities 
> specific to HTTP/2, HTTP/3, etc.
> 
> Best,
> Tommy
>> 
>> Cheers
>> 
>> Magnus Westerlund
>> 
>>> -Original Message-
>>> From: Mark Nottingham mailto:m...@mnot.net>>
>>> Sent: den 12 juni 2020 05:56
>>> To: Magnus Westerlund >> <mailto:magnus.westerl...@ericsson.com>>
>>> Cc: The IESG mailto:i...@ietf.org>>; 
>>> capport-cha...@ietf.org <mailto:capport-cha...@ietf.org>; captive-
>>> port...@ietf.org <mailto:port...@ietf.org>; Martin Thomson 
>>> mailto:m...@lowentropy.net>>; draft-ietf-
>>> capport-...@ietf.org <mailto:capport-...@ietf.org>
>>> Subject: Re: [Captive-portals] Magnus Westerlund's Discuss on draft-ietf-
>>> capport-api-07: (with DISCUSS)
>>> 
>>> Just jumping in here, apologies if I don't have all context:
>>> 
>>>> On 11 Jun 2020, at 11:38 pm, Magnus Westerlund via Datatracker
>>> mailto:nore...@ietf.org>> wrote:
>>>> 
>>>> First of all what is the intention of which HTTP version should be
>>>> supported here? And which protocol are the port 443 you are
>>>> recommending, TCP, UDP or SCTP? This also relates to HTTP/3 as it is
>>>> getting close to being published, we can expect that in the future maybe
>>> people would like to upgrade to HTTP/3.
>>> 
>>> It's generally bad practice for an API to specify a version of HTTP.
>>> 
>>>> Already now I am wondering if the written allow for HTTP/2 over
>>>> TLS/TCP? Note, that I am mostly commenting from the perspective if you
>>>> want to be specific that it is HTTP/1.1. over TLS/TCP that is the
>>>> goal. Then this document should make certain changes in the
>>>> formulation. If you want to be unspecific and don't think that will
>>>> hurt interoperability, then another formulation that the current is also
>>> needed.
>>> 
>>> I think what's desired is to say that the URL accessed must have a HTTPS
>>> scheme and a default port, not that communication happen over any specific
>>> wire format.
>>> 
>>>> Likely also a discussion about how a client will figure out what
>>>> versions are supported.
>>> 
>>> Why would it be different than any other use of HTTP?
>>> 
>>> Cheers,
>>> 
>>> --
>>> Mark Nottingham   https://protect2.fireeye.com/v1/url?k=3

Re: [Captive-portals] Roman Danyliw's Discuss on draft-ietf-capport-api-07: (with DISCUSS and COMMENT)

[Tommy Pauly]

Hi Roman,

I’ve published the working copy as the -08 version of the draft: 

https://datatracker.ietf.org/doc/html/draft-ietf-capport-api 
<https://datatracker.ietf.org/doc/html/draft-ietf-capport-api>

Please take a look, and update your evaluation if it looks good!

Best,
Tommy

> On Jun 11, 2020, at 12:14 PM, Roman Danyliw  wrote:
> 
> Hi Tommy!
>  
> The proposed edits in the working copy look good and address all of my 
> discuss and comments.  Thanks for making the changes.
>  
> Regards,
> Roman
>  
> From: Tommy Pauly  
> Sent: Wednesday, June 10, 2020 2:09 PM
> To: Roman Danyliw 
> Cc: The IESG ; draft-ietf-capport-...@ietf.org; 
> capport-cha...@ietf.org; captive-portals@ietf.org; Martin Thomson 
> 
> Subject: Re: Roman Danyliw's Discuss on draft-ietf-capport-api-07: (with 
> DISCUSS and COMMENT)
>  
> Hi Roman,
>  
> Thanks for your comments! I’ve updated our working copy with this commit:
>  
> https://github.com/capport-wg/api/commit/ef6f9afe84f2e49827560b5e2e8f292966107896
>  
> <https://github.com/capport-wg/api/commit/ef6f9afe84f2e49827560b5e2e8f292966107896>
>  
> The full editor’s copy can be viewed here:
>  
> https://capport-wg.github.io/api/draft-ietf-capport-api.html 
> <https://capport-wg.github.io/api/draft-ietf-capport-api.html>
> 
> 
> On Jun 9, 2020, at 7:51 PM, Roman Danyliw via Datatracker  <mailto:nore...@ietf.org>> wrote:
>  
> Roman Danyliw has entered the following ballot position for
> draft-ietf-capport-api-07: 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/statement/discuss-criteria.html 
> <https://www.ietf.org/iesg/statement/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-capport-api/ 
> <https://datatracker.ietf.org/doc/draft-ietf-capport-api/>
> 
> 
> 
> --
> DISCUSS:
> --
> 
> “Discuss discuss”.  Section 4 says “The API server endpoint MUST be accessed
> using HTTP over TLS (HTTPS) and SHOULD be served on port 443 [RFC2818].”  
> There
> is also various guidance on verifying the API server identity and access to
> revocation and time resources.  However, the way I read the definition of the
> “Captive Portal API Server” per Section 2 and per Figure 1 of
> draft-ietf-capport-architecture, the API server is logically different than 
> the
> service at the user-portal-url URL (i.e., Web Portal Server in the
> architecture).
> 
> Section 7.1 helpfully points out “Information passed between a client and a
> Captive Portal system may include a user's personal information, such as a 
> full
> name and credit card details.  Therefore, it is important that Captive Portal
> API Servers do not allow access to the Captive Portal API over unencrypted
> sessions.”  The first sentence is makes sense, but the second, while true,
> doesn’t follow the first for me.  PII and credit card information would be the
> kind of input you would provide to the _Web Portal Server_ not the Captive
> Portal API (of course both are part of the overall Captive Portal system).
>  
> This has been updated to:
>  
> Information passed between a client and the user-facing web portal may 
> include a user's personal information, such as a full name and credit card 
> details. Therefore, it is important that both the user-facing web portal and 
> the API server that points a client to the web portal are only accessed over 
> encrypted connections.
>  
> 
> 
>  I
> feel there is missing guidance roughly on the order of the user-portal-url
> “provides the URL of a web portal _that MUST be accessed over TLS_ with which 
> a
> user can interact.” (and the venue-info-url SHOULD use TLS too).
>  
> Good point. This was implicit in some of our text, but needed to be stated:
>  
> - "user-portal-url" (string): provides the URL of a web portal that MUST be 
> accessed over TLS with which a user can interact.
> - "venue-info-url" (string): provides the URL of a webpage or site that 
> SHOULD be accessed over TLS on which the operator of the network has 
> information that it wishes to share with the user (e.g., store info, maps, 
> flight status, or entertainment).
>  
> 
> 
> 
> Both this draft and draft-ietf-capport-rfc7710bis-07 are fundamentally

Re: [Captive-portals] Magnus Westerlund's Discuss on draft-ietf-capport-api-07: (with DISCUSS)

[Tommy Pauly]

Thanks all for the input. The text in our working copy now reads:

The API server endpoint MUST be accessed over HTTP using an https URI 
{{!RFC2818}}, and SHOULD use the default https port.

(https://capport-wg.github.io/api/draft-ietf-capport-api.html#name-api-connection-details
 
)


> On Jun 12, 2020, at 7:43 AM, Magnus Westerlund 
>  wrote:
> 
> Hi,
> 
> I fully understand the simplicity from one perspective to not define the
> version of HTTP. And I think the proposed language was an improvement. Using
> default port I think has an advantage due to the multi transport protocol
> nature we have here. 
> 
> On the question about versions I think it has likely interesting
> implications for CAPPORT implementations. I expect that servers will
> actually be deployed and potentially not be upgraded after having been
> installed in a network over significant times in some cases. This will force
> the clients to actually support the full set of HTTP protocols to support to
> ensure interoperability over many networks. I guess this is similar for
> other deployments of HTTP beyond the web. 

As a client implementer, I think this is both entirely standard and entirely 
necessary. Any device that is currently interacting with a user-facing captive 
portal needs to support generic browser-style webpages, which means that 
support for older versions HTTP for compatibility reasons is a necessity. I 
agree with Mark that the text here shouldn’t specify anything about the wire 
format version, since it has no requirements on capabilities specific to 
HTTP/2, HTTP/3, etc.

Best,
Tommy
> 
> Cheers
> 
> Magnus Westerlund
> 
>> -Original Message-
>> From: Mark Nottingham mailto:m...@mnot.net>>
>> Sent: den 12 juni 2020 05:56
>> To: Magnus Westerlund > >
>> Cc: The IESG mailto:i...@ietf.org>>; capport-cha...@ietf.org 
>> ; captive-
>> port...@ietf.org ; Martin Thomson 
>> mailto:m...@lowentropy.net>>; draft-ietf-
>> capport-...@ietf.org 
>> Subject: Re: [Captive-portals] Magnus Westerlund's Discuss on draft-ietf-
>> capport-api-07: (with DISCUSS)
>> 
>> Just jumping in here, apologies if I don't have all context:
>> 
>>> On 11 Jun 2020, at 11:38 pm, Magnus Westerlund via Datatracker
>>  wrote:
>>> 
>>> First of all what is the intention of which HTTP version should be
>>> supported here? And which protocol are the port 443 you are
>>> recommending, TCP, UDP or SCTP? This also relates to HTTP/3 as it is
>>> getting close to being published, we can expect that in the future maybe
>> people would like to upgrade to HTTP/3.
>> 
>> It's generally bad practice for an API to specify a version of HTTP.
>> 
>>> Already now I am wondering if the written allow for HTTP/2 over
>>> TLS/TCP? Note, that I am mostly commenting from the perspective if you
>>> want to be specific that it is HTTP/1.1. over TLS/TCP that is the
>>> goal. Then this document should make certain changes in the
>>> formulation. If you want to be unspecific and don't think that will
>>> hurt interoperability, then another formulation that the current is also
>> needed.
>> 
>> I think what's desired is to say that the URL accessed must have a HTTPS
>> scheme and a default port, not that communication happen over any specific
>> wire format.
>> 
>>> Likely also a discussion about how a client will figure out what
>>> versions are supported.
>> 
>> Why would it be different than any other use of HTTP?
>> 
>> Cheers,
>> 
>> --
>> Mark Nottingham   https://protect2.fireeye.com/v1/url?k=3a8ff1cb- 
>> 
>> 642f338e-3a8fb150-86b568293eb5-26a118f7c2d94334=1=d25e7a4c-
>> f7e3-4e34-a054-2498def27e05=https%3A%2F%2Fwww.mnot.net 
>> %2F
> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org 
> https://www.ietf.org/mailman/listinfo/captive-portals 
> 
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Magnus Westerlund's Discuss on draft-ietf-capport-api-07: (with DISCUSS)

[Tommy Pauly]

> On Jun 11, 2020, at 6:38 AM, Magnus Westerlund via Datatracker 
>  wrote:
> 
> Magnus Westerlund has entered the following ballot position for
> draft-ietf-capport-api-07: 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/statement/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-capport-api/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> Section 4.1:
> 
>   The API server endpoint MUST be accessed using HTTP over TLS (HTTPS)
>   and SHOULD be served on port 443 [RFC2818].
> 
> I have another reason than Roman to discuss this particular sentence.
> 
> First of all what is the intention of which HTTP version should be supported
> here? And which protocol are the port 443 you are recommending, TCP, UDP or
> SCTP? This also relates to HTTP/3 as it is getting close to being published, 
> we
> can expect that in the future maybe people would like to upgrade to HTTP/3.
> Already now I am wondering if the written allow for HTTP/2 over TLS/TCP? Note,
> that I am mostly commenting from the perspective if you want to be specific
> that it is HTTP/1.1. over TLS/TCP that is the goal. Then this document should
> make certain changes in the formulation. If you want to be unspecific and 
> don't
> think that will hurt interoperability, then another formulation that the
> current is also needed. Likely also a discussion about how a client will 
> figure
> out what versions are supported.

This is an interesting point. In my interpretation, this text does apply to 
HTTP/1.1 over TLS/TCP,
HTTP/2 over TLS/TCP, and HTTP/3 over QUIC (which uses TLS for encryption, still 
uses port 443,
and still maintains the URI scheme of https://).

> 
> And maybe one of the ART ADs can help untangle if RFC 2818 really is the right
> normative reference here? Or if it should be RFC 7230 and possibly additional
> references for HTTP/2?

Looking at RFCs like the one for DoH, 
https://www.rfc-editor.org/rfc/rfc8484.html 
, RFC 2818 is still
the reference for https:

over HTTP
   [RFC7540] using https [RFC2818] URIs (and therefore TLS [RFC8446]
   security for integrity and confidentiality).

My suggestion is that we can reword the sentence in question here to:

  The API server endpoint MUST be accessed over HTTP using an https URI 
[RFC2818],
  and SHOULD be served on port 443.

Does that work for everyone?

Thanks,
Tommy

> 
> 
> 
> 
> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Robert Wilton's No Objection on draft-ietf-capport-api-07: (with COMMENT)

[Tommy Pauly]

Hi Rob,

Thanks for the review!

Responses inline. You can also see updates in our working copy here:

https://capport-wg.github.io/api/draft-ietf-capport-api.html

> On Jun 11, 2020, at 4:17 AM, Robert Wilton via Datatracker  
> wrote:
> 
> Robert Wilton has entered the following ballot position for
> draft-ietf-capport-api-07: No Objection
> 
> 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/statement/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-capport-api/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Hi,
> 
> I found this document straight forward and easy to read.
> 
> Linda's comment in the Opsdir review is interesting.  I would have expected 
> the
> CAPPORT architecture document to discuss/reference the problem being solved,
> but it seems to be mostly silent on this.  I will redirect Linda's comment to
> the CAPPORT architecture.
> 
> In section 5. "API State Structure", it does not state whether a connection
> could be both time and data limited.  My reading of the spec is that this 
> would
> be allowed, assuming that is the case, the current text is fine.

Correct, there is no requirement that time and data limits are mutually 
exclusive.
> 
> 6.  Example Interaction
> 
>   Upon receiving this information the client will use this information
>   direct the user to the the web portal (as specified by the user-
>   portal-url value) to enable access to the external network.  Once the
>   user satisfies the requirements for extenal network access, the
>   client SHOULD query the API server again to verify that it is no
>   longer captive.
> 
> Nit: information direct => information to direct

Fixed on latest working copy.
> 
> 7.  Security Considerations
> 
> I'm slightly concerned about the third paragraph in the security
> considerations.  Ideally I would like a solution that doesn't require humans 
> to
> potentially spot potentially dubious spoofed domain names.  But I can
> appreciate that is probably out of scope here.

This has been removed and reworded in our working copy, from addressing Ben’s 
comments.
> 
> 7.1.  Privacy Considerations
> 
> Possibly worth adding a comment about the necessity to keep personal
> information secure.   In addition, should there be any comments about GDPR 
> like
> constraints (if they apply)?

This section has also be reworded slightly to make this more clear. I’m not 
sure if there’s anything we can state for GDPR or similar constraints here. I 
think that would mainly apply to what is shown in the user portal, not the API 
interaction.

Best,
Tommy
> 
> Thanks,
> Rob
> 
> 
> 

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Roman Danyliw's Discuss on draft-ietf-capport-api-07: (with DISCUSS and COMMENT)

[Tommy Pauly]

Hi Roman,

Thanks for your comments! I’ve updated our working copy with this commit:

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


The full editor’s copy can be viewed here:

https://capport-wg.github.io/api/draft-ietf-capport-api.html 


> On Jun 9, 2020, at 7:51 PM, Roman Danyliw via Datatracker  
> wrote:
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-capport-api-07: 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/statement/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-capport-api/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> “Discuss discuss”.  Section 4 says “The API server endpoint MUST be accessed
> using HTTP over TLS (HTTPS) and SHOULD be served on port 443 [RFC2818].”  
> There
> is also various guidance on verifying the API server identity and access to
> revocation and time resources.  However, the way I read the definition of the
> “Captive Portal API Server” per Section 2 and per Figure 1 of
> draft-ietf-capport-architecture, the API server is logically different than 
> the
> service at the user-portal-url URL (i.e., Web Portal Server in the
> architecture).
> 
> Section 7.1 helpfully points out “Information passed between a client and a
> Captive Portal system may include a user's personal information, such as a 
> full
> name and credit card details.  Therefore, it is important that Captive Portal
> API Servers do not allow access to the Captive Portal API over unencrypted
> sessions.”  The first sentence is makes sense, but the second, while true,
> doesn’t follow the first for me.  PII and credit card information would be the
> kind of input you would provide to the _Web Portal Server_ not the Captive
> Portal API (of course both are part of the overall Captive Portal system).

This has been updated to:

Information passed between a client and the user-facing web portal may include 
a user's personal information, such as a full name and credit card details. 
Therefore, it is important that both the user-facing web portal and the API 
server that points a client to the web portal are only accessed over encrypted 
connections.


>  I
> feel there is missing guidance roughly on the order of the user-portal-url
> “provides the URL of a web portal _that MUST be accessed over TLS_ with which 
> a
> user can interact.” (and the venue-info-url SHOULD use TLS too).

Good point. This was implicit in some of our text, but needed to be stated:

- "user-portal-url" (string): provides the URL of a web portal that MUST be 
accessed over TLS with which a user can interact.
- "venue-info-url" (string): provides the URL of a webpage or site that SHOULD 
be accessed over TLS on which the operator of the network has information that 
it wishes to share with the user (e.g., store info, maps, flight status, or 
entertainment).


> 
> Both this draft and draft-ietf-capport-rfc7710bis-07 are fundamentally
> providing pointers to other resources.  Would it be out of scope for this
> document to place restrictions on what the API is capable of pointing to?  If
> not here, then where?
> 
> 
> --
> COMMENT:
> --
> 
> Thanks for describing the protocol interaction within the reference
> architecture of draft-ietf-capport-architecture.
> 
> ** Ben points to a few places to tighten up the TLS mechanics (e.g.,
> referencing BCP195, non-OCSP stapling revocation) which I won't repeat here. 
> These are important.

Indeed. Please see responses to Ben’s comments.
> 
> ** Are there any retry behavior to specify for the client?  Say the client
> tries to the visit the API URL and the server returns an HTTP 500 error? Or,
> the API server doesn’t respond at all?

I’ve added this text to clarify:

Client behavior for issuing requests for updated JSON content is 
implementation-specific, and can be based on user interaction or the 
indications of seconds and bytes remaining in a given session. If at any point 
the client does not receive valid JSON content from the API server, either due 
to an error or due to receiving no response, the client SHOULD continue to 
apply the most recent valid content it had received; or, if no content had been 
received previously, proceed to interact with the captive 

Re: [Captive-portals] Benjamin Kaduk's No Objection on draft-ietf-capport-api-07: (with COMMENT)

[Tommy Pauly]

Hi Ben,

Thanks as always for your detailed comments. I’ve updated our working copy with 
this commit:

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


The full editor’s copy can be viewed here:

https://capport-wg.github.io/api/draft-ietf-capport-api.html 


> On Jun 9, 2020, at 12:16 PM, Benjamin Kaduk via Datatracker 
>  wrote:
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-capport-api-07: No Objection
> 
> 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/statement/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-capport-api/
> 
> 
> 
> --
> COMMENT:
> --
> 
> I'll start off with a handful of high-level comments, some of which
> might qualify for Discuss-level points, but which have obvious
> resolution and for which I trust the authors and AD to do the right
> thing.
> 
> JSON only has Numbers, not integers; Section 5 should not describe
> fields as integers without additional clarification (e.g., "integer,
> represented as a JSON Number").

Fixed to mark this as a number, and mention that it is an integer in the 
description.
> 
> Also, the GET example in Section 6 seems to be malformed, not specifying
> an HTTP-version.

Fixed!

> 
> I also think we should go into more detail on the TLS usage, pulling in
> the relevant preexisting IETF BCP and proposed standards to take
> advantage of the current state of the art (details in the
> section-by-section comments).

Indeed! Replied in individual comments.
> 
> Additionally, I note some places in the section-by-section comments
> where we can go into more detail on the "chain of custody" of
> information presented to the user, making sure that we keep a trusted
> path from initial provisioning through to API server access and captive
> portal server access.  There are some places where we don't seem to have
> a 100% airtight solution, and those gaps can be called out more clearly.

I’ve tried to tighten this text throughout. Comments inline.
> 
> Abstract
> 
>   with a Captive Portal system.  With this API, clients can discover
>   how to get out of captivity and fetch state about their Captive
>   Portal sessions.
> 
> The architecture document only implicitly talks about "Captive Portal
> sessions" (one mention in passing of when the "end of a session is
> imminent").  Should it have more text introducing the term/topic?

Opened an issue on the architecture: 
https://github.com/capport-wg/architecture/issues/92

> 
> Also, the architecture doc talks about learning the "state of
> captivity", but this formulation implies that there might be a much
> richer state to learn about.

Opened an issue on the architecture: 
https://github.com/capport-wg/architecture/issues/93

> 
> Section 1
> 
>   *  A URI that a client browser can present to a user to get out of
>  captivity
> 
> nit: this feels worded oddly to me; merely presenting (displaying?) a
> URI to the user does not help to do anything to get out of captivity.
> Presenting the dereferenced content referred to by that URI might be
> more effective at it, but would still require user action...

Reworded to: "A URI of a user-facing web portal that can be used to get out of 
captivity"
> 
>   *  An encrypted connection (using TLS for connections to both the API
>  and user portal)
> 
> I think "authenticated" is equally as important as "encrypted" and
> should be mentioned alongside it.

Reworded to: "Authenticated and encrypted connections, using TLS for 
connections to both the API and user-facing web portal"
> 
> Section 3
> 
>   2.  API Server interaction, in which a client queries the state of
>   the captive portal and retrieves the necessary information to get
>   out of captivity.
> 
> I may be overly tied to this "state of captivity" phrase, but is there a
> need to use "state" in a different formulation here?

Made consistent as “state of captivity"
> 
> Section 4
> 
>   For example, if the Captive Portal API server is hosted at
>   "example.org", the URI of the API could be "https://example.org/
>   captive-portal/api"
> 
> The architectures says that "the URIs provided in the API SHOULD be
> unique to the UE and not dependent on contextual information to function
> correctly."  I guess this is referring to the contents of the resource
> retrieved by dereferencing the URI of the API and not the URI 

Re: [Captive-portals] Murray Kucherawy's No Objection on draft-ietf-capport-api-07: (with COMMENT)

[Tommy Pauly]

Hi Murray,

Thanks for the review! Some comments inline.

> On May 13, 2020, at 12:45 AM, Murray Kucherawy via Datatracker 
>  wrote:
> 
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-capport-api-07: No Objection
> 
> 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/statement/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-capport-api/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Nice work.
> 
> A couple of points on the IANA registrations:
> 
> Section 8.1: The "Interoperability Considerations" text isn't quite what I
> think is anticipated by RFC 6838.  Given what you're saying there against what
> Section 6.2 of that document says, I think you could just have "None" here, 
> but
> either way I suggest it's worth a second look.

This is boilerplate text that we lifted from other RFCs with similar forms (RFC 
8460, RFC 8427). I’m fine with this being “None” as well, if that’s the general 
guidance.
> 
> Section 8.2: I suggest either having a column dedicated to recording the
> specification (since the Designated Expert is supposed to ensure there is 
> one),
> or explicitly encourage that it be referenced in the Description column.

That's a great point. I’ve added this to our working copy in GitHub:

https://github.com/capport-wg/api/commit/67fe784f0cb2883367a46da740378338ecf84805
 


Thanks,
Tommy
> 
> 
> 

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Martin Duke's No Objection on draft-ietf-capport-api-07: (with COMMENT)

[Tommy Pauly]

Hi Martin,

Thanks for the updated review. I’ve incorporated these comments in our GitHub:

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


Thanks,
Tommy

> On Jun 8, 2020, at 8:08 AM, Martin Duke via Datatracker  
> wrote:
> 
> Martin Duke has entered the following ballot position for
> draft-ietf-capport-api-07: No Objection
> 
> 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/statement/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-capport-api/
> 
> 
> 
> --
> COMMENT:
> --
> 
> This document is clearly written. Thanks.
> 
> I am also confused by this sentence at the end of section 4.1 about failed
> authentication: “It may still be possible for the user to access the network 
> by
> being redirected to a web portal.”
> 
> I suggest “...access the network by redirecting a clear text webpage to a web
> portal.”  I was a bit confused by the original wording.
> 
> As I said in the architecture review, the term for the user portal keeps
> changing. Over there it’s called a “Captive Portal Server” and a “web portal
> server”. Here it’s a “user-portal.” The authors of the two docs should get
> together and agree on a term.
> 
> One nit:
> s/extenal/external
> 
> 
> 

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Martin Duke's Discuss on draft-ietf-capport-api-07: (with DISCUSS and COMMENT)

[Tommy Pauly]

Hi Martin,

Thanks for the review. Responses inline. 

> On Jun 6, 2020, at 2:49 PM, Martin Duke via Datatracker  
> wrote:
> Martin Duke has entered the following ballot position for
> draft-ietf-capport-api-07: 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/statement/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-capport-api/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> Unless I am misinterpreting the language here, there is a disconnect between
> this document and the architecture document.
> 
> Sec 2.3 of -architecture says:
> At minimum, the API MUST provide: (1) the state of captivity and (2) a URI for
> the Captive Portal Server.
> 
> But in section 5 user-portal-url is an optional field. Is -architecture
> actually levying a requirement on the api spec, or the api server?

I believe in this case the architecture document needs to change, or clarify 
that this MUST refers to that the mechanism needs to be *able* to communicate 
such a URI, not that such a URI must always be communicated.

The group has discussed this several times, and I believe the API doc reflects 
the consensus: while we aren’t tackling solutions for captive portals that 
don’t involve User Portal pages (future solutions using a more OS-driven 
experience and perhaps built in payment, etc), we want to allow the API JSON to 
be usable in those new models. Not all captive networks will necessarily use 
this kind of URI in the future, and there’s no need to make the registry lock 
that in as mandatory. 

> 
> I am also confused by this sentence at the end of section 4.1 about failed
> authentication: “It may still be possible for the user to access the network 
> by
> being redirected to a web portal.”
> 
> Who is doing the redirecting here? If authentication has failed, how is this
> redirect authenticated and secure against theft of credentials?

This is referring to the fact that the old HTTP redirect of a clear text 
webpage may still happen on a network. Even networks that support the API will 
need to handle legacy clients. This is only about redirecting unrelated pages 
to the user portal, and is orthogonal to the authenticity of the API server. 
> 
> 
> --
> COMMENT:
> --
> 
> This document is otherwise clearly written. Thanks.
> 
> As I said in the architecture review, the term for the user portal keeps
> changing. Over there it’s called a “Captive Portal Server” and a “web portal
> server”. Here it’s a “user-portal.”

User-portal is indeed the key name, representing the current use case of 
presenting a portal to a user. Other solutions in the future may use other 
URIs. In description text, we explain that this is a web portal page. I’d 
suggest using the user portal term in the architecture. 


> 
> One nit:
> s/extenal/external

Good catch, will fix. 

Tommy
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Secdir last call review of draft-ietf-capport-rfc7710bis-04

[Tommy Pauly]

Hi Rifaat,

Your comments make it clear that the recommendation to make the API server name 
visible isn’t necessarily clear. I think it’s not a harmful thing to show, as a 
way to give troubleshooting information and transparency to the user, but it is 
not a security-critical point.

It seems appropriate to either explain the rationale more in depth, or remove 
that sentence entirely to avoid the misinterpretation.

Do others in the CAPPORT group have thoughts on this sentence, and any 
background on why we decided to go that way? Would there be any objections to 
removing the sentence?

Thanks,
Tommy

> On Jun 1, 2020, at 6:05 PM, Rifaat Shekh-Yusef  
> wrote:
> 
> 
> 
> 
>> On Sun, May 31, 2020 at 2:07 AM Erik Kline  wrote:
>> On Wed, May 20, 2020 at 4:37 AM Rifaat Shekh-Yusef
>>  wrote:
>> >
>> > Adding SecDir back to this thread.
>> >
>> >
>> > >Martin Thomson  Tue, 19 May 2020 01:02 UTCShow header
>> > >
>> > >On Tue, May 19, 2020, at 07:08, Rifaat Shekh-Yusef wrote:
>> > >>it provides the client of the API
>> > >>an opportunity to authenticate the server that is hosting the API..
>> > >>This authentication is aimed at *allowing a user to be reasonably
>> > >>confident that the entity providing the Captive Portal API has a
>> > >>valid certificate for the hostname in the URI*
>> > >[...]
>> > >> An end user should be able to validate that the name is example.com and
>> > >> not any other form of the URI.
>> > >> It would be much more difficult for the end user to make sense and
>> > >> validate an IP address.
>> > >
>> > >I think that you missed the point of my comments.  This validation, 
>> > >performed by
>> > >a user, has no meaningful security value.  The text you cite says that 
>> > >the server
>> > >has a certificate for the name it chooses, which is not the same as "has 
>> > >a certificate
>> > >for a name the client expects".  The difference is important.
>> > >
>> >
>> > This is not the way I read these statements from section 4.1 titled Server 
>> > Authentication.
>> >
>> > Here is the use case I have in mind when I read this section:
>> > If I walk into an airport and I see an ad for a paid Internet service from 
>> > example.com, then as an
>> > end user it is reasonable to expect that I would have some ability to make 
>> > sense of the name
>> > presented to me and make sure it is from example.com if I choose to get 
>> > such a service.
>> >
>> > If this is not the case, then yo might want to make it clear that this is 
>> > not about Server Authentication
>> > as the title of the section and the text inside that section is suggesting.
>> 
>> If we changed the API document's section 4.1 title from "Server
>> Authentication" to "API Server Authentication", would that be more
>> clear?
>> 
>> I reality, users should never see the API URL. 
> 
> The following is a quote from section 4.1 of the API document, which implies 
> otherwise:
> "The hostname of the API SHOULD be displayed to the user in order to indicate 
> the entity which is providing the API service."
>  
> Regards,
>  Rifaat
> 
> 
>  
>> They'll just be
>> connecting to "Cool Cafe" or "Awesome Bookshop" ESSIDs.  If anything
>> will only be one or both of the "user-portal-url" or "venue-info-url"
>> URLs that might be visible in the browser that's opened for the user's
>> interaction.
>> 
>> -ek
>> 
>> > Regards,
>> >  Rifaat
>> >
>> >
>> >
>> > >In a typical web scenario, a person types a string in and (ignore the 
>> > >case where there
>> > >is an extra hop via a search engine) that string determines what is 
>> > >acceptable as a
>> > >server identity.  The exposure to confusables is limited (under a set of 
>> > >other assumptions,
>> > >HSTS, etc...).  Here, the network has free reign to do as they choose 
>> > >with homoglyphs and
>> > >other such nonsense.  Any expectation you might have about this really 
>> > >being a trustworthy
>> > >entity is meaningless in this context.
>> > >
>> > >There are protections against this, but they all lie firmly in the 
>> > >anti-phishing domain.
>> > >Most of those rely on having a certificate though, so the requirement for 
>> > >HTTPS is in
>> > >service of that, not in terms of ensuring that an untrained human can 
>> > >make a security
>> > >critical decision based on poisoned information.
>> >
>> > On Mon, May 18, 2020 at 5:08 PM Rifaat Shekh-Yusef 
>> >  wrote:
>> >>
>> >> Adding Ben.
>> >>
>> >>
>> >> On Sun, May 17, 2020 at 9:26 PM Martin Thomson  
>> >> wrote:
>> >>>
>> >>> Adding more lists..
>> >>>
>> >>> On Sun, May 17, 2020, at 02:50, Rifaat Shekh-Yusef wrote:
>> >>> > > Here is a quote form the API document:
>> >>> > > "The hostname of the API SHOULD be displayed to the user in order to 
>> >>> > > indicate the entity which is providing the API service."
>> >>> > >
>> >>> > > This seems to suggest that the user is expected to inspect the 
>> >>> > > displayed name and make sure it is make sense in the context of 
>> >>> > > whoever is 

Re: [Captive-portals] Opsdir last call review of draft-ietf-capport-api-07

[Tommy Pauly]

Hi Linda,

Thanks for reviewing the document.

For background on how the architecture defined by the CAPPORT WG is preferable 
to the non-standard mechanisms in deployment today, I’d like to point you to 
one of the documents referenced by the API document, 
draft-ietf-capport-architecture 
(https://tools.ietf.org/html/draft-ietf-capport-architecture).

There are several benefits, grouping roughly as follows:

- Security: Generally, solutions today require interception of DNS and 
redirecting HTTP responses, and incompatibility with TLS or attempts to 
man-in-the-middle TLS.
- Privacy: Captive networks usually rely on intercepting “user” traffic, which 
means a device may try to send traffic with user-sensitive names on a network 
and only later realize it is captive and the results are bogus.
- Functionality: Solutions today do not have a way to communicate time 
remaining to devices or how to extend a session, so association is often cut 
off abruptly.
- Consistency and early detection: There isn’t any standard way for a client 
device to detect that it is captive today, and there is a large variety in the 
way networks implement this, leading to inconsistency in user experience and 
timing.

Best,
Tommy

> On May 9, 2020, at 3:06 PM, Linda Dunbar via Datatracker  
> wrote:
> 
> Reviewer: Linda Dunbar
> Review result: Has Nits
> 
> I have reviewed this document as part of the Ops area directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the Ops area directors.
> Document editors and WG chairs should treat these comments just like any other
> last call comments.
> 
> This document provides examples of the API structure between client and 
> captive
> server. The document is well written. I just have a question:
> 
> What improvement does the proposed API have over today's existing 
> communication
> between clients and  Captive Server(s)? Captive servers have been deployed
> everywhere, like airport or restaurants trying to access free WIFI. What
> problems does the existing method have to justify this newly proposed APIs?
> 
> Cheers,
> Linda Dunbar
> 
> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Genart last call review of draft-ietf-capport-api-07

[Tommy Pauly]

Hi Brian,

Thanks for the review! I’ve updated our working copy to fix the nits you 
mention:

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

> On May 3, 2020, at 9:29 PM, Brian Carpenter via Datatracker 
>  wrote:
> 
> Reviewer: Brian Carpenter
> Review result: Ready with Nits
> 
> https://www.ietf.org/id/draft-ietf-capport-api-07.html
> 
> Gen-ART Last Call review of draft-ietf-capport-api-07
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> .
> 
> Document: draft-ietf-capport-api-07.html
> Reviewer: Brian Carpenter
> Review Date: 2020-05-04
> IETF LC End Date: 2020-05-11
> IESG Telechat date:  
> 
> Summary: Ready (almost...)
> 
> 
> Minor Issue:
> 
> 
>> If the client is captive (i.e. captive=true),
>> it can still be allowed enough access for it to perform server
>> authentication Section 4.1.
> 
> What does "can" mean? MAY or perhaps SHOULD? Is this a local policy decision?

Changed this to “will”. This does not need to be a normative claim here, as it 
is simply describing what the server deployment will do based on the referenced 
section.
> 
> Nit:
> 
> 
>> If the client is captive (i.e. captive=true),
>> it can still be allowed enough access for it to perform server
>> authentication Section 4.1.
> 
> Missing parentheses around "Section 4.1"?

Fixed!

Best,
Tommy
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] AD review of draft-ietf-capport-architecture-07

[Tommy Pauly]

> On Apr 27, 2020, at 7:21 AM, Barry Leiba  wrote:
> 
> Thanks for the reply, Dave, and I think we're OK to start last call on
> the document after you post a revised I-D with the changes so far --
> most unresolved things are not at a blocking level.  Just one thing
> I'd like to push on before you revise the I-D, though:
> 
>>> Please be consistent about using “URI”, and not “URL”.
>> 
>> Changed all URI to URL in commit
>> https://github.com/capport-wg/architecture/commit/a9c87ba48aa64564bd9d0e1f21bd82906a2714f4
> 
> But that's backward: the IETF formally defines "URI" [RFC3986], not
> "URL", and that document says [Section 1.1.3]:
> 
>   Future specifications and related documentation should
>   use the general term "URI" rather than the more restrictive terms
>   "URL" and "URN"
> 
> (Additionally, we should probably include an informative reference to
> 3986 on first use of the term.)
> 
> If the working group really wants "URL" here I won't block it further,
> but I would strongly prefer that we use "URI", consistent with IETF
> usage.

FWIW, the API document uses “URI” everywhere other than in its JSON keys. I’d 
agree that the architecture document should use URI as well.

Thanks,
Tommy
> 
> ---
> 
> Collecting the other points that aren't resolved, but that need not
> block last call:
> 
>>> General:
>>> Expect comments during IESG Evaluation about the extensive use of BCP
>>> 14 key words in an Informational document.  I don’t object to it here,
>>> though I do find all the “MAY”s odd (example: “A device MAY query this
>>> API at any time”, rather than “A device may query this API at any
>>> time”), but I do expect some ADs to comment on it.
>> 
>> I've reviewed all upper-case "MAY", and I believe they are used as
>> intended.  We've allowed the user equipment to participate or not in various 
>> ways.
> 
> OK, then no more to do here.  This was mostly just a note that I
> expect to see comments, and not an expectation of any changes to the
> document.  Thanks for checking.
> 
>>> — Section 2.3 —
>>> 
>>>   The API SHOULD provide evidence
>>>   to the caller that it supports the present architecture.
>>> 
>>> I don’t understand what this means; can you explain?
>> 
>> To me, this means that User Equipment can determine from the
>> interaction that the API is implementing this architecture vs.
>> being some random API. I imagine that a version number or content-
>> type could achieve this.
>> 
>> I've opened https://github.com/capport-wg/architecture/issues/61
>> to track the issue.
> 
> OK.  A small wording tweak will be good at some point, but let's see
> if anyone else raises this point in reviews.
> 
>>> — Section 3.3 —
>>> Are we really talking about evaluating individual identifiers here?
>>> Or does this really mean to discuss *methods* of generating or
>>> choosing identifiers?
>> 
>> I believe this is about choice of identifier in a solution/standard.
>> 
>> Opened issue https://github.com/capport-wg/architecture/issues/62
> 
> Great; again, a small wording tweak will do it.
> 
>>> — Section 3.4.3 —
>>> Is this section talking about using a context-free URI as a UEe
>>> identifier?  It should be clearer about that, if so (and if that’s not
>>> what it’s about, the section is misplaced).  There’s nothing in here
>>> that discusses how such identifiers would meet the specified criteria.
>> 
>> I think this is trying to say the server should not be looking at
>> Ethernet addresses, for example, because the server is probably not
>> on the same subnet as the User Equipment. So the info needs to be
>> in the URL.
>> 
>> I hope others can weigh in on this. Created issue
>> https://github.com/capport-wg/architecture/issues/63
> 
> To be clear here, I'm not concerned about the content of the section
> as such, only about how it fits into the topic of identifier
> selection.  So I think it's just a matter of clarifying that, and it
> should be easy to deal with by the time last call ends.
> 
> Barry
> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] AD review of draft-ietf-capport-api-06

[Tommy Pauly]

Hi Barry,

Thanks for the review! Update made here:

 
https://github.com/capport-wg/api/commit/27cd22fd8a8db696efb9772acd6c05d24a86c81d
 


This has been posted as draft-ietf-capport-api-07: 
https://tools.ietf.org/html/draft-ietf-capport-api-07 


> On Apr 23, 2020, at 10:03 PM, Barry Leiba  wrote:
> 
> Thanks for a nice document.  Here’s my AD review prior to last call.  For a 
> few reasons, I think we need a revised I-D before going to last call.
> 
> — Section 2 —
> 
>*  Captive Portal API Server: The server exposing the API's defined
> 
> Nit: no apostrophe should be in “APIs” (it’s not possessive).

Fixed
> 
> This section also needs BCP 14 boilerplate (and the document needs normative 
> references to RFCs 2119 and 8174), as Sections 4 and 5 use BCP 14 key words.

Added
> 
> — Section 3 —
> I think 7710bis is an informative reference, not a normative one.

Changed to informative.
> 
> — Section 4.1 —
> 
>valid certificate for the hostname in the URI (such as
>"example..com ").
> 
> It’s a small point, and not wrong as written, but as there is an example 
> already given right above at the end of Section 4, I suggest referring to it:
> 
> NEW
>valid certificate for the hostname in the URI
>("example.org ", in the example above).
> END

Changed as suggested.
> 
> — Section 5 —
> 
> In the bullet about seconds-remaining:
> 
>   The API server SHOULD include this value if the client is
>   not captive (i.e. captive=false) and the client session is time-
>   limited, and SHOULD omit this value for captive clients (i.e.
>   captive=true).
> 
> What about captive=false and the client is not time-limited?  I think you 
> want, “and SHOULD omit this value value for captive clients (i.e. 
> captive=true) or when the client sessiin is not time-limited.”  Or, simpler 
> and better, “and SHOULD omit this value otherwise.”
> 
> And similarly for the next bullet about bytes-remaining.

Changed for both cases.
> 
> — Section 6 —
> The example violates the SHOULD in Section 5, “seconds-remaining”.  That’s 
> not a good idea.  It might be good to have two examples, one with 
> captive=true and one with captive=false.

Split the server response example into two.

> 
>Upon receiving this information the client will provide this
>information to the user so that they may navigate the web portal
> 
> The client isn’t really going to provide the information to the user, is it?  
> It will provide the information to another application, or will use the 
> information to allow the user to navigate the portal.  Can you rephrase this 
> so it doesn’t sound as if the client will say, “Here’s the portal URI; go 
> wild.” ?

The sentence now reads: "Upon receiving this information the client will use 
this information direct the user to the the web portal (as specified by the 
user-portal-url value) to enable access to the external network."

> 
> — Section 8.1 —
> Please double-check the registration template for media types in RFC 6838 and 
> make sure this complies.

Updated for the missing "Fragment identifier considerations” field.
> 
> — Section 8.2 —
> 
>New assignments for Captive Portal API Keys Registry will be
>administered by IANA through Expert Review [RFC8126].  The Designated
>Expert is expected to validate the existence of documentation
>describing new keys in a permanent publicly available specification.
> 
> How, then, is this not Specification Required?

Good point =) Updated to Specification Required, as that is what the text 
explains.

Best,
Tommy
> 
> — 
> Barry
> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

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

[Tommy Pauly]

> On Mar 7, 2020, at 1:54 PM, ddol...@golden.net 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 

> 
> 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 


Thanks for the comments!
Tommy
> 
> I'm making editorial pull requests in github.
> 
> -Dave
> 
> On 2020-03-05 01:55, Martin Thomson wrote:
>> 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)
>> ___
>> Captive-portals mailing list
>> Captive-portals@ietf.org
>> https://www.ietf.org/mailman/listinfo/captive-portals
> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

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

[Tommy Pauly]

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  
> wrote:
> 
> 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?

Agreed, changed the wording as suggested.
> 
> 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?

Filed https://github.com/capport-wg/architecture/issues/50
> 
> 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.
> "

Added clarification as suggested.

> 
> 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)?

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

> 
> 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."

Fair clarification! Added as suggested.
> 
> 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?

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.

> 
> 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.

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.

> 
> 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.

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

> 
> Thanks,
> 

Re: [Captive-portals] IETF 107 Preliminary Agenda

[Tommy Pauly]

> On Feb 21, 2020, at 3:58 PM, Erik Kline  wrote:
> 
> Fellow capport-ians,
> 
> https://datatracker.ietf.org/meeting/107/agenda.html 
> 
> https://datatracker.ietf.org/meeting/107/agenda.txt 
> 
> 
> We are currently scheduled for a 1 hour session on Thursday at 17:40.
> 
> The agenda will mostly likely be similar to previous agendae 
> .
> 
> Would folks like to have some capport participation in the Hackathon again?

I won’t be there in person, but some of my other Apple compatriots should be 
able to bring along our implementation for interop!

Thanks,
Tommy
> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Remediation url for CAPPORT

[Tommy Pauly]

Lorenzo, my impression is that the User Portal URL (already distinct from the 
Venue URL) should cover that use case; or at least we should encourage it to be 
so. Once a user is logged in, the page generally won’t just show a new log in. 
If for some reason the renew page needs to be a different URL, it could simply 
redirect the user portal URL whenever the user is logged in.

If we have three URLs, then we’d have two URLs, the User Portal the new Extend 
URL, that would each only be useful at certain mutually exclusive times: one 
before log in and one while logged in. That seems like an easy opportunity to 
encourage portal designers to have a single page, so we don’t have a UI in 
android or iOS that ever presents a link that takes you to a useless “you’re 
logged in” page.

I’m all for having the venue URL be distinct, but let’s just use a Boolean to 
indicate if the user portal URL is a useful URL while logged in or not. 

Tommy

> On Jan 19, 2020, at 8:50 PM, Lorenzo Colitti  wrote:
> 
> I do think something is needed here because we don't want the device
> to put up a "you're running out of time, please click here to extend"
> prompt/notification, if tapping that prompt goes to a page that just
> says "you're logged in" without allowing the user to extend. If the
> network doesn't support extending sessions, then the device should not
> display the prompt. So we should give the network a way to express via
> the API whether it's possible to extend the user's time or not.
> 
> Once we do decide to have something like that in the API, ISTM that a
> separate URL is more useful than just a boolean. Whether the URL is
> present or not gives you the boolean; the content of the URL makes it
> easier for network operators because it means they can provide a
> specific "manage my connection" page that is different from the login
> page. The operator could of course decide what to display based on the
> login state of the user; this just makes it easier.
> 
> But as long as this is not the same as the venue URL, that works for
> me. We do want it to be separate, because we expect most operators
> will primarily want to surface the venue URL, and we don't want them
> to have to make a choice between surfacing the venue URL and making
> the session easy to extend.
> 
> Cheers,
> Lorenzo
> 
>> On Fri, Jan 17, 2020 at 4:25 PM Remi NGUYEN VAN
>>  wrote:
>> 
>> As far as the Android implementation is concerned, I think it would be nice 
>> to have capport API support in the next (android R) version; however due to 
>> deadlines, it's going to be harder for me to change the attributes read from 
>> the API very soon.
>> Following this discussion my current plan is to support an optional 
>> "remediation-supported" boolean, and only prompt users to extend their 
>> session shortly before it expires when it is set to true. Hopefully the 
>> boolean can be added to the current draft or in a future, separate draft 
>> considering that we seem to roughly agree on it, but if the group eventually 
>> realizes that it wants to go in another direction, we'll update behavior in 
>> subsequent releases.
>> 
>> Does that make sense ?
>> 
>> Cheers,
>> 
>> Remi
>> 
>>> On Wed, Jan 15, 2020 at 9:30 AM Erik Kline  wrote:
>>> 
>>> If there's working group consensus to add it to the current API draft then 
>>> definitely add it.  Otherwise, probably a separate document that would need 
>>> a call for wg adoption.
>>> 
>>> Separately, and hopefully without starting a massive bikeshed, is there a 
>>> more apt word than "remediation"?  I think this specific word carries the 
>>> connotation of "fixing an error" or "correcting damage" and it seems like 
>>> the use here would be broader.  But perhaps I'm completely mistaken.
>>> 
>>> On Tue, 14 Jan 2020 at 16:21, Heng Liu  wrote:
>>>> 
>>>> It seems most are comfortable with adding a remediation-capable boolean, 
>>>> which is simpler than another url while also making it explicit on whether 
>>>> remediation is provided or not, so UE could display different 
>>>> notifications.
>>>> 
>>>> Anyone have any objections on adding this boolean please?
>>>> 
>>>> If not, what's the next step on moving this forward please?
>>>> 
>>>> Thanks,
>>>> Heng
>>>> 
>>>> On Tue, Jan 14, 2020 at 12:38 PM Tommy Pauly  wrote:
>>>>> 
>>>>> Any captive portal that is newly adopting the CAPPORT API will hopefully 
>>&

Re: [Captive-portals] Remediation url for CAPPORT

[Tommy Pauly]

I have a similar initial reaction to Erik's. Adding another URL that 
effectively is just another user portal, but meant to be used at certain times, 
adds a lot of complexity. I'm certainly not ruling out adding such a key as 
need arises, but I'd hesitate to make it part of the initial set.

Particularly, if we start seeing the "venue URL" be the main landing page we 
redirect people to once they're logged it, it kind of makes sense to let the 
user portal be the status/remediation/payment page.

Tommy

> On Jan 13, 2020, at 4:06 PM, Erik Kline  wrote:
> 
> 
> 
> On Mon, 13 Jan 2020 at 15:26, Heng Liu  > wrote:
> On Sun, Jan 12, 2020 at 2:34 PM Erik Kline  > wrote:
> Why should this different from the user-portal-url?  It seems to me that 
> either the user-portal-url would remediation UI elements or it wouldn't.
> Some CP vendors want to specify a different URL specifically tailored for 
> remediation of a session. By providing a 3rd URL, we can accommodate this use 
> case.
> 
> If the remediation URL is available but the user (somehow) navigates to the 
> user-portal-url, what do they see?
> 
>  
> With this 3rd URL, if the bytes/time does expire should the OS try to launch 
> an interaction the remediation URL and then fallback to the user URL if it 
> failed to load?  In which case, why not just leave all interaction with the 
> user-portal-url?
> if a remediation URL is present, and if it fails to load for whatever reason, 
> no need to fallback to user portal URL: CP vendor should make sure the 
> remediation URL is working properly (this is similar to user-portal url 
> should work properly, if not, there is no other way for user to clear a CP)
> 
> I guess I'm just trying to be mindful of one person's flexibility is another 
> person's complexity.  I think this just doubles the number of URLs that the 
> CP vendor needs to make sure function correctly.
> 
> If the vendor doesn't implement a means to extend your session without 
> completely shutting everything down and forcing to the user to restart the 
> interaction flow anew, I could see that an OS would not want to bother the 
> user with an interaction where they couldn't actually do anything useful.  
> But that might suggest a boolean capability, rather than a new URL 
> (remediation-supported={true|false})?
> A boolean field could also be a positive signal to notify UE that remediation 
> is possible, but this would prevent CP vendors from using different URLs for 
> remediation.
> 
> (As mentioned in the initial thread, this URL approach is also taken by the 
> Passpoint release 2.0 spec to signal remediation process.)
> 
> regards,
> Heng
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org 
> https://www.ietf.org/mailman/listinfo/captive-portals 
> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org 
> https://www.ietf.org/mailman/listinfo/captive-portals 
> 
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] option 160 conflict

[Tommy Pauly]

One option we have is to use Code 114, which was reserved for use by Apple as a 
"URL" option. That particular codepoint wasn't ever used, so it should be open 
to be reclaimed as a CAPPORT API URL. Since this is in the range below 128, it 
should be safer to use.

Best,
Tommy

> On Dec 23, 2019, at 11:27 AM, Bernie Volz (volz)  wrote:
> 
> Hi:
>  
> OK, good to know. I had thought that there was support for using option 160 
> in implementations as RFC7710 was published in December 2015.
>  
> I guess Warren will need to update the bis document to request IANA to assign 
> a new DHCPv4 option (replacing 160) because of the potential conflict 
> regarding its use – likely it would be useful to give some short 
> justification for this (about the conflict). Likely the listing for option 
> 160 will need to be something like:
>  
> 160 DEPRECATED (see new-option-code) - DHCP Captive-Portal   
> N DHCP Captive-Portal   [RFC7710]
> 160 Polycom (vendor specific)
>  
> It may also be appropriate to request IANA assign 111 (if still available) as 
> it has no reported use and is in the original (<128) IANA assigned space (as 
> per RFC2132).
>  
> BTW: Code 115 (which was listed as used by failover in RFC3679) could also be 
> a good choice as I am pretty sure it this was ever used (and if it was, it 
> was for failover communication and not normal clients; and that use has long 
> been deprecated).
>  
> Bernie
>  
> From: tpa...@apple.com  
> Sent: Monday, December 23, 2019 12:58 PM
> To: Lorenzo Colitti 
> Cc: Bernie Volz (volz) ; Michael Richardson 
> ; captive-portals@ietf.org; Warren Kumari 
> 
> Subject: Re: [Captive-portals] option 160 conflict
>  
>  
> 
> 
> On Dec 21, 2019, at 7:48 PM, Lorenzo Colitti 
>  > wrote:
> 
> 
> On Sat, 21 Dec 2019, 07:53 Bernie Volz (volz),  > wrote:
> 1) It would not really remove the overlap for a long while (until all of the 
> clients that used the "old" 160 Capport option are upgraded). So, devices 
> will still need to deal with it for a long while.
>  
> Do any clients or networks actually implement 160 to mean capport? I know 
> that iOS and Android, which seem most interested in this option, do not yet.
>  
> I am not aware of anything using the option yet. iOS does not use it; we used 
> it for interop testing, but that is not in production code. 
> 
>  
> If they do not, the right thing to do would be to get a new option code, and 
> do so as soon as possible so the implementations that are being written this 
> year can immediately start using the new one.
>  
> I would also urge that if we want a new code, we allocate it soon so that the 
> implementations can quickly test it out and ship the right value. 
>  
> Tommy
> 
> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org 
> https://www.ietf.org/mailman/listinfo/captive-portals 
> 
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Discovering captive portal API URL via DNS?

[Tommy Pauly]

> On Sep 3, 2019, at 4:44 PM, Lorenzo Colitti 
>  wrote:
> 
> All,
> 
> During discussions with captive portal operators about implementing the 
> capport API, one of the stumbling blocks that keeps coming up is that the 
> captive portal operator does not always control the DHCP configuration and 
> thus cannot easily use RFC7710.

Thanks for bringing this up.

I wanted to clarify the issue a bit before diving into the mitigations. Do 
these captive portal operators have *no* relationship to the DHCP 
configuration? Presumably, the captive portal enforcement is done somewhere on 
path, in the router, or between the router and the Internet connection. And, if 
there is redirection of DNS going on, presumably, this is a DNS server that the 
captive portal (or the operator of the network) has some control over, and is 
provisioned via DHCP. For such portals, I would assume that it would be as easy 
to add a DHCP CAPPORT option as it would be to add the DNS server address of 
the captive portal's resolver (assuming the DHCP implementation supports the 
option).

Since the mitigation below is specific to modifying the DNS, I assume that we 
are talking about captive portal solutions that work, in part, by intercepting 
DNS.

Thanks,
Tommy
> 
> The WG has previously rejected the option of using a well-known DNS name to 
> discover the URL, because the API itself requires TLS, and without a hostname 
> it is not possible (or at least not easy) to validate the server. However, 
> what if the client did a CNAME query for capport.arpa (or equivalent other 
> local-only, non-DNSSEC-signed name), got back a CNAME for the real server, 
> and then assumed that the API server was https:///capport-api ?
> 
> Alternatively, Erik and Warren suggest RFC 7553. In this scheme the client 
> would do a URI lookup for "capport.arpa" or equivalent, and would take the 
> result of that URL as the API endpoint.
> 
> Thoughts?
> 
> Regards,
> Lorenzo
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Review of draft-ietf-capport-rfc7710bis

[Tommy Pauly]

To that end, any enforcement of other traffic (such as normal web page loading) 
will not be carrying any session identifier, so only signals that are already 
present in the packets, such as the IP address, are effectively useful here.

Thanks,
Tommy

> On Jul 25, 2019, at 2:43 PM, Lorenzo Colitti 
>  wrote:
> 
> Is there a problem with saying that the portal server should identify the 
> device by IP address?
> 
> On Mon, Jul 22, 2019 at 7:40 PM David Bird  > wrote:
> I think that assumption is problematic... the nature of captive portal means 
> the portal will be taking some action (e.g. releasing the UE from captivity) 
> specific to the UE/session, regardless of the content generated for the URL. 
> Captive portal networks work differently in uniquely identifying the 
> UE/session, but ultimately a "session-id" is typically carried in the 
> redirect URL on a per UE/session basis. If everyone gets the exact same URL, 
> this can only be done by IP address at the portal... Is that the design 
> networks are encouraged to take? 
> 
> On Mon, Jul 22, 2019 at 4:25 PM Lorenzo Colitti 
> mailto:40google@dmarc.ietf.org>> 
> wrote:
> No, I'm assuming that the URL in the RA is identical for all users and that 
> if any per-user behaviour is needed, then the content of that URL will be 
> dynamically generated.
> 
> On Mon, Jul 22, 2019, 18:12 David Bird  > wrote:
> Are we assuming that the URL contained in the DHCP/RA is the final "session 
> specific" URL for which the portal is able to uniquely identify the 
> UE/session ?
> 
> On Mon, Jul 22, 2019 at 2:43 PM Lorenzo Colitti 
> mailto:40google@dmarc.ietf.org>> 
> wrote:
> On Mon, Jul 22, 2019 at 4:49 PM Martin Thomson  > wrote:
> > 2. I'm surprised that the following text is present. It seems like we 
> > should disallow IP literals for compatibility with IPv6. But perhaps 
> > SHOULD is enough here.
> > 
> >  The URI SHOULD NOT contain an IP address literal. 
> 
> I tend to think that the core goal is that the URI contain a target identity 
> that can be authenticated when accessed over HTTPS.
> 
> That generally means that IP literals aren't a good idea, but I wouldn't make 
> this statement.  I would instead emphasize that this is an HTTPS URI.  Though 
> I would not go into great detail on what that means, I would refer to RFC 
> 7230.
> 
> It's possible to use HTTPS to IP literals. But IP literals are address-family 
> specific. That makes it impossible to support this option in a dual-stack 
> network because the two URLs will be different.
> 
> > 3. The section that documents the link relation type should mention 
> > what should happen if the portal is already open. Should the captive 
> > portal add this header to probe responses even if the portal is already 
> > open? if it does not, there is no way for a device to learn the API URL 
> > if it connects to a portal, logs in, disconnects, and then reconnects, 
> > because when it reconnects the portal will be open.
> 
> Good point.  I would be interested in hearing what the working group thinks 
> of this.
> 
> To my understanding, this is a problem that exists today.  So we may decide 
> not to worry about this particular problem, but just document it.  That would 
> make this path less good than other options (like DHCP/RA), but I don't want 
> to encourage networks to intercept EVERY request that passes.
> 
> Right, for networks without the capport API (i.e., all networks today) this 
> works. But for a network with the capport API, I think it's a problem if the 
> device cannot find the API URL just because the portal is open. The reason I 
> mention it is: this document says that the URL in the option is in fact the 
> API URL, and the link rel mechanism doesn't work well for the API URL.
> 
> One option would just be to drop this mechanism. If it is clear that the DHCP 
> / RA solutions are feasible in real networks, I don't see much of a need for 
> the link rel version at all.
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org 
> https://www.ietf.org/mailman/listinfo/captive-portals 
> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org 
> https://www.ietf.org/mailman/listinfo/captive-portals 
> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] quick poll: IETF 105 Montreal

[Tommy Pauly]

I’m in favor of having a meeting (and I’ll be in Montreal); I think at this 
point we should work to get the documents ready to go.

Our milestones for API, Architecture, and 7710bis are set to July 2019, so I’d 
encourage that we get those documents in shape to WGLC, and go through any 
issues that exist. For API, we have some changes in the GitHub version that 
haven’t been published yet. We should make sure to do that prior to the cutoff.

Thanks,
Tommy

> On Jun 10, 2019, at 9:38 PM, Erik Kline  
> wrote:
> 
> All,
> 
> Feel free to reply unicast to us (or otherwise) if you have plans to be in 
> Montreal and think we should have a meeting.
> 
> I know I have a few todos on the 7710bis document, but apart from that what 
> do folks think we should discuss?  Any demos to present?
> 
> If there isn't a formal meeting and it turns out there's interest "on the 
> ground", we could always do like we did in Bangkok and try to sort out an 
> unofficial meeting when we get there.  That obviously can have its own issues.
> 
> Thanks,
> -Erik
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Call for adoption draft-ekwk-capport-rfc7710bis

[Tommy Pauly]

Agreed, this document is definitely an improvement and core to moving ahead the 
other working group items. I also support adoption!

Best,
Tommy

> On Mar 28, 2019, at 7:00 PM, Kyle Larose  wrote:
> 
> We need to update the document to align with our proposed API, as well
> as to address a few shortcomings I believe we have discovered since it
> was first published.
> 
> I support adoption.
> 
>> On Wed, 27 Mar 2019 at 08:01, Martin Thomson  wrote:
>> 
>> Erik and Warren have helpfully provided this draft that updates RFC 7710.  
>> Today we discussed this and there seemed to be general agreement to adopt.
>> 
>> Please respond to this email before 2019-04-12 stating whether you think we 
>> should adopt or not.  If not, please share your reasons when you say this.
>> 
>> I'll be assessing consensus on this document, because my co-chair is an 
>> author.
>> 
>> ___
>> Captive-portals mailing list
>> Captive-portals@ietf.org
>> https://www.ietf.org/mailman/listinfo/captive-portals
> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] [Doh] Captive portals (was Re: suggested slides for IETF 104 on draft-reid-doh-operator)

[Tommy Pauly]

> On Mar 15, 2019, at 5:22 AM, Thomas Peterson  wrote:
> 
> (to those exclusively on the captive-portals list, this email follows on a 
> discussion around a presentation discussing implications of DNS over HTTP in 
> networks where captive portals are present)
> 
> On 15/03/2019 11:26, Martin Thomson wrote:
>> If the OS catches the captive portal, everything works nicely once the 
>> captive portal is dealt with.  If the captive portal manages to evade 
>> detection...
> 
> As there are numerous folk from browser and OS vendors within this mailing 
> list who implement capture portal detection, would there benefit in authoring 
> an informational document covering capture portal detection methods in the 
> absence of a network's DHCP service not implementing RFC 7710? Such a 
> document may help describe common methods to inform implementers and minimise 
> detection evading capture portals. It may be better placed in the capport WG 
> instead of doh.

Agreed that CAPPORT is a good place for this discussion.

As far as providing a document to describe OS-vendor-specific mitigations, I'm 
not sure if the benefit would be that large. It may be useful as an appendix in 
our Captive Portal Architecture document? The problem is that captive portals 
that want to whitelist OS probes for portals always can some way or another. 
Captive portals that do want to play nice don't whitelist these probes, and the 
detection generally works fine.

Thanks,
Tommy
 
> 
> Regards
> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] IETF 103 call for agenda items

[Tommy Pauly]

That sounds good to me. We haven't revved the API docs, etc, but using the time 
to just review next steps and get some more work done on 7710bis would be good.

Best,
Tommy

> On Oct 29, 2018, at 4:49 PM, Erik Kline  wrote:
> 
> I propose that this time we'll just meet informally.
> 
> There are some administrative things we might bring up, but otherwise
> leave it open for discussion.
> 
> -Erik
> On Mon, 22 Oct 2018 at 14:53, Erik Kline  wrote:
>> 
>> All,
>> 
>> We currently have a 1 hour slot scheduled on Thursday afternoon.  Does
>> anyone who'll be present have any proposed agenda items?
>> 
>> The list has been rather quiet of late.  I know I still need to
>> produce a more complete 7710bis, but that hardly warrants a full hour
>> of discussion.
>> 
>> If there isn't much to talk about this time, we can give everyone
>> their time back (and perhaps, for some folks, de-conflict this time
>> slot), and reconvene in Prague.
>> 
>> Thoughts?
>> -Erik
> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] I-D Action: draft-ietf-capport-api-00.txt

[Tommy Pauly]

> On Feb 5, 2018, at 4:54 PM, Martin Thomson  wrote:
> 
> On Tue, Feb 6, 2018 at 8:41 AM, David Bird  wrote:
>>> I have heard UE vendors express a strong desire to be able to know
>>> about status before they attempt to use the network.
>>> 
>> 
>> Hm, but (assuming you are using the provided network for DNS, CRL checks,
>> and the API itself), the UE is *already* using the network.
> 
> Not really.  The way I understand it, the UE alters routing tables so
> that only applications that explicitly opt in to using the interface
> to the network can do so.  That state exists until the network is
> given an "all clear”.
> 

That’s correct—the device chooses how to expose the available interfaces/PvDs 
to the applications. If we have a cellular connection, for example, we won’t 
let any application traffic use the Wi-Fi network until we’re sure that it’s 
not captive (as far as we can tell).

>> I believe this desire on the UE vendor part is a case of 'be careful what
>> you wish for' ... Having an API telling you it is "all clear" vs "do
>> internal (often sandboxed for various reasons browser) captive portal
>> dialog" amounts to making this a configuration of the network administrator
>> -- Remember the (current) arms race concerning captive  portal detection?
>> Well, the network operator wins with this API (!).
> 
> Remember we already concluded that if the network wants to lie about
> status, we aren't planning to stop them.  There are still some
> discussions to be had about providing incentives to be truthful, but
> it's possible that we could never really plumb the depths of that
> issue productively, so we've been deferring it.

Right, we can’t know for sure that the network isn’t lying. We have to trust 
that in the same way we trust the provisioning of DHCP, etc. We don’t need to 
make it such that no captive network can pretend to be non-captive, but we do 
need to allow some captive networks let the devices known that they are captive.

> 
>> Over the years on this list we have seen many use-cases come through, I
>> recall:
>> 
>> -  A school/library network that allows most of the Internet, but captures
>> and redirects for certain networks / sites
>> -  A network allows all sorts of protocols - IMAP, HTTPS, for example -
>> but not others - like HTTP, SMTP - and want to redirect / signal portal
>> -  A network that allows all Internet traffic, but just at a low QoS tier.
>> No "captive" portal, but a portal is  yet available for upgrading tier
>> -  Any network that allows a large walled garden, or even a *very large*
>> garden, but otherwise has a captive portal
>> -  A network that will 99.99% of the time allow all traffic, but will
>> (perhaps because of virus detection) interrupts sessions  into captive state
>> [technically, this is a "boolean" use-case, but one where polling would just
>> be huge noise]
> 
> I'd say that the amount of information provided here is rich enough
> that you want to talk to a human.  Very few networks permit sending of
> arbitrary packets to arbitrary hosts and the receipt of similar.  The
> point is to ensure that you are managing expectations.  If I
> understand the expression of requirements, the idea is that a UE can
> use the boolean signal, but this other stuff is better presented on
> the web page.  If the network starts off in a captive state, then that
> page will be seen (if there is a human), and maybe not used (if there
> isn't).
> 
>> Clients that go idle typically have their session terminated - so, yes, it
>> does save the user time (depending on "time" is billed - real time vs
>> metered, etc).
> 
> Right.  Though this is relatively rare in my experience.  In those
> cases, I think that the idea is that the client can check with the API
> before its time comes due and notice the resulting extension and so go
> back to sleep.

An idle device will still time out if nothing checks in, but for a device that 
is actively using the network and will be timeout at some specific threshold, 
it is useful to allow the user to re-up the connection.
> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] API access and .well-known

[Tommy Pauly]

Hi Evert,

I think that all three options that Martin provided implicitly support two 
different URLs ([API-URL] and [HTML-URL] for lack of a better term) that a 
client device could use. I agree that making things very explicit and clear is 
important.

>> a. use .well-known and just provide better justification for it

The reason I suggested a well-known URL was to ensure that we didn’t collide 
with some other URL (like the captive portal landing page) or some other JSON 
that’s not really doing this API. It would be easier to validate that the 
configuration did indeed intend to point to this JSON API. 

Note that in this setup, you would learn about the URL of the Captive Portal 
JSON API as the main entry point for the UE (the discovery coming from either 
7710 or PvD or the like). This is specifically the first URL, [API-URL]. The 
JSON content itself would contain [HTML-URL].

Instead of using a well-known URL here, we could imagine just enforcing that 
the discovered URL MUST be a JSON endpoint that serves up this API.

The benefit of this approach (get [API-URL] first, and follow it to [HTML-URL]) 
is that we pave the way towards more flexibility when we don’t necessarily need 
the [HTML-URL] to do traditional captive portals, but instead can do 
interaction models designed for watch-like devices, or multiple devices that 
don’t ever need a follow-on URL.

>> b. use content negotiation

In this approach, [API-URL] and [HTML-URL] are essentially the same, just with 
different content. I agree with the concern that this is ambiguous. It also has 
the potentially negative effect of tying together the JSON API and traditional 
HTML URL. Yes, you can do redirects, etc, to not be co-located, but this seems 
more prone to configuration error and complexity. 

>> c. find some way to get two URIs, like revising 7710 or finding an
>> alternative mechanism (such as the one in RFC 5986)

I think that this approach is effectively saying that [API-URL] and [HTML-URL] 
are both signaled explicitly in the discovery mechanism. While this avoids the 
problem of ambiguity, it bakes in the notion of a legacy captive portal URL, 
and takes up more space in the discovery mechanism.

I’d vote for some variation on (a), but we can just explain the meaning of the 
URL we discover more clearly, instead of using a well known URL.

Thanks,
Tommy

> On Jan 16, 2018, at 10:16 AM, Evert Pot  wrote:
> 
> On 1/14/18 9:39 PM, Martin Thomson wrote:
>> (see also https://github.com/capport-wg/api/issues/2)
>> 
>> Currently the API draft proposes use of .well-known for finding the
>> API.  Generally speaking, there's a trend toward avoiding use of
>> .well-known except when either:
>> 
>> * it is difficult to configure or provide a full URL, or
>> * the .well-known provides information about the origin as a whole.
>> 
>> In this case, the latter definitely doesn't apply, but I think we
>> should probably discuss the former a little.
>> 
>> The problem we have is that there are really two URLs we care about
>> and 7710 only provides one.  (PvD might provide two URLs, so we don't
>> need to worry about this problem for PvD.)
>> 
>> The old API draft used HTTP method to distinguish the two uses: GET
>> for HTML that you might show to a person; POST for an API.  But the
>> new, leaner API uses GET too, so that's not an option we can use.
>> 
>> HTTP content negotiation is another option here.  It's pretty
>> well-supported on the whole aside from a few wrinkles around caching.
>> I suspect we will find that caching will be infeasible for other
>> reasons (see the other issues on GitHub for a taste of that).  Content
>> negotiation works [1] by having the client send an Accept header field
>> with a new media type (straw man: application/capport+json) and the
>> server would detect this and send back an API response or redirect to
>> the API endpoint.  If this content-type wasn't present, it could send
>> back HTML (or a redirect to a server that does).
>> 
>> Here's the options I see:
>> 
>> a. use .well-known and just provide better justification for it
>> b. use content negotiation
>> c. find some way to get two URIs, like revising 7710 or finding an
>> alternative mechanism (such as the one in RFC 5986)
>> 
>> Tommy notes that this has a drawback in that it forces the web UI and
>> API to be co-located.  I don't think that is necessarily true if you
>> accept that HTTP-level redirects are possible.  Indeed, that is how
>> many enforcement points work today: they terminate a connection
>> locally but then redirect to more capable servers.  Also, using
>> .well-known doesn't really make the resources any less co-located
>> because the origin - and the server - are still the same.
>> 
>> What do folks prefer here?
>> 
>> [1] Content negotiation can use other properties of the request as
>> well, but Accept is common and pretty widely supported.
> We would definitely prefer to see 2 distinct urls here. It makes the least 

Re: [Captive-portals] UE Identification

[Tommy Pauly]

The WIP is up on GitHub here:

https://github.com/capport-wg/api <https://github.com/capport-wg/api>

Thanks,
Tommy

> On Jan 16, 2018, at 10:24 AM, David Bird <db...@google.com> wrote:
> 
> Do we have a preliminary draft of the API yet?
> 
> Requirements, purpose, whatnot...
> 
> On Mon, Dec 4, 2017 at 12:39 PM, David Bird <db...@google.com 
> <mailto:db...@google.com>> wrote:
> Looking forward to it!
> 
> 
> On Mon, Dec 4, 2017 at 12:35 PM, Tommy Pauly <tpa...@apple.com 
> <mailto:tpa...@apple.com>> wrote:
> Darshak Thakore and I are now the editors of the API document, and will be 
> posting a new version of the document hopefully soon that addresses the 
> discussions from the previous two IETF meetings. This definition will be a 
> lot simpler, and should make it clearer how to interact with the ICMP path. 
> 
> Thanks,
> Tommy
> 
> 
>> On Dec 4, 2017, at 9:11 AM, David Bird <db...@google.com 
>> <mailto:db...@google.com>> wrote:
>> 
>> I will also point out that the API is not only ill-defined, it doesn't have 
>> editors... right?
>> 
>> On Mon, Dec 4, 2017 at 9:08 AM, David Bird <db...@google.com 
>> <mailto:db...@google.com>> wrote:
>> These are good questions for the group to consider and provide feedback on...
>> 
>> While doing so, also consider the fact that the "The basic problem is that 
>> the enforcement point and API are two different entities." is a problem of 
>> our own creation in an effort to support an API that we haven't clearly 
>> defined.
>> 
>> I suggest rethinking the problem, let the extra ICMP semantics sink in, and 
>> consider the fact that we could achieve similar use-cases (if not identical, 
>> even more use-cases) without the above "basic problem" ... 
>> 
>> The use-cases I speak of specially are:
>> 
>> - A way to better identify captivity in the network and feedback (on a need 
>> to know basis) of what resources are allowed in the walled garden.
>> - A non-redirect (non-flow terminating) way of notifying of pending session 
>> interruptions or otherwise suggesting a portal visit.
>> - A deployment model that doesn't put huge requirements on systems 
>> integrations and installers.
>> 
>> 
>> On Sun, Dec 3, 2017 at 11:53 PM, Martin Thomson <martin.thom...@gmail.com 
>> <mailto:martin.thom...@gmail.com>> wrote:
>> Thanks Kyle for the summary of the discussion.
>> 
>> The chairs would like to focus your attention on the issue of User
>> Equipment identification.  The basic problem is that the enforcement
>> point and API are two different entities.  They might also need to
>> talk about the UE with other entities (RADIUS servers, logging
>> systems, payment systems, and all sorts of backend systems).
>> 
>> How should the UE be identified?
>> 
>> We had a great discussion about this in Singapore and it's the view of
>> the chairs that there was no consensus for defining a set of UE
>> identifiers for explicit use in the protocols.  There were a few
>> reasons for this. One was that it would be difficult to find a set of
>> identifiers that would work for all deployments.  Also, allowing the
>> UE to include identifiers would increase the risk that the UE spoofs
>> those identifiers.
>> 
>> The two options that were discussed at length both involved having the
>> UE identified implicitly.  That is, some property of the packets that
>> arrive at the enforcement point would be used to identify the UE.  The
>> concern being that the identifier(s) were not subject to spoofing.
>> MAC, IP, or the circuit on which the packets arrive might all be
>> acceptable.
>> 
>> There was some discussion about how to manage consistent
>> identification between API and enforcement.  From the discussion, we
>> appear to have two options:
>> 
>> 1. Identify the UE at the API the same way that it is identified at
>> enforcement.  API and enforcement would have to agree on the
>> identifier they use.  This would also constrain deployments so that
>> the API has to be located on the network in a position where
>> spoofing identifiers isn't possible.
>> 
>> 2. Have the enforcement device pass an identifier (a "session ID") to
>> the UE for use with the API.  The enforcement would probably use an
>> ICMP extension to pass this information back.  This would need to be
>> authenticated, so that the UE couldn't generate a valid identifier.
>> There was plenty of discussion about that, but the short summary is
>

Re: [Captive-portals] UE Identification

[Tommy Pauly]

Darshak Thakore and I are now the editors of the API document, and will be 
posting a new version of the document hopefully soon that addresses the 
discussions from the previous two IETF meetings. This definition will be a lot 
simpler, and should make it clearer how to interact with the ICMP path. 

Thanks,
Tommy

> On Dec 4, 2017, at 9:11 AM, David Bird  wrote:
> 
> I will also point out that the API is not only ill-defined, it doesn't have 
> editors... right?
> 
> On Mon, Dec 4, 2017 at 9:08 AM, David Bird  > wrote:
> These are good questions for the group to consider and provide feedback on...
> 
> While doing so, also consider the fact that the "The basic problem is that 
> the enforcement point and API are two different entities." is a problem of 
> our own creation in an effort to support an API that we haven't clearly 
> defined.
> 
> I suggest rethinking the problem, let the extra ICMP semantics sink in, and 
> consider the fact that we could achieve similar use-cases (if not identical, 
> even more use-cases) without the above "basic problem" ... 
> 
> The use-cases I speak of specially are:
> 
> - A way to better identify captivity in the network and feedback (on a need 
> to know basis) of what resources are allowed in the walled garden.
> - A non-redirect (non-flow terminating) way of notifying of pending session 
> interruptions or otherwise suggesting a portal visit.
> - A deployment model that doesn't put huge requirements on systems 
> integrations and installers.
> 
> 
> On Sun, Dec 3, 2017 at 11:53 PM, Martin Thomson  > wrote:
> Thanks Kyle for the summary of the discussion.
> 
> The chairs would like to focus your attention on the issue of User
> Equipment identification.  The basic problem is that the enforcement
> point and API are two different entities.  They might also need to
> talk about the UE with other entities (RADIUS servers, logging
> systems, payment systems, and all sorts of backend systems).
> 
> How should the UE be identified?
> 
> We had a great discussion about this in Singapore and it's the view of
> the chairs that there was no consensus for defining a set of UE
> identifiers for explicit use in the protocols.  There were a few
> reasons for this. One was that it would be difficult to find a set of
> identifiers that would work for all deployments.  Also, allowing the
> UE to include identifiers would increase the risk that the UE spoofs
> those identifiers.
> 
> The two options that were discussed at length both involved having the
> UE identified implicitly.  That is, some property of the packets that
> arrive at the enforcement point would be used to identify the UE.  The
> concern being that the identifier(s) were not subject to spoofing.
> MAC, IP, or the circuit on which the packets arrive might all be
> acceptable.
> 
> There was some discussion about how to manage consistent
> identification between API and enforcement.  From the discussion, we
> appear to have two options:
> 
> 1. Identify the UE at the API the same way that it is identified at
> enforcement.  API and enforcement would have to agree on the
> identifier they use.  This would also constrain deployments so that
> the API has to be located on the network in a position where
> spoofing identifiers isn't possible.
> 
> 2. Have the enforcement device pass an identifier (a "session ID") to
> the UE for use with the API.  The enforcement would probably use an
> ICMP extension to pass this information back.  This would need to be
> authenticated, so that the UE couldn't generate a valid identifier.
> There was plenty of discussion about that, but the short summary is
> that this is possible if we want to have it happen.
> 
> It seems like there is some sense that the first option was preferred.
> We'd like to get a sense of the list here.  Which of these options is
> preferable, and why?
> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org 
> https://www.ietf.org/mailman/listinfo/captive-portals 
> 
> 
> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] I-D Action: draft-ietf-capport-architecture-00.txt

[Tommy Pauly]

Hi Kyle, Dave,

Thanks for updating the architecture document! It's nicely written, and serves 
as a very good summary of the state of our collective thoughts in the WG.

I've just done a pass of a review of the document, and wanted to share my 
notes/thoughts with you and the rest of the group for discussion. Details below!

Best,
Tommy


Section 1:

The principles in general are great!

I’m not sure about this one:

“Solutions SHOULD allow a device to be alerted that it is in a
  captive network when attempting to use any application on the
  network.  (Versus requiring a user to visit a clear-text HTTP site
  in order to receive a notification.)”

I would possible modify the requirement to be:

“Solutions SHOULD allow a device to be alerted that it is in a
captive network before and in response to any attempt by 
an application to use the network.”

It’s very similar, but we’re likely fine if we know before the attempt (as part 
of attachment) or as a notification in response to a failed connection.

Section 1: I would remove the parentheses around the statement “(However, this 
document does not yet…”

Section 1: I don’t see a large different between the mechanism “End-user 
devices are notified of captivity with ICMP/ICMP6” and “Receipt of the 
ICMP/ICMP6 messages informs an end-user device”. Is this just trying to split 
the network behavior from the device behavior?

Section 2.1: I would upgrade distinguishing Captive Portal API per-interface to 
a SHOULD from a MAY. While mPvD is a way to view it, any UE that has multiple 
interfaces (PvDs) really should not be treating all as captive, if only one is 
captive. Captive servers are prime examples of resources that are likely local 
to your attachment.

Section 2.2.2: The summary of the PvD approach is good. We should update the 
references to [draft-ietf-intarea-provisioning-domains].

Later on, in Section 6, you mention how PvDs are trying to tie the authenticity 
of the JSON API server to the RA/DHCP provisioning; that may be a useful point 
to bring up to the initial discussion in 2.2.2.

Areas I’d like to discuss with the group around PvDs, or the currently 
specified DHCP option:
• Clearly, the DHCP option needs more specification to point to an API 
(protocol, etc) beyond the current RFC, as discussed in 2.2.1. I’d love to see 
this update as opportunity for 2.2.1 and 2.2.2 to converge, however that makes 
most sense.
• A difference of the PvD option is that it allows for finer 
granularity, i.e. that you can have multiple PvDs/access routes on a single 
layer 2 interface (two uplinks on one Wi-Fi). One may be captive, the other 
not. Of course, we can specify that the DHCP/RA option for CAPPORT API URL will 
be associated with the PvD that shares the RA packet, so that’s solvable.
• We need to have a story around authentication that the CAPPORT API is 
actually provisioned by the same entity that provides the DHCP/RA. That can 
either be an auth option separately, or by using authentication of the PvD if 
we tie the captive option to a PvD.
• One discussion that’s come up is that a PvD API set of options will 
likely be longer-lived and less user-specific than the results in a CAPPORT 
API. The solution currently outlined here says that the device would first 
fetch the PvD API blob, which would point to the CAPPORT API. That works, and 
we may not care, but I don’t love the indirection here. Of course, the two 
*could* be co-located, even if one points to the other. My other thought (which 
may be harebrained) is that the option we get in RA/DHCP could essentially be 
able to point you to two different kinds of URLs: one for long-lived 
network-wide state, and one for more dynamic per-device state. These would have 
different fetching schemes, and the option would communicate the presence or 
non-presence of each.
• The current DHCP option doesn’t have a way to say “there’s no captive 
portal to talk to”, so whenever we don’t see it, we’ll need to send a probe. So 
every network would either be one with a probe (thus delaying our full 
attachment), or one that is explicitly captive. Whatever we end up with, I’d 
like to see that be able to be avoided. Making the option a bit more generic 
(like PvD) would allow having defined semantics around the option saying “I’m a 
network that knows what I’m doing, and I don’t have a captive portal for you to 
interact with”.

Section 2.3: Any thoughts on upgrading the TLS (or some other authenticated 
channel) support for the CAPPORT API to a MUST? Section 6.2 assumes this.

Section 3.2: Could there be a sub-workflow for the case in which the UE 
predicted an expiry based on the CAPPORT API, and re-checks in before user has 
to have anything blocked, get ICMP, etc?

> On Sep 29, 2017, at 6:33 AM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a 

Re: [Captive-portals] Capport at the hackathon

[Tommy Pauly]

+1

I'll be there, and would love to work on CAPPORT stuff!

Tommy

> On Nov 2, 2017, at 7:29 AM, Kyle Larose  wrote:
> 
> I'll be participating. Hoping to see a bunch of people there. :)
> 
> -Original Message-
> From: Captive-portals [mailto:captive-portals-boun...@ietf.org] On Behalf Of 
> Martin Thomson
> Sent: Wednesday, November 01, 2017 8:04 PM
> To: captive-portals@ietf.org
> Subject: [Captive-portals] Capport at the hackathon
> 
> FYI,
> 
> I've tentatively registered interest in capport work at the hackathon.
> For those interested in participating, I hope that you can join us.
> 
> See 
> https://www.ietf.org/registration/MeetingWiki/wiki/doku.php?id=100hackathon
> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals
> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] [adoption call] draft-larose-capport-architecture

[Tommy Pauly]

I support adoption as well!

Thanks,
Tommy

> On Aug 30, 2017, at 7:20 PM, Dave Dolson  wrote:
> 
> As one of the authors, I support adoption.
> 
> David Dolson
> Sandvine
>  Original Message
> From: Erik Kline
> Sent: Wednesday, August 30, 2017 7:04 AM
> To: captive-portals@ietf.org
> Cc: martin.thom...@gmail.com
> Subject: [Captive-portals] [adoption call] draft-larose-capport-architecture
> 
> 
> All,
> 
> As indicated in the minutes from Prague
> [https://datatracker.ietf.org/doc/minutes-99-capport/], there was a
> general hum in favor of the architecture document:
> 
>"""
>1. for arch doc, do we want a milestone for architecture. Humming: in 
> favor.
>2. is the document a good basis for the milestone? Humming: in favor.
>"""
> 
> This email is to initiate a two week adoption call for:
> 
>https://datatracker.ietf.org/doc/draft-larose-capport-architecture/
> 
> Feedback requested, even if only to restate an opinion expressed in Prague.
> 
> Thanks,
> -Erik
> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] [adoption call] draft-donnelly-capport-detection

[Tommy Pauly]

+1 to adopting this document as the basis for the captive API.

Thanks,
Tommy

> On Aug 30, 2017, at 7:23 PM, Dave Dolson  wrote:
> 
> I support adopting the API document, expecting some changes to the details of 
> the API itself, which I believe the authors also said they expected.
> 
> David Dolson
> Sandvine
>  Original Message
> From: Erik Kline
> Sent: Wednesday, August 30, 2017 7:04 AM
> To: captive-portals@ietf.org
> Cc: martin.thom...@gmail.com
> Subject: [Captive-portals] [adoption call] draft-donnelly-capport-detection
> 
> 
> All,
> 
> As indicated in the minutes from Prague
> [https://datatracker.ietf.org/doc/minutes-99-capport/], there was a
> general hum in favor of the API document:
> 
>"""
>4. API document: do we need a milestone? Humming: in favor.
>5. Is this document a good basis. Humming in favor.
>
> 
> This email is to initiate a two week call for adoption for:
> 
>https://datatracker.ietf.org/doc/draft-donnelly-capport-detection/
> 
> Feedback requested, even if only to restate an opinion expressed in Prague.
> 
> Thanks,
> -Erik
> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Questions about PvD/API

[Tommy Pauly]

Right, I think the difference between an unreachable destination, and a captive 
portal or walled garden, is that we expect the captive portal style interaction 
to be an Operating System-level action, and one that will have consequences on 
everything the device does while associated to a given network. You can certain 
use spoofed ICMP to disrupt connections, but (a) the user would notice and (b) 
you're not causing the Operating System to change behavior. When the OS thinks 
it is on a captive network or not, it will change what network it considers 
primary/usable, which may potentially be invisible to the user other than an 
icon change. I would be able to go onto a captive network, start sending out 
ICMP messages, and potentially bump other people's connection off the network. 

Having the UE fetch some resource in order to determine captive state, 
especially if that resource can be somehow signed, makes it much harder for an 
attacker to cause the OS to take silent behavior.

Tommy

> On Aug 24, 2017, at 7:40 AM, Lorenzo Colitti  wrote:
> 
> A forged destination unreachable can't cause someone else's device to think 
> that wifi is a portal and switch to possibly expensive cellular data.
> 
> On Thu, Aug 24, 2017 at 11:29 PM, David Bird  > wrote:
> Just like the rampant problem we see in ICMP Dest-Unreachable forgery 
> attacks? 
> 
> On Thu, Aug 24, 2017 at 7:01 AM, Lorenzo Colitti  > wrote:
> On Thu, Aug 24, 2017 at 10:40 PM, David Bird  > wrote:
> Can you give an example of how ICMP could be misconfigured? 
> 
> It doesn't matter how hard it is to misconfigure, because it is trivial to 
> forge.
> 
> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Questions about PvD/API

[Tommy Pauly]

 new PvD device is 
> seeing a captive portal, while all their other devices do not. Staff at the 
> coffee shop don't believe me; all their devices work too.
> 
> I think there are fundamental issues in splitting what should be 'network 
> notification' into web APIs
> 
> 1. Tomorrow, we join a network, always do a probe, which redirects to captive 
> portal
> 
> It wasn't clear in your e-mail if RFC7710 can be used *without* providing a 
> URL, or is there a PvD specific DHCP option?
> 
> Thanks,
> David
> 
> 
> On Wed, Aug 16, 2017 at 9:20 AM, Tommy Pauly <tpa...@apple.com 
> <mailto:tpa...@apple.com>> wrote:
> Hi David,
> 
> You mention in one of your emails that you'd expect there to be many "broken 
> PvD" deployments, which would either necessitate ignoring PvD and using 
> legacy mechanisms, or else having the user face a broken portal. My 
> impression is that if client-side deployments fail closed—that is, if there 
> is a PvD advertised, but it does not work well, then we treat the network as 
> broken. If this client behavior is consistent from the start of deployment, 
> then I would think that deployments would notice very quickly if they are 
> broken. The fundamental part of the PvD being advertised is in the RAs—if our 
> DHCP or RAs are broken on a network, we generally are going to be broken 
> anyhow.
> 
> As far as where the API resides, I appreciate your explanation of the various 
> complexities. My initial take is this:
> 
> - Where a PvD is being served is up to the deployment, and determined by the 
> entity that is providing the RAs. To that end, the server that hosts the API 
> for extended PvD information may be very different for enterprise/carrier 
> scenarios than in captive portals for coffee shops.
> - For the initial take for Captive Portals, I would co-locate the "PvD API" 
> server with the "Captive API" and "Captive Web Server". Presumably, the 
> device that was previously doing the HTTP redirects would be able to do the 
> similar coordination of making sure the PvD ID that is given out to clients 
> matches the PvD API server (which is the same as the "Captive Web Server").
> 
> For the captive use-case, I see the integration of PvDs as an incremental 
> step:
> 
> 1. Today, we join a network, always do a probe, which may get redirected to a 
> captive web server
> 2. With RFC 7710, we would join a network and do the same as (1), unless the 
> captive URL is given in the DHCP/RA and we just make a connection directly.
> 3. With the Captive API draft, we can interact with the portal other than 
> just showing a webpage; but this may still be bootstrapped by 7710 if not 
> using another mechanism
> 4. With PvDs, the mechanism in 7710 is generalized to support APIs other than 
> just captive, and can indicate that no captive portal or other extended info 
> is present; and the PvD API in this form is just a more generic version of 
> the captive API that allows us to use the same mechanism for other network 
> properties that aren't specifically captive (like enterprise network extended 
> info, or walled gardens)
> 
> Getting into the arms race of people avoiding the captive probes: if someone 
> doesn't want to interact with the client OS's captive portal system, they can 
> and likely will not change anything and just keep redirecting pages. 
> Hopefully if a better solution becomes prevalent enough in the future, client 
> OS's will be able to just ignore and reject any network that redirects 
> traffic, and the only supported captive portals would be ones that interact 
> in specified ways and advertise themselves as captive networks. In order to 
> get to this point, there certainly needs to be a carrot to incentivize 
> adoption. My goal with the more flexible interaction supported by PvD is that 
> we will allow the networks to provide a better user experience to people 
> joining their networks, and integrate with client OS's to streamline the 
> joining process (notification of the network being available, who owns it, 
> how to accept and how to pay), the maintenance process (being able to 
> integrate time left or bytes left on the network into the system UI), and 
> what is allowed or not on the network.
> 
> Thanks,
> Tommy
> 
> 
>> On Aug 16, 2017, at 6:51 AM, David Bird <db...@google.com 
>> <mailto:db...@google.com>> wrote:
>> 
>> My question about where the PvD API resides was somewhat rhetorical. In 
>> reality, I'm sure you will find all of the above - In the NAS (e.g. Cisco), 
>> at the hotspot services provider, and something hosted next to the venues 
>> website. It depends mostly on how t

Re: [Captive-portals] Questions about PvD/API

[Tommy Pauly]

Hi David,

You mention in one of your emails that you'd expect there to be many "broken 
PvD" deployments, which would either necessitate ignoring PvD and using legacy 
mechanisms, or else having the user face a broken portal. My impression is that 
if client-side deployments fail closed—that is, if there is a PvD advertised, 
but it does not work well, then we treat the network as broken. If this client 
behavior is consistent from the start of deployment, then I would think that 
deployments would notice very quickly if they are broken. The fundamental part 
of the PvD being advertised is in the RAs—if our DHCP or RAs are broken on a 
network, we generally are going to be broken anyhow.

As far as where the API resides, I appreciate your explanation of the various 
complexities. My initial take is this:

- Where a PvD is being served is up to the deployment, and determined by the 
entity that is providing the RAs. To that end, the server that hosts the API 
for extended PvD information may be very different for enterprise/carrier 
scenarios than in captive portals for coffee shops.
- For the initial take for Captive Portals, I would co-locate the "PvD API" 
server with the "Captive API" and "Captive Web Server". Presumably, the device 
that was previously doing the HTTP redirects would be able to do the similar 
coordination of making sure the PvD ID that is given out to clients matches the 
PvD API server (which is the same as the "Captive Web Server").

For the captive use-case, I see the integration of PvDs as an incremental step:

1. Today, we join a network, always do a probe, which may get redirected to a 
captive web server
2. With RFC 7710, we would join a network and do the same as (1), unless the 
captive URL is given in the DHCP/RA and we just make a connection directly.
3. With the Captive API draft, we can interact with the portal other than just 
showing a webpage; but this may still be bootstrapped by 7710 if not using 
another mechanism
4. With PvDs, the mechanism in 7710 is generalized to support APIs other than 
just captive, and can indicate that no captive portal or other extended info is 
present; and the PvD API in this form is just a more generic version of the 
captive API that allows us to use the same mechanism for other network 
properties that aren't specifically captive (like enterprise network extended 
info, or walled gardens)

Getting into the arms race of people avoiding the captive probes: if someone 
doesn't want to interact with the client OS's captive portal system, they can 
and likely will not change anything and just keep redirecting pages. Hopefully 
if a better solution becomes prevalent enough in the future, client OS's will 
be able to just ignore and reject any network that redirects traffic, and the 
only supported captive portals would be ones that interact in specified ways 
and advertise themselves as captive networks. In order to get to this point, 
there certainly needs to be a carrot to incentivize adoption. My goal with the 
more flexible interaction supported by PvD is that we will allow the networks 
to provide a better user experience to people joining their networks, and 
integrate with client OS's to streamline the joining process (notification of 
the network being available, who owns it, how to accept and how to pay), the 
maintenance process (being able to integrate time left or bytes left on the 
network into the system UI), and what is allowed or not on the network.

Thanks,
Tommy

> On Aug 16, 2017, at 6:51 AM, David Bird  wrote:
> 
> My question about where the PvD API resides was somewhat rhetorical. In 
> reality, I'm sure you will find all of the above - In the NAS (e.g. Cisco), 
> at the hotspot services provider, and something hosted next to the venues 
> website. It depends mostly on how this URL is configured, and by whom. (One 
> could imagine people doing all sorts of things). 
> 
> My question more specifically for the authors is, how would Cisco implement 
> PvD for Guest/Public access and would it actively stop avoiding Apple captive 
> portal detection? Or, would turning on PvD just make that 'feature' easier to 
> implement?
> 
> On Tue, Aug 15, 2017 at 5:19 PM, Erik Kline  > wrote:
> Randomly selecting Tommy and Eric so this bubbles up in their inbox.
> 
> On 2 August 2017 at 10:36, David Bird  > wrote:
> > Could an author of PvD help me understand the following questions for each
> > of the diagrams below I found on the Internet -- which represent some
> > typical hotspot configurations out there...
> >
> > - Where would the API reside?
> >
> > - Who 'owns' the API?
> >
> > - How does the API keep in-sync with the NAS? Who's responsible for that
> > (possibly multi-vendor, multi-AAA) integration?
> >
> > 1) Typical Hotspot service company outsourcing:
> > 

Re: [Captive-portals] IETF 99 minutes

[Tommy Pauly]

> On Aug 2, 2017, at 6:20 AM, Gunther Nitzsche <gnitzs...@netcologne.de> wrote:
> 
> Hi
> 
> and thanks for the meeting minutes.
> 
> I have two (no..three :) small comments on that:
> There is an uncontradicted comment saying:
> 
> 
> David Dolson: need to
> notify non-http-80
> Tommy Pauly: expect to interact with web pages
> Martin:
> considers status code 511 to be dead until new information.
> 
> 
> I am wondering why the complete discussion in the last weeks
> regarding  511 - status on this mailing list seems to be completely
> ignored? At least for me it is still the preferred way to go as I mentioned
> earlier here.
> 
> And:
> 
> Martin:  Some
> feedback I got was (a) there are far too many bits & messages (maybe dest
> unreach is enough), you allow provider to provide discriminatory services.
> David
> B: That's what walled garden does. We shouldn't go there.
> 
> 
> ..and I thought, we had the consensus that walled garden
> is a perfect topic for this ml?
> 
> Further down:
> 
> Tommy: today, we wait for capport
> probe to complete until allowing network access.
> 
> 
> That is not what we do. Download of antivirus -patterns or
> self- reenabling after abuse block is a valid reason to
> reach parts of the network even when the customer is blocked.

Hi Gunther,

I was referring to what the behavior on Apple operating systems is. When a 
Wi-Fi network is joined, the captive portal probe is a generally a precondition 
for allowing the Wi-Fi network to be marked as the default route for the 
system. While traffic may still be allowed over that network when scoped, 
general networking traffic is not allowed until the probe completes.

Thanks,
Tommy
> 
> 
> Thanks
> 
> Gunther
> 
> On 31.07.2017 03:00, Erik Kline wrote:
>> FYI: I have uploaded the meeting minutes as captured in Etherpad.
>> Many thanks to David Dolson (and any others) for taking notes.
>> 
>> You can find the minutes on the wg meetings page:
>> 
>>https://datatracker.ietf.org/group/capport/meetings/
>>https://datatracker.ietf.org/meeting/99/minutes/capport
>> 
>> and in the wg-materials repo on github:
>> 
>>https://github.com/capport-wg/wg-materials
>> 
>> I have not edited this initial upload of the minutes in any way.
>> 
>> Please review if/when you get a chance; we can post 
>> corrections/clarifications.
>> 
> 
> 
> 
> NetCologne Systemadministration
> -- 
> NetCologne Gesellschaft für Telekommunikation mbH
> Am Coloneum 9 ; 50829 Köln
> Geschäftsführer:   
>  Timo von Lepel,
>  Mario Wilhelm  
> Vorsitzender des Aufsichtsrates:
>  Dr. Andreas Cerbe
>  HRB 25580, AG Köln
> 
> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org <mailto:Captive-portals@ietf.org>
> https://www.ietf.org/mailman/listinfo/captive-portals 
> <https://www.ietf.org/mailman/listinfo/captive-portals>
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"

[Tommy Pauly]

To chime in on the problem of misconfigured networks, I can picture three 
variations of issues:

1. If the PvD captivity information is unavailable due to misconfiguration, I 
would argue that an implementation MUST fall back to any legacy mechanisms like 
today’s HTTP probes. This means that on misconfigured networks that advertised 
a PvD server, we would have a delay after failing to fetch the information.
2. If the PvD information is wrong and lies saying that there is no captivity, 
when in fact there is, that could be detected by clients by the redirects that 
happen with future connections. This is essentially the situation we’re in 
today in which a captive network whitelists hosts such as captive.apple.com 
<http://captive.apple.com/>, and the user is forced to manually browse to a 
site and get redirected. This case is unfortunate, and exists today (and likely 
with any solution).
3. If the PvD information is wrong and lies that that there is captivity when 
there isn’t any, I would assume that the portal site would fail to connect or 
load, and would be ignored or dismissed by the system. The system could also 
run explicit probes in this case.

Between all three of these, there shouldn’t be any fundamental reason a device 
that is PvD-aware would fail to join a network that a legacy device was able to 
join. These cases may still involve probing, or waiting for connections to 
fail, but if we can hope that misconfiguration is not the norm (which must 
always be our hope), then we’re still benefiting most cases.

As for cases in which you join a network and then captivity starts partway 
through after expiration, I think the PvD solution is very elegant: we would 
still do explicit PvD discovery, and be altered that there is an expiration 
time on the access from the moment the network is joined.

Also, the configuration that’s accessed for the PvD captivity doesn’t need to 
be public—the information can be specific to a local network, and only needs to 
tell as much information as the network is willing to share for the device’s 
benefit.

Thanks,
Tommy

> On Jul 10, 2017, at 8:54 AM, Dave Dolson <ddol...@sandvine.com> wrote:
> 
> David,
> Is it fair to say your concerns are mainly about misconfigured networks?
> And this is the reason that devices will always be incented to probe 
> regardless of any method of provisioning?
>  
> -Dave
>  
>  
> From: David Bird [mailto:db...@google.com <mailto:db...@google.com>] 
> Sent: Monday, July 10, 2017 9:39 AM
> To: Tommy Pauly
> Cc: Dave Dolson; Eric Vyncke (evyncke); captive-portals@ietf.org 
> <mailto:captive-portals@ietf.org>
> Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"
>  
> On Sat, Jul 8, 2017 at 6:14 PM, Tommy Pauly <tpa...@apple.com 
> <mailto:tpa...@apple.com>> wrote:
> [snip] 
> The idea with explicit PvD discovery is that it would, as a step, replace a 
> separate captive portal detection strategy.
>  
> My overall concern with discovery mechanisms that are specific to only 
> captive portals is that this is an extra step that is performed potentially 
> on every network association, that may have limited extensibility for 
> non-captive use cases. Since the explicit PvD design promises a way to 
> discover many properties beyond captivity, and is bootstrapped very early on 
> in the network association, it should hopefully allow clients to avoid the 
> extra probe.
> 
> 
>  
> I have concerns with the PvD approach, as described.
>  
> If a network was misconfigured to advertise a PvD that does have a (Internet 
> based) HTTPS server with a JSON file on it describing a captive portal 
> network, then devices utilizing the PvD information will *never* get on this 
> network while devices not using the PvD information do. That could be very 
> confusing to users and network administrators alike. 
>  
> If you have seen walled garden configurations for large networks, you will 
> notice a lot about the network operator's marketing partners. Indeed, many 
> walled gardens are much larger than the network really wants... sometimes 
> they just need to make things work in the garden. My point here is that 
> operators may not *want* to list out their walled garden configuration on a 
> public JSON file...
>  
> At the end of the day, I'd argue that the client *will always probe* -- 
> wether it means to or not... A networking using PvD could just advertise all 
> networks routes are available so that the device connects only to get caught 
> up in a captive portal redirect anyway... back to step 1 and captive portal 
> detection..
>  
> I'm also unclear how PvD would deal with scenarios where you might start out 
> with internet connectivity (e.g. "MAC Authentication") then to have a captive 
>

Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"

[Tommy Pauly]

Hi Dave,

> On Jul 10, 2017, at 8:54 AM, Dave Dolson  wrote:
> 
> At the last meeting, I think we heard, “PvDs can help solve this problem.”
> (This seems to me to be true.)
> Are the PvD authors backing away from this assertion?

No, we’re definitely still saying that PvDs can help solve the Captive Portal 
problem. The details of the JSON aren’t in latest revision of the main PvD 
document just to focus the scope of the draft, but the idea would be that the 
PvD provisioning information would be how you bootstrap captive portal 
discovery.

>  
> I think there are two aspects:
> 1.   The PvD data structures on the end-user device, which track 
> captivity state per PvD. (RFC 7556 discusses connectivity tests per PvD.)
> 2.   Whether the PvD protocol explicitly conveys the captive-portal 
> concept.
>  
> If I understand correctly, (1) could be achieved even if capport information 
> is conveyed in DHCP or RAs (vs. in the PvD protocol).
> However, that points to yet another API to query.

You’re correct. A client device can keep track of PvD information and already 
should associate captivity when discovered with the implicit PvD. Part (2) is 
saying that if we are doing external PvD discovery anyway, it should include 
captivity information. This is how we avoid the extra API to call.
>  
> I think that draft-bruneau-intarea-provisioning-domains has addressed a 
> problem more generic than the CAPPORT API problem.
> And therefore I’m feeling it is still worth pursuing.

Right, the draft is more generic than the captive portal right now. I could 
imagine that we make sure that the CAPPORT solution references and works well 
with PvDs.

Thanks,
Tommy
>  
>  
> I think Tommy makes a great point that there is value in explicitly 
> indicating, “this is not a captive portal”. This ought to speed up network 
> association.
>  
>  
> -Dave
>  
>  
>  
> From: tpa...@apple.com  [mailto:tpa...@apple.com 
> ] 
> Sent: Saturday, July 8, 2017 9:15 PM
> To: Dave Dolson
> Cc: Eric Vyncke (evyncke); captive-portals@ietf.org 
> ; David Bird
> Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"
>  
>  
> 
> 
> On Jun 27, 2017, at 12:46 PM, Dave Dolson  > wrote:
>  
> Eric,
> Do I understand correctly from 
> https://tools.ietf.org/html/draft-bruneau-intarea-provisioning-domains-00#section-5.5
>  
> 
> that the intention is for the JSON key “captivePortal” to indicate that the 
> specified URL is to be visited by the browser to navigate the requirements 
> for exiting captivity?
>  
> If so, would you say this URL should be used in place of performing a capport 
> detection strategy (e.g., canary HTTP request)?
>  
> The idea with explicit PvD discovery is that it would, as a step, replace a 
> separate captive portal detection strategy.
>  
> My overall concern with discovery mechanisms that are specific to only 
> captive portals is that this is an extra step that is performed potentially 
> on every network association, that may have limited extensibility for 
> non-captive use cases. Since the explicit PvD design promises a way to 
> discover many properties beyond captivity, and is bootstrapped very early on 
> in the network association, it should hopefully allow clients to avoid the 
> extra probe.
> 
> 
>  
>  
>  
> Note: the same “captivePortal” key is also defined in section 5.3 as a 
> Boolean. Should I consider this to be a defect in the draft, or am I missing 
> something?
>  
> The updated version of the draft 
> (https://tools.ietf.org/html/draft-bruneau-intarea-provisioning-domains-01 
> ) 
> leaves out the specific keys for captive portals, and discusses it more 
> abstractly. That would be a good thing to nail down at the Prague meeting. If 
> PvD detection is done generically on network association, then a boolean or 
> some way to indicate that this is *not* a captive portal will allow the 
> device to not perform extra probing. If there is a captive network, we should 
> be able to get the page or instructions on how to get beyond captivity.
>  
> Thanks,
> Tommy
> 
> 
>  
> -Dave
>  
>  
>  
> From: Eric Vyncke (evyncke) [mailto:evyn...@cisco.com 
> ] 
> Sent: Sunday, June 25, 2017 8:27 PM
> To: Dave Dolson; captive-portals@ietf.org 
> Cc: David Bird
> Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"
>  
> At least Erik Kline and myself are following the captive-portal list :-)
>  
> And the more we think about it, PvD could really be useful and we, the PvD 
> I-D authors, would be pleased to present at your WG
>  
> -éric
>  
> From: Captive-portals