Subject: Re: [Captive-portals] A new draft / idea - draft-wkumari-capport-icmp-unreach

From: Yaron Sheffer <[email-masked]>
Date: Fri, 01 May 2015 14:42:57 +0300

As a user, I have never seen a case where the captive portal is not on 
the same link as the client device, and never seen a case where an IP is 
obtained using a non-DHCP mechanism when in a CP setting. Can you give 
some concrete examples?

Thanks,
	Yaron

On 05/01/2015 05:49 AM, Dave Dolson wrote:
> I think it would be desirable to keep the captive portal mechanism independent of DHCP. The captive portal enforcement need not be on the same link as the user device. Furthermore, DHCP is not the only way to obtain an IP address.
>
> David Dolson
> Senior Software Architect, Sandvine Inc.
>    Original Message
> From: Warren Kumari
> Sent: Thursday, April 30, 2015 8:02 PM
> To: Yaron Sheffer
> Cc: [email-masked]
> Subject: Re: [Captive-portals] A new draft / idea - draft-wkumari-capport-icmp-unreach
>
>
> On Thu, Apr 30, 2015 at 10:52 AM, Yaron Sheffer <[email-masked]> wrote:
>> Hi Warren.
>>
>> The security consideration (an attacker can send any arbitrary URL, and will
>> redirect you at will) seems like a showstopper to me.
>
> Yeah, we were a bit freaked about that too :-)
>
> I have removed the URL / URI stuff - now this is simply annotates
> Destination Unreachable to explain that the reason for the Dest
> Unreachable is because of a captive portal.
>
>>
>> Also, once you have the DHCP mechanism, you can have client-initiated
>> communication to a well-defined interface, and you don't need to deal with
>> arbitrary connections being rejected. After all, the client needs to get an
>> IP address from DHCP before it can initiate any such connection.
>
>
> One reason that this is still useful is that eventually your captive
> portal connection will expire and the CP will close. If you have
> gotten CP information from DHCP, and then start getting these
> Destination Unreachables you will know to connect to the captive
> portal URL and pay again....
> So, basically, get CP information from DHCP and use it. After 4hours
> (or whatever), you start getting these new unrechables and know to
> connect and pay again...
>
> I think that the security implications are now the same as for
> "regular" (extended) Destination Unreachable.
>
> Thoughts?
>
> Thank you very much for your feedback,
> W
>
>>
>> Thanks,
>>          Yaron
>>
>>
>> On 04/29/2015 11:32 PM, Warren Kumari wrote:
>>>
>>> Hi y'all.
>>>
>>>
>>> So, this short document discusses another way for Captive Portals to
>>> inform users that they are behind a CP. Basically, it uses an extended
>>> ICMP Destination Unreachable message to let the host know that the
>>> reason it cannot reach a destination is because it is behind a CP and
>>> also includes a URL to reach the CP.
>>>
>>> This idea is mainly David's, I'm largely the editor. We'd really like
>>> some feedback on this idea and the implementation we've written up.
>>> Obviously the document would need a bunch more work, but we'd like to
>>> get some idea if folk think this is worth pursuing.
>>>
>>> URL:
>>>
>>> https://www.ietf.org/internet-drafts/draft-wkumari-capport-icmp-unreach-00.txt
>>> Status:
>>> https://datatracker.ietf.org/doc/draft-wkumari-capport-icmp-unreach/
>>> Htmlized:
>>> https://tools.ietf.org/html/draft-wkumari-capport-icmp-unreach-00
>>>
>>> It is somewhat similar to the wkumari-dhc-capport document, but solves
>>> a different issue, in a different way - I think that they are
>>> complementary documents.
>>>
>>>
>>> Any feedback gratefully accepted.
>>> W
>>>
>>
>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>     ---maf
>
> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals
>

---

From: Dave Dolson <[email-masked]>
Date: Fri, 1 May 2015 12:22:23 +0000

Any middlebox between user and server can block traffic and redirect http.
An IETF protocol should not mix layering or be limited to specific access technology.

IPv6 has ‎autoconfiguration for obtaining IP addresses.

3GPP has specific GTP-based mechanisms for obtaining IP addresses.

So DHCP isn't even always used to access the internet.

David Dolson
Senior Software Architect, Sandvine Inc.
  Original Message
From: Yaron Sheffer
Sent: Friday, May 1, 2015 7:43 AM
To: Dave Dolson; Warren Kumari
Cc: [email-masked]
Subject: Re: [Captive-portals] A new draft / idea - draft-wkumari-capport-icmp-unreach

Thanks,
        Yaron

---

From: Dave Dolson <[email-masked]>
Date: Fri, 1 May 2015 12:28:25 +0000

‎I like the ICMP idea because it is immediate, and can be applied to any traffic (not just http).

I think it even allows use cases where some traffic is permitted and other traffic denied. ‎ E.g., allow http to certain web sites, but otherwise access portal to unlock full features.

However, I'm concerned application software won't be able to receive these ICMP messages on most operating systems. I'm unsure about this.

