Thanks for your clarifications.
For 3) below.
In the example it would great if you explicitly either mark it as HTTPS request or add a phrase like over a TLS connection as shown below:
3.3. Example Exchange
over a TLS connection
To request the Captive Portal JSON content, a host sends an HTTPS GET
Thanks for reading the document! To respond to the individual comments:
1. Access to the Internet is indeed an example, but it is among the most reliable ways to distinguish a "captive" network from a "non-captive" network. Captive networks often do also allow access to walled-garden services, at varying levels
of authentication and payment. From the architecture document:
Captive Network: A network which limits communication of attached
devices to restricted hosts until the user has satisfied Captive
Portal Conditions, after which access is permitted to a wider set of
hosts (typically the internet).
3. How would you expect the request/response to be different? That's assumed to be the request/response used within the TLS connection.
I was going through the latest update of this draft and had the following questions/observations:
1) In the Introduction excerpt:
The state of captivity (whether or not the host has access to the Internet) - Here I believe Internet is just an example, it could be access to
any network, am I correct?
2) Is there any other reference that talks about Enforcement under section 2?
3) I found the example in section :3.3 was actually showing a HTTP request instead of HTTPS, while sections 2 and 3.1.1 strongly emphasizes HTTPS/authentication
for both API server and portal.
Thanks again for the input!
That's a good point about HTTPS vs HTTP. The document should never mention HTTP as part of the solution.
Thanks for CC’ing the right alias.
The draft seems to use HTTP / HTTPS interchangeably, maybe we should just stick with HTTPS then, to ensure the TLS protects the API server?
For example, the abstract says HTTP:
This document aims to document consensus on the 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.
I agree that the functionality bundling is a design decision and may not be architectural.
I still haven’t completely gone through the API draft you mention in II) below. I may come back to you on this for questions, inputs, if any.
Thanks again for the quick turn-around.
Subject: Re: Comments/Queries on draft-ietf-capport-architecture
captive-portals is the publicly archived list. I've copied it. I'll respond to your question inline.
For those on the list who haven't seen this yet, please read my previous reply. I had some thoughts related to the API in it.
Thanks for your response.
BTW, do you know if this is the right alias that gets archived? Otherwise can you please include the right alias?
Thanks for your responses.
I have a follow-up question.
1) Was it considered to provide two URIs during provisioning,
one for Server API and another for the actual web-portal, because that way it becomes more tough to break two systems to masquerade an end-user?
I don't think we ever seriously considered it.
a. In the current design, with just 1 URI returned during provisioning,
dns-spoofing the Server API URI and returning an eavesdropping web-portal can gather legitimate login/password.
Would this not lead to a failure to validate the tls certificate of the malicious server? From the document:
The API MUST use TLS for privacy and server authentication. The
implementation of the API MUST ensure both privacy and integrity of
any information provided by or required by it.
b. Secondly, may be, the API server may also send the Signal,
which is kept separate from the web-portal. I definitely like the word authenticity(that is mentioned below) and in this architecture, a single authenticity check for API server and Signal combo would suffice. However, this is bundling(co-hosting) the functionality
of Signaling to the API Server.
The Enforcement Device is logically responsible for triggering the signal, since it is the device which actually devices whether to block or allow traffic. That said, there is no reason it could not relay it through
the API server. Or, the API server could also be the enforcement device. However, those are design decisions for the protocol or deployment; I wouldn't want to tie down the options in the architecture. As you've noted it'd couple the functionality.
This is certainly an option to consider when we design the protocol!
But then, if the DHCP server is compromised, nothing much can be done.
Thanks for the detailed feedback, Subash. I'll respond inline.
I was reviewing the new version of the draft and had the following queries/comments.
In the excerpt below, isn’t it the network that decides the policy rules to configure the default route on the user equipment and not the user equipment’s operating system?
MAY restrict application access to networks not granting full
network access. E.g., a device connected to a mobile network may
be connecting to a WiFi network; the operating system MAY avoid
updating the default route until network access restrictions have
been lifted (excepting access to the Captive Portal server). This
has been termed "make before break".
A device may be connected to two independently managed networks, so at some point it will be faced with the decision to choose one over the other, particularly for cases where both networks advertise a default route.
Consider the common case of a mobile device connected to 4G. It is using that connection for all of its IP communication. Now consider that same device entering into the range of a known wifi hostpot. The hotspot is going to tell the device that it may be
used as its default route. Which should the device choose? My understanding is that typically the OS will favour wifi networks over mobile networks, since wifi tends not to be metered, and is often faster.
What this point is trying to capture is that the OS will first try to determine whether the wifi network actually has network connectivity prior to changing its routes. This prevents existing connections from needlessly
breaking if you've wandered into range of a broken/misconfigured/etc network.
In the excerpt below, sorry I could not clearly get if you meant the DHCP server or the web-server serving the captive portal page?
What exactly is the Accept field here, I didn’t find any mention in RFC 7710 as well.
For backwards compatibility, it is
RECOMMENDED that the server check the "Accept" field when serving the
URI , and serve HTML pages for "text/html" and serve the API for
"application/json". [REVISIT: are these details appropriate?]
This is talking about the web-server (aka the API).
We actually discussed this at IETF 101 if I remember correctly. The idea is that the client indicates in its http request accept header (https://tools.ietf.org/html/rfc2616#section-14.1)
what type of content the client expects. A legacy client would likely request text, and they certainly would not request json. Thus, by serving up a standard html page for the text/html case, we maintain backwards compatibility. On the other hand, for modern
clients, which will request application/json, we can serve up the API.
That said, there are two issues here for sure:
2. I don't see anything about accepting text to fall back to html in the api doc.
Ultimately, it feels to me like the architecture is providing too much detail--it should simply recommend some form of backwards compatibility mechanism, and some other document should specify the details of *how*
to provide that backwards compatibility. On the other hand, it doesn't seem like we've provided this mechanism in the API so far.
Does anyone remember what we concluded here at IETF 101? :) I don't see anything in the minutes.
III) Minor typos here:
3. User Equipment Identity
Multiple components in the architecture interact with both the User
Equipment and each other. Since the User Equipment is the focus of
these interactions, the components must be able to both identify the
user equipment from their interactions with it, and be able to agree
on the identi
fty of the user equipment when interacting with each
Whoops! I even ran it through a spell check. Must have missed that one. :)
3.2.3. Visible to the API
Since the API will need to perform operations which rely on the
fty of the user equipment, such as query whether it is captive,
the API needs to be able to relate requests to the User Equipment
making the request.
IV) For this step, how do you verify the plausibility(I guess it includes authenticity, integrity)?
5. The User Equipment verifies the signal is plausible.
It's not really well defined yet, since we haven't specified the signal. That said, we were considering signing the packet somehow, IIRC, or putting some hint that would be relatively hard to spoof if not on-path.
Perhaps authenticity is a better term?
Either way, the signal currently specifies these requirements, and now that I read them or the Nth time, it seems like we're not doing a good job of suggesting that the signal allow for validation/verification:
3. The protocol SHOULD have a method of identifying the source of
4. The signal SHOULD NOT include any information other than a prompt
to contact the API, and any information necessary for validation.
Do we really need to identify the source of the signals? Not unless the validation mechanism requires it. So, I think that #3 should be rephrased along the lines of:
"The protocol SHOULD have a method of validating that signals were sent by an enforcement device on the user equipment's path to the external network." (That last bit may be unnecessary... Trying to capture what
it means for the signal to be valid)
Subash Tirupachur Comerica
Ruckus Networks(An Arris Company)
On 6/30/18, 5:04 AM, "IETF Secretariat" <[email protected]> wrote:
This is a notification from the ID list for Captive Portal Interaction.
Change by Kyle Larose on 2018-06-30 05:04 PDT:
New version available: *draft-ietf-capport-architecture-02.txt*
The Datatracker draft tracking service
(for the IETF Secretariat)