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
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
_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals
