Subject: [Captive-portals] Thinking of something related to captive portals for the ietf98 hackathon

From: Kyle Larose <[email-masked]>
Date: Wed, 22 Feb 2017 14:12:41 +0000

Hey everyone,

I was thinking of doing something (anything) related to captive portals for the ietf 98 hackathon. In particular, https://tools.ietf.org/html/draft-wkumari-capport-icmp-unreach-01 caught my eye. I was wondering if anyone had thoughts on that, and whether there is anything else they'd like to see me champion.

Thanks,

Kyle

---

From: David Bird <[email-masked]>
Date: Wed, 22 Feb 2017 06:31:21 -0800

Hi Kyle,

I think that is a great idea!

I had started to implement here:
https://github.com/coova/coova-chilli/tree/capport-icmp

What would be nice, in addition to the NAS changes, is to also demonstrate
the client side ... either something like icmpd
<https://github.com/snaewe/books-code/tree/master/unpv13e/icmpd> (to listen
for the ICMP and provide applications a way of checking the status of their
dest. unreach. connections), or the necessary Linux kernel changes. Also
with kernel changes, the I-D could also be implemented using iptables, or
other NAS software too.

Cheers,
David

On Wed, Feb 22, 2017 at 6:12 AM, Kyle Larose <[email-masked]> wrote:

> Hey everyone,
>
> I was thinking of doing something (anything) related to captive portals
> for the ietf 98 hackathon. In particular, https://tools.ietf.org/html/
> draft-wkumari-capport-icmp-unreach-01 caught my eye. I was wondering if
> anyone had thoughts on that, and whether there is anything else they'd like
> to see me champion.
>
> Thanks,
>
> Kyle
>
> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Feb 2017 23:42:24 +0900

I'm not a fan of the ICMP method. I think the security implications need
more thought.

As is, it looks like pretty much anyone on the Internet can send you one of
these packets, and you have no way of knowing if it's legitimate. Relying
on such an easy-to-spoof signal to decide that a network no longer provides
Internet access could be quite harmful, particularly if the receiving
device decided to switch to cellular data and incur the associated traffic
costs. Even if the signal is only taken as a hint to revalidate the
network, that still has battery implications.

It would seem to be much more useful to use:

   - A header in the initial redirect that captive portals almost always
   generate.
   - A well-known URL where the state of the captive portal can be
   revalidated, either periodically or when some other indication of loss of
   connectivity is observed.

At the last IETF we talked about possibly having a more structured way of
communicating this and other bits of information from captive portal to
host (a RESTful API, IIRC). That would also be useful, if we can all
collectively resist the temptation to overengineer such a mechanism. :-)

On Wed, Feb 22, 2017 at 11:31 PM, David Bird <[email-masked]> wrote:

> I had started to implement here: https://github.com/coova
> /coova-chilli/tree/capport-icmp
>
> <https://github.com/snaewe/books-code/tree/master/unpv13e/icmpd> (to
> listen for the ICMP and provide applications a way of checking the status
> of their dest. unreach. connections), or the necessary Linux kernel
> changes. Also with kernel changes, the I-D could also be implemented using
> iptables, or other NAS software too.
>
> Cheers,
> David
>
>
>> for the ietf 98 hackathon. In particular, https://tools.ietf.org/html/dr
>> aft-wkumari-capport-icmp-unreach-01 caught my eye. I was wondering if

---

From: Dave Dolson <[email-masked]>
Date: Wed, 22 Feb 2017 14:53:48 +0000

Lorenzo,
My interest in ICMP is that it could work with any protocol, not just HTTP, and doesn't require any MITM for HTTPS.
I recall a discussion about adding a difficult-to-guess token to the ICMP message, making it hard to spoof.

-Dave

________________________________
From: Captive-portals [[email-masked]] on behalf of Lorenzo Colitti [[email-masked]]
Sent: Wednesday, February 22, 2017 9:42 AM
To: David Bird
Cc: [email-masked]; Kyle Larose; [email-masked]
Subject: Re: [Captive-portals] Thinking of something related to captive portals for the ietf98 hackathon

I'm not a fan of the ICMP method. I think the security implications need more thought.

