Re: [Captive-portals] 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]> 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]>
Date: Tuesday, July 3, 2018 at 5:51 PM
To: "Tirupachur Comerica, Subash" <Subash.TirupachurComerica@arris.com>
Cc: "draft-ietf-capport-[email protected]" <draft-ietf-capport-[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[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 <Subash.TirupachurComerica@arris.com> 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) 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) 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" <ietf-secretariat-reply@ietf.org> 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



    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)