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: captive-portals@ietf.org
Subject: Re: [Captive-portals] A new draft / idea -
draft-wkumari-capport-icmp-unreach
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: captive-portals@ietf.org
> Subject: Re: [Captive-portals] A new draft / idea -
> draft-wkumari-capport-icmp-unreach
>
>
> On Thu, Apr 30, 2015 at 10:52 AM, Yaron Sheffer <yaronf.i...@gmail.com> 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
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals
>
_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals
