Hi Subash, 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). 2. Enforcement is referring to section 2.4 of the architecture document: https://tools.ietf.org/html/draft-ietf-capport-architecture-02#section-2.4 3. How would you expect the request/response to be different? That's assumed to be the request/response used within the TLS connection. Thanks, Tommy > On Jul 16, 2018, at 4:09 PM, Tirupachur Comerica, Subash > <[email protected]> wrote: > > Hi Tommy/Darshak, > Greetings! > > 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, > Subash > > From: Kyle Larose <[email protected] <mailto:[email protected]>> > Date: Friday, July 6, 2018 at 10:48 AM > To: "Tirupachur Comerica, Subash" <[email protected] > <mailto:[email protected]>> > Cc: "[email protected] > <mailto:[email protected]>" > <[email protected] > <mailto:[email protected]>>, "[email protected] > <mailto:[email protected]>" <[email protected] > <mailto:[email protected]>>, "[email protected] <mailto:[email protected]>" > <[email protected] <mailto:[email protected]>>, "[email protected] > <mailto:[email protected]>" <[email protected] > <mailto:[email protected]>> > Subject: Re: Comments/Queries on draft-ietf-capport-architecture > > 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. > > On 6 July 2018 at 13:43, Tirupachur Comerica, Subash > <[email protected] > <mailto:[email protected]>> wrote: > Hi Kyle, > 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. > > Thanks, > Subash > > > From: Kyle Larose <[email protected] <mailto:[email protected]>> > Date: Friday, July 6, 2018 at 4:46 AM > To: "Tirupachur Comerica, Subash" <[email protected] > <mailto:[email protected]>> > Cc: "[email protected] > <mailto:[email protected]>" > <[email protected] > <mailto:[email protected]>>, "[email protected] > <mailto:[email protected]>" <[email protected] > <mailto:[email protected]>>, "[email protected] <mailto:[email protected]>" > <[email protected] <mailto:[email protected]>>, "[email protected] > <mailto:[email protected]>" <[email protected] > <mailto:[email protected]>> > > Subject: Re: Comments/Queries on draft-ietf-capport-architecture > > Hi Subash, > > 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. > > On 5 July 2018 at 19:54, Tirupachur Comerica, Subash > <[email protected] > <mailto:[email protected]>> wrote: > Hi Kyle, > 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, > Subash > > From: Kyle Larose <[email protected] <mailto:[email protected]>> > Date: Tuesday, July 3, 2018 at 5:51 PM > To: "Tirupachur Comerica, Subash" <[email protected] > <mailto:[email protected]>> > Cc: "[email protected] > <mailto:[email protected]>" > <[email protected] > <mailto:[email protected]>>, "[email protected] > <mailto:[email protected]>" <[email protected] > <mailto:[email protected]>>, "[email protected] <mailto:[email protected]>" > <[email protected] <mailto:[email protected]>> > Subject: Re: Comments/Queries on draft-ietf-capport-architecture > > Thanks for the detailed feedback, Subash. I'll respond inline. > > On 2 July 2018 at 02:40, Tirupachur Comerica, Subash > <[email protected] > <mailto:[email protected]>> wrote: > Dear Authors, > > I was reviewing the new version of the draft and had the following > queries/comments. > > I) > > 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. > > II) > > 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 > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc2616%23section-14.1&data=01%7C01%7CSubash.TirupachurComerica%40arris.com%7Cec3104d8533b406e590d08d5e1483747%7Cf27929ade5544d55837ac561519c3091%7C1&sdata=I8ZnWtBFvDGJaHs8GkVMw6Ce3wEplIZ6M52tk8ohvmY%3D&reserved=0>) > 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: > > 1. The most recent API doc > (https://tools.ietf.org/html/draft-ietf-capport-api-01 > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-capport-api-01&data=01%7C01%7CSubash.TirupachurComerica%40arris.com%7Cec3104d8533b406e590d08d5e1483747%7Cf27929ade5544d55837ac561519c3091%7C1&sdata=TDrVeMfhSlUgqK7NlZFNHN7XGtyAqJPaKNvCFN5cSWc%3D&reserved=0>) > uses application/json-capport, so at the very least we need to update this\ > 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 identifty of the user equipment when interacting with each > > other. > > > 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 > > identifty 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. > > > > *sigh* > > > 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 > signals. > > 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) > > Thanks, > > Subash Tirupachur Comerica > > Ruckus Networks(An Arris Company) > > > > On 6/30/18, 5:04 AM, "IETF Secretariat" <[email protected] > <mailto:[email protected]>> wrote: > > > > > > Hello, > > > > This is a notification from the ID list for Captive Portal Interaction. > > > > Document: draft-ietf-capport-architecture, > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-capport-architecture%2F&data=01%7C01%7Csubash.tirupachurcomerica%40arris.com%7Cbae1510308a743e43f6d08d5de81ad83%7Cf27929ade5544d55837ac561519c3091%7C1&sdata=SCJ2Lo%2BpR%2BsghePG8oLxjZ2HV%2BkBZKqfOKO2nsfSTW0%3D&reserved=0 > > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-capport-architecture%2F&data=01%7C01%7Csubash.tirupachurcomerica%40arris.com%7Cbae1510308a743e43f6d08d5de81ad83%7Cf27929ade5544d55837ac561519c3091%7C1&sdata=SCJ2Lo%2BpR%2BsghePG8oLxjZ2HV%2BkBZKqfOKO2nsfSTW0%3D&reserved=0> > > > Change by Kyle Larose on 2018-06-30 05:04 PDT: > > > > New version available: *draft-ietf-capport-architecture-02.txt* > > > > Best regards, > > > > The Datatracker draft tracking service > > (for the IETF Secretariat) > > > > > > > >
_______________________________________________ Captive-portals mailing list [email protected] https://www.ietf.org/mailman/listinfo/captive-portals