As is, it looks like pretty much anyone on the Internet can send you one of these packets, and you have no way of knowing if it's legitimate. Relying on such an easy-to-spoof signal to decide that a network no longer provides Internet access could be quite harmful, particularly if the receiving device decided to switch to cellular data and incur the associated traffic costs. Even if the signal is only taken as a hint to revalidate the network, that still has battery implications.

  *   A header in the initial redirect that captive portals almost always generate.
  *   A well-known URL where the state of the captive portal can be revalidated, either periodically or when some other indication of loss of connectivity is observed.

At the last IETF we talked about possibly having a more structured way of communicating this and other bits of information from captive portal to host (a RESTful API, IIRC). That would also be useful, if we can all collectively resist the temptation to overengineer such a mechanism. :-)

On Wed, Feb 22, 2017 at 11:31 PM, David Bird <[email-masked]<mailto:[email-masked]>> wrote:
Hi Kyle,

I had started to implement here: https://github.com/coova/coova-chilli/tree/capport-icmp

What would be nice, in addition to the NAS changes, is to also demonstrate the client side ... either something like icmpd<https://github.com/snaewe/books-code/tree/master/unpv13e/icmpd> (to listen for the ICMP and provide applications a way of checking the status of their dest. unreach. connections), or the necessary Linux kernel changes. Also with kernel changes, the I-D could also be implemented using iptables, or other NAS software too.

Cheers,
David

On Wed, Feb 22, 2017 at 6:12 AM, Kyle Larose <[email-masked]<mailto:[email-masked]>> wrote:
Hey everyone,

Thanks,

Kyle

_______________________________________________
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: Lorenzo Colitti <[email-masked]>
Date: Thu, 23 Feb 2017 00:24:03 +0900

Ok, but the implementations that are the most likely to implement this sort
of feature already send sacrificial plaintext HTTP requests on connect, and
are quite capable of generating HTTP requests on demand when they think
something is wrong.

On Wed, Feb 22, 2017 at 11:53 PM, Dave Dolson <[email-masked]> wrote:

> Lorenzo,
> My interest in ICMP is that it could work with any protocol, not just
> HTTP, and doesn't require any MITM for HTTPS.
> ------------------------------
> *From:* Captive-portals [[email-masked]] on behalf of
> Lorenzo Colitti [[email-masked]]
> *Sent:* Wednesday, February 22, 2017 9:42 AM
> *To:* David Bird
> *Cc:* [email-masked]; Kyle Larose; [email-masked]
> *Subject:* Re: [Captive-portals] Thinking of something related to captive
> portals for the ietf98 hackathon
>
> As is, it looks like pretty much anyone on the Internet can send you one
> of these packets, and you have no way of knowing if it's legitimate.
> Relying on such an easy-to-spoof signal to decide that a network no longer
> provides Internet access could be quite harmful, particularly if the
> receiving device decided to switch to cellular data and incur the
> associated traffic costs. Even if the signal is only taken as a hint to
> revalidate the network, that still has battery implications.
>
>> What would be nice, in addition to the NAS changes, is to also
>> demonstrate the client side ... either something like icmpd

---

From: David Bird <[email-masked]>
Date: Wed, 22 Feb 2017 07:26:46 -0800

Agreed, we can take measures to thwart spoofing and other attack vectors
that are already present with ICMP signaling.

I think a RESTful API is a good idea, one could argue it was already tried
with WISPr. Like WISPr, I think there would be problems with consistency. I
could imagine many web developers implementing the RESTful API with varying
degrees of features, compliance, bugs, etc.

---

From: Alexander Szlezak <[email-masked]>
Date: Wed, 22 Feb 2017 17:44:51 +0100

Hi David,

Nice to read you again. I could imagine the problems with consistency 
are related to complexity and poor documentation of wispr (especially of 
client side implementations) and could be mitigated by a simple and well 
documented RESTful API. I'm interested in more discussion related to 
this issue though.

best,

Alex

Am 22.02.17 um 16:26 schrieb David Bird:
> Agreed, we can take measures to thwart spoofing and other attack 
> vectors that are already present with ICMP signaling.
>
> I think a RESTful API is a good idea, one could argue it was already 
> tried with WISPr. Like WISPr, I think there would be problems with 
> consistency. I could imagine many web developers implementing the 
> RESTful API with varying degrees of features, compliance, bugs, etc.
>
>
>
> On Wed, Feb 22, 2017 at 6:53 AM, Dave Dolson <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Lorenzo,
>     My interest in ICMP is that it could work with any protocol, not
>     just HTTP, and doesn't require any MITM for HTTPS.
>     I recall a discussion about adding a difficult-to-guess token to
>     the ICMP message, making it hard to spoof.
>
>     -Dave
>
>
>
>     ------------------------------------------------------------------------
>     *From:* Captive-portals [[email-masked]
>     <mailto:[email-masked]>] on behalf of Lorenzo
>     Colitti [[email-masked] <mailto:[email-masked]>]
>     *Cc:* [email-masked] <mailto:[email-masked]>; Kyle Larose;
>     [email-masked] <mailto:[email-masked]>
>     *Subject:* Re: [Captive-portals] Thinking of something related to
>     captive portals for the ietf98 hackathon
>
>     As is, it looks like pretty much anyone on the Internet can send
>     you one of these packets, and you have no way of knowing if it's
>     legitimate. Relying on such an easy-to-spoof signal to decide that
>     a network no longer provides Internet access could be quite
>     harmful, particularly if the receiving device decided to switch to
>     cellular data and incur the associated traffic costs. Even if the
>     signal is only taken as a hint to revalidate the network, that
>     still has battery implications.
>
>       * A well-known URL where the state of the captive portal can be
>         revalidated, either periodically or when some other indication
>         of loss of connectivity is observed.
>
>     At the last IETF we talked about possibly having a more structured
>     way of communicating this and other bits of information from
>     captive portal to host (a RESTful API, IIRC). That would also be
>     useful, if we can all collectively resist the temptation to
>     overengineer such a mechanism. :-)
>
>         <https://github.com/coova/coova-chilli/tree/capport-icmp>
>
>         listen for the ICMP and provide applications a way of checking
>         the status of their dest. unreach. connections), or the
>         necessary Linux kernel changes. Also with kernel changes, the
>         I-D could also be implemented using iptables, or other NAS
>         software too.
>
>         Cheers,
>         David
>
>
>         On Wed, Feb 22, 2017 at 6:12 AM, Kyle Larose
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>             Hey everyone,
>
>             I was thinking of doing something (anything) related to
>             captive portals for the ietf 98 hackathon. In particular,
>             https://tools.ietf.org/html/draft-wkumari-capport-icmp-unreach-01
>             <https://tools.ietf.org/html/draft-wkumari-capport-icmp-unreach-01>
>             caught my eye. I was wondering if anyone had thoughts on
>             that, and whether there is anything else they'd like to
>             see me champion.
>
>             Thanks,
>
>             Kyle
>
>             [email-masked] <mailto:[email-masked]>
>             <https://www.ietf.org/mailman/listinfo/captive-portals>
>
>
>
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/captive-portals>
>
>
>
>
>

-- 
Follow us on Twitter @
http://twitter.com/unwirednetworks

Mag. Alexander Szlezak
Unwired Networks GmbH
Founder & CEO

+43 660 1350410
[email-masked]
www.unwired.at

Gonzagagasse 11/25
1010 Vienna
Austria

Support: [email-masked]

---

From: Dave Dolson <[email-masked]>
Date: Wed, 22 Feb 2017 17:04:21 +0000

As I understand it, to "think something is wrong" requires an application-layer timeout. Some people think this is about 5s, but I don't believe TCP specifies an upper bound.

An ICMP message can give an "instant" response.

It's worth considering that the ICMP message may trigger the "sacrificial" HTTP request by the operating system.

________________________________
From: Lorenzo Colitti [[email-masked]]
Sent: Wednesday, February 22, 2017 10:24 AM
To: Dave Dolson
Cc: David Bird; [email-masked]; Kyle Larose; [email-masked]
Subject: Re: [Captive-portals] Thinking of something related to captive portals for the ietf98 hackathon

Ok, but the implementations that are the most likely to implement this sort of feature already send sacrificial plaintext HTTP requests on connect, and are quite capable of generating HTTP requests on demand when they think something is wrong.

On Wed, Feb 22, 2017 at 11:53 PM, Dave Dolson <[email-masked]<mailto:[email-masked]>> wrote:
Lorenzo,
My interest in ICMP is that it could work with any protocol, not just HTTP, and doesn't require any MITM for HTTPS.
I recall a discussion about adding a difficult-to-guess token to the ICMP message, making it hard to spoof.

