Subject: [Captive-portals] Last Call: <draft-ietf-capport-architecture-08.txt> (CAPPORT Architecture) to Informational RFC

From: The IESG <[email-masked]>
Date: Mon, 11 May 2020 09:54:29 -0700

The IESG has received a request from the Captive Portal Interaction WG
(capport) to consider the following document: - 'CAPPORT Architecture'
  <draft-ietf-capport-architecture-08.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2020-05-25. Exceptionally, comments may
be sent to [email-masked] instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract

   This document describes a CAPPORT architecture.  DHCP or Router
   Advertisements, an optional signaling protocol, and an HTTP API are
   used to provide the solution.  The role of Provisioning Domains
   (PvDs) is described.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/

No IPR declarations have been submitted directly on this I-D.

---

From: Bob Harold <[email-masked]>
Date: Mon, 11 May 2020 13:35:59 -0400

I am curious why section 3.4 does not consider the MAC Address as a
possible identifier?

-- 
Bob Harold

On Mon, May 11, 2020 at 12:56 PM The IESG <[email-masked]> wrote:

> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals
>

---

From: "Tirupachur Comerica, Subash" <[email-masked]>
Date: Mon, 11 May 2020 17:50:02 +0000

Hi,
Sorry, I had sent these comments sometime back, a few are still valid.
Could you please take care of these?

Thanks,
Subash

From: "Tirupachur Comerica, Subash" <[email-masked]>
Date: Thursday, April 30, 2020 at 4:19 PM
To: "[email-masked]" <[email-masked]>
Subject: AD review of draft-ietf-capport-architecture-07

Hi,
I was reviewing this AD and found a few discrepancy needing clarifications, couple of them may just be editorial in nature.
Appreciate your response on this, thanks.

Thanks,
Subash

Section 1.2
Captive Network and Captive Portal are used interchangeably, so do we define captive portal or network or both? – [Pending]

Section 2.3
At minimum, the API MUST provide: (1) the state of captivity and (2) a URI for the Captive Portal Server. – [Pending]
-          However, in draft-ietf-capport-api, section 5: API State Structure, only "captive" (boolean): is mandatory whereas "user-portal-url" (string): is optional. One of these two drafts may need an update for consistency.

Section 2.6 Component Diagram
Although the Provisioning Service, API Server, and Web Portal Server functions are shown as discrete blocks, they could of course be combined into a single element. – [Pending]
-          Here may be we can add the [Captive Portal Enforcement] as well, for eg: API Server, Web Portal Server and Enforcement can co-exist on a single WiFi Access-Point using ACLs. Also there is a feeble reference to this co-location in Section 3.4.1

Section 3 Captive Portal Signal
Is Enforcement Device defined anywhere else? Is it same as Captive Portal Enforcement(I guess so) Or does it coordinate with it? – [Resolved, Please ignore]

From: Captive-portals <[email-masked]> on behalf of Bob Harold <[email-masked]>
Date: Monday, May 11, 2020 at 10:35 AM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, IETF-Announce <[email-masked]>, "[email-masked]" <[email-masked]>, Martin Thomson <[email-masked]>
Subject: Re: [Captive-portals] Last Call: <draft-ietf-capport-architecture-08.txt> (CAPPORT Architecture) to Informational RFC

I am curious why section 3.4 does not consider the MAC Address as a possible identifier? -- Bob Harold 
External ([email-masked]<mailto:[email-masked]>)
Report This Email<https://shared.outlook.inky.com/report?id=Y29tbXNjb3BlL3N1YmFzaC50aXJ1cGFjaHVyY29tZXJpY2FAY29tbXNjb3BlLmNvbS8zNzFmOTQzMDliODUzY2QzNTY0NmVlMjZhYWJlMWI2OS8xNTg5MjE4NjE2Ljg4#key=b689685d9a9a6794f20e6fff664abcc3>  FAQ<https://www.inky.com/banner-faq/>  Protection by INKY<https://www.inky.com>

I am curious why section 3.4 does not consider the MAC Address as a possible identifier?

--
Bob Harold

