Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 2 Jun 2017 12:47:53 +0000

On 5/31/17, 9:07 PM, "Martin Thomson" <[email-masked]> wrote:

    On 1 June 2017 at 08:23, Livingood, Jason <[email-masked]> wrote:
    > In any case, this is very much in scope IMO – so agree with others here. With the rise of IoT compromises the need for these sorts of notifications will only rise and will be critical to maintaining the security & integrity of the Internet.
    
    Just trying to understand this.  Jason, can you expand on your
    assertion that insertion of notices in HTTP messages (I assume
    response bodies) is critical to security & integrity?
    
[JL] I am not suggesting that insertion of notices in HTTP messages is the method to use (it just happens to be how we do it today). I’m merely confirming that others share the same use case specified by the German Federal Office for Information Security. FWIW, I presented on this need at the BoF IIRC. The RFC I referred to has some info as well, but it is not the best method which is why I hope that CAPPORT will provide a better alternative. 

[JL] But let me summarize the malware/hacked IoT device use case. A computing device is compromised and being used as part of a DDoS attack (a la the Dyn attack) or sending spam or doing keylogging or whatever. One alternative is to put them in a walled garden with CAPPORT whereby they have no access from any device in the home or, if the network architecture can do it, no access for only that specific device (other devices have unfettered access). The CAPPORT walled garden page would direct the device(s) or user(s) to a page explaining what the malware is and how to remediate, for example. Another alternative is a method to direct a device to a page / deliver a message about this malware issue without otherwise affecting or constraining their Internet access. In this alternative method, the objective is to get a critical security message to the user (e.g. Device X has malware Y and needs to be fixed ASAP) while not affecting things like gaming, OTT voice, OTT video, etc.

Jason

---

From: Martin Thomson <[email-masked]>
Date: Mon, 5 Jun 2017 19:15:20 +1000

On 2 June 2017 at 22:47, Livingood, Jason <[email-masked]> wrote:
> I’m merely confirming that others share the same use case specified by the German Federal Office for Information Security.

Yeah, I can agree that this is a very common desire.  And I'm glad
that it's the use case that matters, because I believe that the
specific methods you referred to are negatively regarded in many
circles.

The need to send notices with users with whom you don't have an active
communications session is why we developed web push, but that still
requires humans.  The "things" case is tricky, and I suspect that - at
list in the short term - CAPPORT won't have much to offer there.

Though I don't think that we need to abandon hope of finding some
options.  Again in web push we've had some success with voluntary
provision of contact details, see
https://tools.ietf.org/html/draft-ietf-webpush-vapid-02

---

From: Gunther Nitzsche <[email-masked]>
Date: Tue, 6 Jun 2017 16:08:10 +0200

On 02.06.2017 14:47, Livingood, Jason wrote:
> [JL] But let me summarize the malware/hacked IoT device use case. A computing device is compromised and being used as part of a DDoS attack (a la the Dyn attack) or sending spam or doing keylogging or whatever. One alternative is to put them in a walled garden with CAPPORT whereby they have no access from any device in the home or, if the network architecture can do it, no access for only that specific device (other 

> The CAPPORT walled garden page would direct the device(s) or user(s) to a page explaining what the malware is and how to remediate, for example. 

..And how to get out of the walled garden.  (nobody wants to stay there )

> Another alternative is a method to direct a device to a page / deliver a message about this malware issue without otherwise affecting or constraining their Internet access. In this alternative method, the objective is to get a critical security message to the user (e.g. Device X has malware Y and needs to be fixed ASAP) while not affecting things like gaming, OTT voice, OTT video, etc.

This alternative is no option. The device in question seems to be a real
danger for
other internet users and also for the device owner himself (like data
loss..).
Letting traffic be unaffected by a walled garden means that a
participation in
e.g. a DDoS attack will go on.  A differentiation between "internet" and
"voice" should be made though.
(skype would be considered as internet use) A POP-UP window or
notification during gaming / trading /
whatsoever will just be ignored or delete-clicked or not even noticed
because of not having a browser like tool.

But that is a topic for a different mailinglist - "how to react to
internet abuse". MAAWG and others are
discussing this for many years now ..:)    We do stop internet access in
case of abuse immediately
and have therefor built our own form of walled garden; others may have a
more tolerant view or just
have bad contracts with their customers :/

So it seems we agree that there are valid reasons for walled gardens -
now we should concentrate
on *how* to implement this in the best way.

(the 511 error page does not seem to be the worst variant.. if the user
sees an error in the browser
then the next reload puts him to the correct walled garden page)

best greetings,
Gunther

NetCologne Systemadministration

-- 
NetCologne Gesellschaft für Telekommunikation mbH
Am Coloneum 9 ; 50829 Köln
Geschäftsführer:   
  Timo von Lepel,
  Mario Wilhelm  
Vorsitzender des Aufsichtsrates:
  Dr. Andreas Cerbe
  HRB 25580, AG Köln

---

From: Erik Kline <[email-masked]>
Date: Mon, 12 Jun 2017 15:17:18 +0900

> then the next reload puts him to the correct walled garden page)