David Dolson
Senior Software Architect, Sandvine Inc.
From: David Bird
Sent: Friday, May 1, 2015 12:29 AM
To: Dave Dolson
Cc: Warren Kumari; Yaron Sheffer; [email-masked]
Subject: Re: [Captive-portals] A new draft / idea - draft-wkumari-capport-icmp-unreach

I think there are two (probably more :) concepts at play here; assisting a client's captive portal discovery mechanism in identifying a CP network and the discovery of the login URL, and the notification ("hints") to the client about why connections failed (and to trigger a new CP detection loop), and when they may start failing. I tried to combine these with the optional URL/URI, but agree that's problematic. In the absence of CP info from DHCP (or RA), CP detection can do the current HTTP redirect check.

I think the ICMP notification mechanism is helpful, thoughts?

On Thu, Apr 30, 2015 at 7:49 PM, Dave Dolson <[email-masked]<mailto:[email-masked]>> wrote:
I think it would be desirable to keep the captive portal mechanism independent of DHCP. The captive portal enforcement need not be on the same link as the user device. Furthermore, DHCP is not the only way to obtain an IP address.

David Dolson
Senior Software Architect, Sandvine Inc.
  Original Message
From: Warren Kumari
Sent: Thursday, April 30, 2015 8:02 PM
To: Yaron Sheffer
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Captive-portals] A new draft / idea - draft-wkumari-capport-icmp-unreach

Thoughts?

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

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

---

From: David Bird <[email-masked]>
Date: Fri, 1 May 2015 09:48:53 -0700

With Linux, at least, I believe applications can make use of it immediately
using icmp(7) (requiring root or CAP_NET_RAW capabilities). I'm not aware
of any RFC4884 support in Linux, but it would be interesting to have
non-root applications access this data via an errno code and a subsequent
ioctl() call.

ICMP does allow for a more immediate notification and the possibility to
allow certain traffic, or all traffic for a certain time. Consider the
following case:

1) Client connects, he gets DHCP IP and CP info (a typical Hotspot)
2) Client does a HTTP redirect check anyway, it doesn't detect captive
portal (maybe he MAC-authed for a 30-min session)
3) After some time, he gets the ICMP/DestUnreach/Host/CP-Extension warnings
(CP discovery already knows the URL from step 1 and can prompt user)
4) After session expires, he gets ICMP/DestUnreach/AdminProhib/CP-Extension
fatals (CP discovery does HTTP redirect check to get URL)

In this scenario, I think it works well with the DHCP / RA idea - improving
the user experience.

David

On Fri, May 1, 2015 at 5:28 AM, Dave Dolson <[email-masked]> wrote:

> I think it even allows use cases where some traffic is permitted and other
> traffic denied. ‎ E.g., allow http to certain web sites, but otherwise
> access portal to unlock full features.
>
> However, I'm concerned application software won't be able to receive these
> ICMP messages on most operating systems. I'm unsure about this.
>
> David Dolson
> I think there are two (probably more :) concepts at play here; assisting a
> client's captive portal discovery mechanism in identifying a CP network and
> the discovery of the login URL, and the notification ("hints") to the
> client about why connections failed (and to trigger a new CP detection
> loop), and when they may start failing. I tried to combine these with the
> optional URL/URI, but agree that's problematic. In the absence of CP info
> from DHCP (or RA), CP detection can do the current HTTP redirect check.
>
> I think it would be desirable to keep the captive portal mechanism
> independent of DHCP. The captive portal enforcement need not be on the same
> link as the user device. Furthermore, DHCP is not the only way to obtain an
> IP address.
>
> David Dolson

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 03 May 2015 10:42:08 +0300

Hi Dave,

Yes, any middlebox can block/redirect traffic. But all clients must 
obtain an IP address before they send anything out.

I would say that both DHCP and IPv6 RA are in our scope. GTP is not, and 
in fact GTP captive portals (yes, these things do exist!) use 
alternative means to notify the user. My personal experience was that 
they'll send you an SMS.

DHCP is commonly used to provide various types of information about the 
local network, so what we're proposing to do is very common DHCP, and 
does not mix layers at all. See 
http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml#options

Thanks,
	Yaron

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Tue, 5 May 2015 17:46:53 +0200

> obtained using a non-DHCP mechanism when in a CP setting. Can you give

user   ]
(local ]---[ Corp Network ]
dhcp ) ]     |
             |   [ Corp Datacenter 1     ]   [ www gateway 1 ]
             |---[ with internal webapps ]---[ with captive  ]-|
             |   [ in direct access      ]   [ portal        ] |--[ W ]
             |                                                    [ W ]
             |   [ Corp Datacenter 2     ]   [ www gateway 2 ] |--[ W ]
             |---[ with internal webapps ]---[ with captive  ]-|
                 [ in direct access      ]   [ portal        ]
                          |
                 [ Permanent VPN tunnel ]
                          |
                 [ Partner datacenter   ]
                 [ and internal webapps ]
                 [ in direct access     ]

Two datacenters and www links since that's the minimum for business
continuity, can be more easily. Captive portal can and is dedicated to www
http(s) access not other firewalled protocols

If such configurations didn't exist there would be no need for pac files.

-- 
Nicolas Mailhot