On Mon, May 11, 2020 at 12:56 PM The IESG <[email-masked]<mailto:[email-masked]>> wrote:

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked]<mailto:[email-masked]> mailing lists by 2020-05-25. Exceptionally, comments may
be sent to [email-masked]<mailto:[email-masked]> instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/<https://secure-web.cisco.com/1yVzqJ3UqY3xwLQUGHinMzu-7twa12PiLIN7EN50B62FLD0cXno02n3f_Qw7DSpKpG96CA7TKBLzu9xzC6TVQejhSfGo-jrF8DNmSa3LVszDOuk89O1tF28heTpZxo-Zl4Kzk3DxQoD5Hc8fDnwaLz69x04aBTgzTGR2Tf9ZMouiJgl4PjT97QOV7tu7viXpNVyNfM-2molaELtIJWJd00DqIJTzR2Hap7yETyceSjQTihOQh7tPi056W8nOWCQ-MxwbxsGzR5V37Soo1SFiKSaR_KHKYhK_NLd4ys-MQ_bKZmZiS_YEiEQX_q0lLjmFgTrqjGvQxzlOj0gwI4zthZQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-capport-architecture%2F>

_______________________________________________
Captive-portals mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/captive-portals<https://secure-web.cisco.com/1luUyQqfEnnX25r5RvmYXc4O6JMe744dFK_VSJQto5cvtJVqN7Y0Ie7SkRZBkDnAUWnL8L3b4ifd7pTzCT-EsrZmZhOLnLmd_gJDefmDNmw8a8wnbkHiR12asEIcSP9COhQWmnSY75DStoZ7N9Bidi67LQuNxiFexwf8r9J6F6QHrpMpgDgnqiyNKBaJcIC6GmF8UsF3j95f2eFjpdr_0ttHQuXj_XrxTJebBxaS3EdYg8OZsH713lH0DH-VYJ0a_IXiATDxiGaA7gvKppncYKLUo1Pi-xZ7HgL6prLTkzjLEwRFRGlYdkwrDLKV6zUZcbT23_4lyApm-XMaOQo4KZEFyQOebJB-U33Nrqn2nO7w/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcaptive-portals>

---

From: S Moonesamy <[email-masked]>
Date: Mon, 11 May 2020 12:24:19 -0700

Hello,
>comments on this action. Please send substantive comments to the

I took a quick look at the draft.  The third paragraph in the 
Introduction section states that the document standardizes an 
architecture for implementing captive portals.  Does it  meant that 
this draft is intended to be a standard?

The principles listed to guide the architecture looks more like 
requirements.  Anyone who has been at an airport understands that 
existing protocols are being intercepted, forged, broken, etc. to get 
to reach the user to go through the "captive" experience.  The 
"SHOULD NOT" (why are the words in uppercase?) comes out as a 
principle that "one should follow the existing standards".

What are there "MAY" principles?

This document is about the architecture.  Where does it provide for 
incremental migration?

On reading further, I would say that the draft is a mix of 
requirements and "solution" instead of a draft about architecture.

Regards,
S. Moonesamy

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 12 May 2020 08:46:27 +1000

Editors,

I've opened a few issues on the comments Subash indicated were still pending.  I think that we can take these as last call comments in the usual fashion.  I don't see a pressing reason to update the draft, but it would be nice if you could take a look at the remaining items to see if there is any action required.

On Tue, May 12, 2020, at 03:50, Tirupachur Comerica, Subash wrote:
> *From: *"Tirupachur Comerica, Subash" <[email-masked]>
> *Date: *Thursday, April 30, 2020 at 4:19 PM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *AD review of draft-ietf-capport-architecture-07
> 
> 
> Hi,
> 
> I was reviewing this AD and found a few discrepancy needing 
> clarifications, couple of them may just be editorial in nature.
> 
> *_Section 1.2_*
> Captive Network and Captive Portal are used interchangeably, so do we 
> define captive portal or network or both? – [Pending]
> 
> 
> *_Section 2.3_*
> 
> At minimum, the API MUST provide: (1) the state of captivity and (2) a 
> URI for the Captive Portal Server. – [Pending]
> 
> - However, in draft-ietf-capport-api, section 5: API State Structure, 
> only "captive" (boolean): is mandatory whereas "user-portal-url" 
> (string): is optional. One of these two drafts may need an update for 
> consistency.
> 
> *_ _*
> 
> *_Section 2.6 Component Diagram_*
> 
> Although the Provisioning Service, API Server, and Web Portal Server 
> functions are shown as discrete blocks, they could of course be 
> combined into a single element. – [Pending]
> 
> - Here may be we can add the [Captive Portal Enforcement] as well, for 
> eg: API Server, Web Portal Server and Enforcement can co-exist on a 
> single WiFi Access-Point using ACLs. Also there is a feeble reference 
> to this co-location in Section 3.4.1
> 
> 
> *_Section 3 Captive Portal Signal_*
> 
> Is Enforcement Device defined anywhere else? Is it same as Captive 
> Portal Enforcement(I guess so) Or does it coordinate with it? – 
> [Resolved, Please ignore]
> 
> 
> 
> *From: *Captive-portals <[email-masked]> on behalf of 
> Bob Harold <[email-masked]>
> *Date: *Monday, May 11, 2020 at 10:35 AM
> *To: *"[email-masked]" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, 
> "[email-masked]" 
> <[email-masked]>, "[email-masked]" 
> <[email-masked]>, IETF-Announce <[email-masked]>, 
> "[email-masked]" <[email-masked]>, Martin Thomson 
> <[email-masked]>
> *Subject: *Re: [Captive-portals] Last Call: 
> <draft-ietf-capport-architecture-08.txt> (CAPPORT Architecture) to 
> Informational RFC
> 
> 
> 
> > https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/ <https://secure-web.cisco.com/1yVzqJ3UqY3xwLQUGHinMzu-7twa12PiLIN7EN50B62FLD0cXno02n3f_Qw7DSpKpG96CA7TKBLzu9xzC6TVQejhSfGo-jrF8DNmSa3LVszDOuk89O1tF28heTpZxo-Zl4Kzk3DxQoD5Hc8fDnwaLz69x04aBTgzTGR2Tf9ZMouiJgl4PjT97QOV7tu7viXpNVyNfM-2molaELtIJWJd00DqIJTzR2Hap7yETyceSjQTihOQh7tPi056W8nOWCQ-MxwbxsGzR5V37Soo1SFiKSaR_KHKYhK_NLd4ys-MQ_bKZmZiS_YEiEQX_q0lLjmFgTrqjGvQxzlOj0gwI4zthZQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-capport-architecture%2F>
> > 
> > 
> > 
> > https://www.ietf.org/mailman/listinfo/captive-portals <https://secure-web.cisco.com/1luUyQqfEnnX25r5RvmYXc4O6JMe744dFK_VSJQto5cvtJVqN7Y0Ie7SkRZBkDnAUWnL8L3b4ifd7pTzCT-EsrZmZhOLnLmd_gJDefmDNmw8a8wnbkHiR12asEIcSP9COhQWmnSY75DStoZ7N9Bidi67LQuNxiFexwf8r9J6F6QHrpMpgDgnqiyNKBaJcIC6GmF8UsF3j95f2eFjpdr_0ttHQuXj_XrxTJebBxaS3EdYg8OZsH713lH0DH-VYJ0a_IXiATDxiGaA7gvKppncYKLUo1Pi-xZ7HgL6prLTkzjLEwRFRGlYdkwrDLKV6zUZcbT23_4lyApm-XMaOQo4KZEFyQOebJB-U33Nrqn2nO7w/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcaptive-portals>
>

---

From: "Tirupachur Comerica, Subash" <[email-masked]>
Date: Mon, 11 May 2020 23:20:37 +0000

Thanks Martin for raising the issues on git for tracking.

Thanks,
Subash

From: Martin Thomson <[email-masked]>
Date: Monday, May 11, 2020 at 3:46 PM
To: "Tirupachur Comerica, Subash" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Captive-portals] Last Call: <draft-ietf-capport-architecture-08.txt> (CAPPORT Architecture) to Informational RFC

Editors, I've opened a few issues on the comments Subash indicated were still pending. I think that we can take these as last call comments in the usual fashion. I don't see a pressing reason to upda
External ([email-masked]<mailto:[email-masked]>)
Report This Email<https://shared.outlook.inky.com/report?id=Y29tbXNjb3BlL3N1YmFzaC50aXJ1cGFjaHVyY29tZXJpY2FAY29tbXNjb3BlLmNvbS81ODQyZDA2YjU2YWIyZmZhZTU1Y2U0NDJmMzNjMWIwYi8xNTg5MjM3MjE1Ljky#key=2b97418ab930d7396312bfa062d59323>  FAQ<https://www.inky.com/banner-faq/>  Protection by INKY<https://www.inky.com>