Some observations, and questions for the working group.

I'm not sure we have enough input on whether 511 is useful or not.  There
seemed to be some suggestion it would help, and some that it wouldn't.
Perhaps one question we could ask is whether it's harmful?  And if we agree
it's not harmful, is it worth developing some recommendations for its use?

As for the ICMP unreachable option, I certainly don't think it would be
harmful (with the extra URL bits removed for now).  Is that something we
wish to progress?

Given that we're probably looking at a portal detection method based on
entirely new work, it seems to me we're free to look at new things like
utilizing the PVD detection scheme (DNS queries for "provisioning domain
names", followed by other interaction still TBD).  Have the portal
implementors reviewed this and given consideration as to whether its
useful?  (I think of the discovery of the portal and subsequent interaction
with it as 2 separate processes conducted, obviously, in serial.)

Thoughts?

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Jun 2017 14:33:51 -0400

> I'm not sure we have enough input on whether 511 is useful or not.
    > There seemed to be some suggestion it would help, and some that it
    > wouldn't. Perhaps one question we could ask is whether it's harmful?
    > And if we agree it's not harmful, is it worth developing some
    > recommendations for its use?

I think you are asking the right question here.

    > As for the ICMP unreachable option, I certainly don't think it would
    > be harmful (with the extra URL bits removed for now). Is that
    > something we wish to progress?

I am keen to see it progress as you describe.

    > Given that we're probably looking at a portal detection method based
    > on entirely new work, it seems to me we're free to look at new things
    > like utilizing the PVD detection scheme (DNS queries for "provisioning
    > domain names", followed by other interaction still TBD). Have the
    > portal implementors reviewed this and given consideration as to
    > whether its useful? (I think of the discovery of the portal and
    > subsequent interaction with it as 2 separate processes conducted,
    > obviously, in serial.)

On this topic, I imagine you have all read about:
     https://www.malwaretech.com/2017/05/how-to-accidentally-stop-a-global-cyber-attacks.html

In which the investigator discovers that this malware looked for zones that
ought not to exist, and if they did, assumed it was in a quaranteen/lab..

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: David Bird <[email-masked]>
Date: Wed, 14 Jun 2017 06:36:00 -0700

> it's not harmful, is it worth developing some recommendations for its use?
In of itself, I don't believe it is harmful. However, if vendors use it as
a reason to continue to terminate TLS connection in order to deliver the
511, then perhaps it is a bit harmful - or at least misleading. As the
world moves to TLS (and QUIC), I think the time for the 511 code has
already passed, to some degree. That, combined with the fact you may still
have browsers not handling that return code properly, I don't see the value
for any vendor or venue to implement this.

> harmful (with the extra URL bits removed for now).  Is that something we
I will work on a new draft that is only the basics. The additional fields
could always be add in their own draft as extensions.

> with it as 2 separate processes conducted, obviously, in serial.)
I believe there are several talking points here, as the PvD method seems to
have several possible implementations.

I think requiring Ipv6 to configure Ipv4 is weird (I believe that was one
proposed method to convey configuration)

Several points I made in the thread "Arguments against any Capport API"
regarding a web service - detached from the NAS - controlling the
UE/station I think are relevant.

If the authors of the PvD concept (re-)present their I-D to the mailing
list, and stick around for discussion, that would be helpful.

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

---

From: Vincent van Dam <[email-masked]>
Date: Fri, 16 Jun 2017 19:55:47 +0000

> I'm not sure we have enough input on whether 511 is useful or not.  There seemed to be some suggestion
> it would help, and some that it wouldn't.  Perhaps one question we could ask is whether it's harmful?  And
> if we agree it's not harmful, is it worth developing some recommendations for its use?

I don’t think it’s harmful, and I don’t see why web browsers wouldn’t support it. What has been specified for this status code is basicly the status, and a custom error page with a html variant of a redirect. Web browsers, even if they don’t understand the full detail of the error, they will display the contents of the response. The browser will process the html of this customised error page and do the redirect.

But I don’t see this as a holy grail for improving capports (not at all). I see this as a feasible alternative for capport providers that are currently hijacking http traffic. In these implementations, they can “confuse”/“poison” cache and apis. They do this by using redirects or hosting an alternative capport site by hijacking the dns. In these situations, it would improve the experience if they would do a status code 511 and use that to move the user to the capport url.

As a recommendation; I would like to discourage any hijacking (http 30x and dns hijacking), but if a capport provider feels this is the way to go, I think we can point them to this ‘friendlier’ method.

> As for the ICMP unreachable option, I certainly don't think it would be harmful (with the extra URL bits
> removed for now).  Is that something we wish to progress?

I think this will be the best way to signal the UE, I am glad David is working on this :-)

