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

From: Warren Kumari <[email-masked]>
Date: Wed, 29 Apr 2015 16:32:26 -0400

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

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 30 Apr 2015 17:52:05 +0300

Hi Warren.

The security consideration (an attacker can send any arbitrary URL, and 
will redirect you at will) seems like a showstopper to me.

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.

Thanks,
	Yaron

---

From: Warren Kumari <[email-masked]>
Date: Thu, 30 Apr 2015 20:02:44 -0400

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.

> 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

---

From: Dave Dolson <[email-masked]>
Date: Fri, 1 May 2015 02:49:59 +0000

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

Thoughts?

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

---

From: David Bird <[email-masked]>
Date: Thu, 30 Apr 2015 21:29:07 -0700

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]> 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
> will
> with