-Dave

________________________________
From: Captive-portals [[email-masked]<mailto:[email-masked]>] on behalf of Lorenzo Colitti [[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, February 22, 2017 9:42 AM
To: David Bird
Cc: [email-masked]<mailto:[email-masked]>; Kyle Larose; [email-masked]<mailto:[email-masked]>
Subject: Re: [Captive-portals] Thinking of something related to captive portals for the ietf98 hackathon

Cheers,
David

Thanks,

Kyle

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 23 Feb 2017 02:05:57 +0900

The ability for any host in the Internet to trigger an instant response
sounds it could turn into a DOS vector, though.

On Thu, Feb 23, 2017 at 2:04 AM, Dave Dolson <[email-masked]> wrote:

> As I understand it, to "think something is wrong" requires an
> application-layer timeout. Some people think this is about 5s, but I don't
> believe TCP specifies an upper bound.
>
> *From:* Lorenzo Colitti [[email-masked]]
> *Sent:* Wednesday, February 22, 2017 10:24 AM
> *To:* Dave Dolson
> *Cc:* David Bird; [email-masked]; Kyle Larose; [email-masked]
>
> Ok, but the implementations that are the most likely to implement this
> sort of feature already send sacrificial plaintext HTTP requests on
> connect, and are quite capable of generating HTTP requests on demand when
> they think something is wrong.
>
>>>> for the ietf 98 hackathon. In particular,
>>>> caught my eye. I was wondering if anyone had thoughts on that, and whether
>>>> there is anything else they'd like to see me champion.
>>>>
>>>> Thanks,
>>>>
>>>> Kyle
>>>>

---

From: Dave Dolson <[email-masked]>
Date: Wed, 22 Feb 2017 17:07:40 +0000

Agreed. Hence the discussion about using a difficult-to-guess token in the message.

Sent: Wednesday, February 22, 2017 12:05 PM

The ability for any host in the Internet to trigger an instant response sounds it could turn into a DOS vector, though.

On Thu, Feb 23, 2017 at 2:04 AM, Dave Dolson <[email-masked]<mailto:[email-masked]>> wrote:
As I understand it, to "think something is wrong" requires an application-layer timeout. Some people think this is about 5s, but I don't believe TCP specifies an upper bound.

________________________________
From: Lorenzo Colitti [[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, February 22, 2017 10:24 AM
To: Dave Dolson
Cc: David Bird; [email-masked]<mailto:[email-masked]>; Kyle Larose; [email-masked]<mailto:[email-masked]>

-Dave

Cheers,
David

Thanks,

Kyle

---

From: David Bird <[email-masked]>
Date: Wed, 22 Feb 2017 09:10:51 -0800

Further, we could tie this to RFC 7710, so that you can disregard this ICMP
from networks not expected to be captive portal and networks who do
implement captive portal can easily (as in iptables rules) filter out
external ICMP of this nature.

On Wed, Feb 22, 2017 at 9:07 AM, Dave Dolson <[email-masked]> wrote:

> *Sent:* Wednesday, February 22, 2017 12:05 PM
>
> *To:* Dave Dolson
>> It's worth considering that the ICMP message may trigger the
>> "sacrificial" HTTP request by the operating system.
>>
>>
>>
>>>    - A header in the initial redirect that captive portals almost
>>>    always generate.
>>> At the last IETF we talked about possibly having a more structured way
>>> of communicating this and other bits of information from captive portal to
>>>>> I was thinking of doing something (anything) related to captive
>>>>> portals for the ietf 98 hackathon. In particular,

---

From: David Farmer <[email-masked]>
Date: Wed, 22 Feb 2017 11:34:13 -0600

I agree this is a DOS attack vector, but is it any worse than the TCP SYN
attack vector, and any reason it can't be mitigated similarly with some
rate control?  Yes, a naively defined ICMP message would be really bad, but
I think a carefully defined one could work.

Another possible mittigation, only accepting the ICMP message form sources
within the same /48 as the host receiving the message, combine this with
BCP-38 filtering and you have drastically limited the scope of who could
launch such a DOS attack. This requires the captive portal redirector, not
necessarily the captive portal itself, to be within the same /48, but that
doesn't seem like its too onerous of a requirement.  You could make it the
same /64, but that might be too restrictive in some larger scale captive
portal implementations.

Thanks.

---

From: Erik Kline <[email-masked]>
Date: Thu, 23 Feb 2017 11:51:33 +0900

How onerous would it be to require that an ICMPv[46] message with a captive
portal code also have a hoplimit of 255 (i.e. be link-local / from an
on-link source)?

I could imagine writing a user-space daemon that listens for ICMP message
of one specific type, and validates the hoplimit with traditional cmsg
tricks.  Furthermore, only having to do so on networks advertising a 7710
option would be good.

On 23 February 2017 at 02:10, David Bird <[email-masked]> wrote:

> Further, we could tie this to RFC 7710, so that you can disregard this
> ICMP from networks not expected to be captive portal and networks who do
>>>> *From:* Captive-portals [[email-masked]] on behalf
>>>> of Lorenzo Colitti [[email-masked]]
>>>> As is, it looks like pretty much anyone on the Internet can send you
>>>> one of these packets, and you have no way of knowing if it's legitimate.

---

From: Dave Dolson <[email-masked]>
Date: Thu, 23 Feb 2017 14:27:03 +0000

Erik,
I don’t think it is onerous.
But, the device causing captive portal is not always on the local subnet of the end-user device.

I think it is better to have a security scheme that doesn’t depend on TTL.

-Dave

From: Erik Kline [mailto:[email-masked]]
Sent: Wednesday, February 22, 2017 9:52 PM
To: David Bird
Cc: Dave Dolson; [email-masked]; Kyle Larose; [email-masked]; Lorenzo Colitti
Subject: Re: [Captive-portals] Thinking of something related to captive portals for the ietf98 hackathon

How onerous would it be to require that an ICMPv[46] message with a captive portal code also have a hoplimit of 255 (i.e. be link-local / from an on-link source)?

I could imagine writing a user-space daemon that listens for ICMP message of one specific type, and validates the hoplimit with traditional cmsg tricks.  Furthermore, only having to do so on networks advertising a 7710 option would be good.

On 23 February 2017 at 02:10, David Bird <[email-masked]<mailto:[email-masked]>> wrote:
Further, we could tie this to RFC 7710, so that you can disregard this ICMP from networks not expected to be captive portal and networks who do implement captive portal can easily (as in iptables rules) filter out external ICMP of this nature.

On Wed, Feb 22, 2017 at 9:07 AM, Dave Dolson <[email-masked]<mailto:[email-masked]>> wrote:

To: Dave Dolson

-Dave

Cheers,
David

Thanks,

Kyle

---

From: Kyle Larose <[email-masked]>
Date: Thu, 23 Feb 2017 17:01:35 +0000

Alright. Thanks everyone for the great discussion. Please continue. ☺

It sounds like there may be some value in making more progress on the ICMP message simply so we can play around with exposing any security holes, and finding ways to plug them. So, it still seems like a good hackathon candidate to me.

Also, since this is a hackathon, why not try to work on more than I can possibly handle? Let’s try to tackle the REST API for RFC 7710 as well. I’ll admit that I’m awful at defining REST APIs, and I don’t really have much experience with this technology, so I’m probably not right to do it, but maybe someone else could help contribute?

Can someone maybe confirm the intent of the REST API? I vaguely recall a discussion at the BoF about allowing less interactive devices, such as smart watches, to authenticate without needing a browser. Was that it?

There were some volunteers for writing a document defining the aforementioned REST API at the BoF. Is there a rough draft we could work from at the hackathon?

Anyway, I think I’ll add the following to the hackathon wiki:

Technology: Captive Portal
Projects

·         Finish up the icmp I-D in coova-chili

·         Try out various client solutions for consuming the icmp message.

·         Try to find security holes in the icmp I-D, and plug them (the output being suggestions to improve the I-D)

·         Work on defining and implementing a REST API for RFC 7710

How does that sound?

Thanks,

Kyle

From: Dave Dolson
Sent: Thursday, February 23, 2017 9:27 AM
To: Erik Kline; David Bird
Cc: [email-masked]; Kyle Larose; [email-masked]; Lorenzo Colitti
Subject: RE: [Captive-portals] Thinking of something related to captive portals for the ietf98 hackathon

Erik,

-Dave

To: Dave Dolson

-Dave

Cheers,
David

Thanks,

Kyle