> Given that we're probably looking at a portal detection method based on entirely new work, it seems to me
> we're free to look at new things like utilizing the PVD detection scheme (DNS queries for "provisioning
> domain names", followed by other interaction still TBD).  Have the portal implementors reviewed this and
> given consideration as to whether its useful?  (I think of the discovery of the portal and subsequent interaction

I think the multi-hop scenario forces us to think of alternative ways to discover the captive portal url when the UE did not receive it via dhcp. Without an alternative method, the icmp, relying on this url will only have a limited scope where it can be applied. Although this sounds much like an api, I think we should limit the functionality of it to what is required (the captive portal url as being the only identified requirement imo).

Gr., Vincent

---

From: Dave Dolson <[email-masked]>
Date: Fri, 23 Jun 2017 18:57:33 +0000

[resend with fewer recipients to avoid mailing list problems]

To echo David’s request,
> If the authors of the PvD concept (re-)present their I-D to the mailing list, and stick around for discussion, that would be helpful.

From: David Bird [mailto:[email-masked]]
Sent: Wednesday, June 14, 2017 9:36 AM
To: Erik Kline
Cc: Gunther Nitzsche; Mark Townsley; Heiko Folkerts; Martin Thomson; [email-masked]; Livingood, Jason; Herzig, Willi; Warren Kumari; Dave Dolson
Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"

On Sun, Jun 11, 2017 at 11:17 PM, Erik Kline <[email-masked]<mailto:[email-masked]>> wrote:
I'm not sure we have enough input on whether 511 is useful or not.  There seemed to be some suggestion it would help, and some that it wouldn't.  Perhaps one question we could ask is whether it's harmful?  And if we agree it's not harmful, is it worth developing some recommendations for its use?

In of itself, I don't believe it is harmful. However, if vendors use it as a reason to continue to terminate TLS connection in order to deliver the 511, then perhaps it is a bit harmful - or at least misleading. As the world moves to TLS (and QUIC), I think the time for the 511 code has already passed, to some degree. That, combined with the fact you may still have browsers not handling that return code properly, I don't see the value for any vendor or venue to implement this.

As for the ICMP unreachable option, I certainly don't think it would be harmful (with the extra URL bits removed for now).  Is that something we wish to progress?

I will work on a new draft that is only the basics. The additional fields could always be add in their own draft as extensions.

Given that we're probably looking at a portal detection method based on entirely new work, it seems to me we're free to look at new things like utilizing the PVD detection scheme (DNS queries for "provisioning domain names", followed by other interaction still TBD).  Have the portal implementors reviewed this and given consideration as to whether its useful?  (I think of the discovery of the portal and subsequent interaction with it as 2 separate processes conducted, obviously, in serial.)

I believe there are several talking points here, as the PvD method seems to have several possible implementations.

I think requiring Ipv6 to configure Ipv4 is weird (I believe that was one proposed method to convey configuration)

Several points I made in the thread "Arguments against any Capport API" regarding a web service - detached from the NAS - controlling the UE/station I think are relevant.

If the authors of the PvD concept (re-)present their I-D to the mailing list, and stick around for discussion, that would be helpful.

Thoughts?

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

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 26 Jun 2017 00:27:00 +0000

At least Erik Kline and myself are following the captive-portal list :-)

And the more we think about it, PvD could really be useful and we, the PvD I-D authors, would be pleased to present at your WG

-éric

From: Captive-portals <[email-masked]> on behalf of Dave Dolson <[email-masked]>
Date: Friday 23 June 2017 at 11:57
To: "[email-masked]" <[email-masked]>
Cc: David Bird <[email-masked]>
Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"

To echo David’s request,

Thoughts?

---

From: Erik Kline <[email-masked]>
Date: Tue, 27 Jun 2017 21:11:12 +0900

Dave,

Eric Vyncke (or another principal author) should have a presentation slot
in Prague to re-introduce us all and restart some discussion.

(Sorry for the long delay in responding.)

On 24 June 2017 at 03:57, Dave Dolson <[email-masked]> wrote:

> *From:* David Bird [mailto:[email-masked]]
> *Sent:* Wednesday, June 14, 2017 9:36 AM
> *To:* Erik Kline
> *Cc:* Gunther Nitzsche; Mark Townsley; Heiko Folkerts; Martin Thomson;
> [email-masked]; Livingood, Jason; Herzig, Willi; Warren Kumari;
> Dave Dolson
> *Subject:* Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"
>
>
>
> I believe there are several talking points here, as the PvD method seems
> to have several possible implementations.
>
>
>

---

From: Dave Dolson <[email-masked]>
Date: Tue, 27 Jun 2017 19:46:16 +0000

Eric,
Do I understand correctly from https://tools.ietf.org/html/draft-bruneau-intarea-provisioning-domains-00#section-5.5
that the intention is for the JSON key “captivePortal” to indicate that the specified URL is to be visited by the browser to navigate the requirements for exiting captivity?

If so, would you say this URL should be used in place of performing a capport detection strategy (e.g., canary HTTP request)?

Note: the same “captivePortal” key is also defined in section 5.3 as a Boolean. Should I consider this to be a defect in the draft, or am I missing something?

-Dave

From: Eric Vyncke (evyncke) [mailto:[email-masked]]
Sent: Sunday, June 25, 2017 8:27 PM
To: Dave Dolson; [email-masked]
Cc: David Bird
Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"

-éric

To echo David’s request,

Thoughts?