Editors,

On Tue, May 12, 2020, at 03:50, Tirupachur Comerica, Subash wrote:

> > https://secure-web.cisco.com/15YygQHy-oelEGxcEL3bc0yBY6TF-VHfruXSf6FPzYwSgtjpWCr1CgRye3VNWf1t9h-rWjEyoiCxycEbzgM4E2NX6heccQhCGsh8UpqqgGoYguA10Fyv5zEaaY80-zR3SK6eFYcDZpb4FE7D-PjMtnB0PdF7JJeg-ehHQj3Bg-GVchuCNAJdJ_hgIDlcJUdmg5RokTl4EJSydiSNpHG6yfIuuR-hpfrPa64iMiOQDnAkCqg5GG092jgTsF6_hADsUFyvYISWUz7juEs-lovsptJ8dtWW2Y4IOMt5V9P6ltN99kIu9BbuE8DkobpGjYdizEJnK5BVTJB8KL9zjHNwjSg/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-capport-architecture%2F <https://secure-web.cisco.com/1yVzqJ3UqY3xwLQUGHinMzu-7twa12PiLIN7EN50B62FLD0cXno02n3f_Qw7DSpKpG96CA7TKBLzu9xzC6TVQejhSfGo-jrF8DNmSa3LVszDOuk89O1tF28heTpZxo-Zl4Kzk3DxQoD5Hc8fDnwaLz69x04aBTgzTGR2Tf9ZMouiJgl4PjT97QOV7tu7viXpNVyNfM-2molaELtIJWJd00DqIJTzR2Hap7yETyceSjQTihOQh7tPi056W8nOWCQ-MxwbxsGzR5V37Soo1SFiKSaR_KHKYhK_NLd4ys-MQ_bKZmZiS_YEiEQX_q0lLjmFgTrqjGvQxzlOj0gwI4zthZQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-capport-architecture%2F>

> > https://secure-web.cisco.com/19JFZdBEW3HbgyKwfA6173s7J4a8zv5vvOztdE6iJlssKD4bNLfbi87gxYkoUIM_JpR112JGLqAnoNvRQTPm_lFpjezWRmZbHWUG2W4a1rVp9pRqnmS3asoPidUlFdVnuWBehpP4bld0n-HIRQ3QKvS4L_oZEyJHQp3WjrtEhnSd9bGg65vt5vBwfsjUY1G5Ji_n7wK_ro1WD5v0G4jJdoOdjcCqgTQmAjwW0BVJLHSuBeb_2W7SCvM7_0jjZKOJu7zXXoEPGvYKjk288nQ0ipH4jU8xcvSLA_QX1BO6tAqbnL3btzMXt8UkZKuTEjAnlK73wIBUdJyacSwj5W-IUumL5GKDz-I66wHZKHqTV0ZM/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcaptive-portals <https://secure-web.cisco.com/1luUyQqfEnnX25r5RvmYXc4O6JMe744dFK_VSJQto5cvtJVqN7Y0Ie7SkRZBkDnAUWnL8L3b4ifd7pTzCT-EsrZmZhOLnLmd_gJDefmDNmw8a8wnbkHiR12asEIcSP9COhQWmnSY75DStoZ7N9Bidi67LQuNxiFexwf8r9J6F6QHrpMpgDgnqiyNKBaJcIC6GmF8UsF3j95f2eFjpdr_0ttHQuXj_XrxTJebBxaS3EdYg8OZsH713lH0DH-VYJ0a_IXiATDxiGaA7gvKppncYKLUo1Pi-xZ7HgL6prLTkzjLEwRFRGlYdkwrDLKV6zUZcbT23_4lyApm-XMaOQo4KZEFyQOebJB-U33Nrqn2nO7w/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcaptive-portals>

> https://secure-web.cisco.com/19JFZdBEW3HbgyKwfA6173s7J4a8zv5vvOztdE6iJlssKD4bNLfbi87gxYkoUIM_JpR112JGLqAnoNvRQTPm_lFpjezWRmZbHWUG2W4a1rVp9pRqnmS3asoPidUlFdVnuWBehpP4bld0n-HIRQ3QKvS4L_oZEyJHQp3WjrtEhnSd9bGg65vt5vBwfsjUY1G5Ji_n7wK_ro1WD5v0G4jJdoOdjcCqgTQmAjwW0BVJLHSuBeb_2W7SCvM7_0jjZKOJu7zXXoEPGvYKjk288nQ0ipH4jU8xcvSLA_QX1BO6tAqbnL3btzMXt8UkZKuTEjAnlK73wIBUdJyacSwj5W-IUumL5GKDz-I66wHZKHqTV0ZM/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcaptive-portals

---

From: Kyle Larose <[email-masked]>
Date: Tue, 12 May 2020 08:09:52 -0400

Hi Bob,

Thanks for the quick feedback.

> I am curious why section 3.4 does not consider the MAC Address as a possible identifier?

Its omission doesn't mean that the MAC Address is not a valid
identifier. One should evaluate it using the criteria provided in 3.2
and 3.3. When I wrote the skeleton of this section, I left the MAC
Address out more to keep the section short than anything, though I did
consider adding it.

Bob, do you think the MAC address needs to be considered in this
section for completeness?

How does the capport wg feel as a whole about this question?

Thanks,

Kyle

---

From: Bob Harold <[email-masked]>
Date: Tue, 12 May 2020 08:32:34 -0400

> section for completeness?

I won't argue too much if you decide to leave it out, but it seems like the
most obvious identifier, and is used by many things, so it would be good to
list its pros and cons.

> How does the capport wg feel as a whole about this question?

I am also wondering the same thing.

Thanks,

---

From: Kyle Larose <[email-masked]>
Date: Tue, 12 May 2020 08:45:44 -0400

Hello,

Thanks for the quick feedback

> this draft is intended to be a standard?

The draft is intended to be informational. We should probably rephrase
that section.

I have submitted a gh issue:
https://github.com/capport-wg/architecture/issues/74

> principle that "one should follow the existing standards".

I don't quite understand your point here.  Are you suggesting that because it
is commonly known that existing captive portal implementations do
these things, saying
that we should not do them instead means we should? Our goal is to
document an architecture
that allows providers to offer a service that does not use these
mechanisms. This is why we're
suggesting that a solution shouldn't do that. Do you have a suggestion
for alternate phrasing
that is less confusing?

> What are there "MAY" principles?

Perhaps we shouldn't be calling these principles, but rather the
requirements the document is
placing on a solution that will lead to a good outcome.

I've submitted https://github.com/capport-wg/architecture/issues/75
for us to consider reworking this section. I
welcome any suggestions for how to improve it.

> This document is about the architecture.  Where does it provide for

We don't have an explicit section, but we considered existing captive
portal implementations
when putting together the document. The new components are not tightly
coupled by the architecture,
meaning that any of them could be omitted. You wouldn't have the
functionality they provide, but
a solution without them would still work.

> requirements and "solution" instead of a draft about architecture.

I view an architecture as guidelines for how components of a system
interact as well as definitions
of those components. Perhaps that is the wrong view, but it is what I
think we documented.
The draft does talk about solutions, since the end goal of the
components we're describing is a solution to the problem
of providing internet access through wifi hotspots. It places
requirements on the components which form the system,
and their interactions

The document also provides examples for clarity. Perhaps the examples
consume too much of the document, making them seem
like recommendations for a particular solution, or the interactions
are not sufficiently abstract to allow for multiple solutions?

Does anything in particular stand out to you that warrants change?

Thanks,

Kyle

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 13 May 2020 09:48:41 +1000

On Tue, May 12, 2020, at 22:32, Bob Harold wrote:
> >  How does the capport wg feel as a whole about this question? [MAC as identifier]
> 

We did discuss this, if I recall.  From memory, there were a few reasons not to go further:

MAC randomization means that the identifier might not be stable (I don't think that this is relevant in retrospect as MAC is no worse in this way than IP)

The nature of MAC and what entities could access that information means that it is more vulnerable to spoofing.  That is, an entity that is not on the same network segment would be unable to see the MAC and verify that incoming data was attributed to the UE.

No one volunteered to do a more thorough analysis.  As we have the generic criteria Kyle refers to, that was considered enough.