Subject: [Captive-portals] thoughts on two documents

From: Erik Kline <[email-masked]>
Date: Sun, 23 Apr 2017 23:41:10 +0900

All,

I have the vague feeling that there might be some general agreement around
the idea of having an ICMP unreachable code for captive portals (like an
HTTP 511 code [https://tools.ietf.org/html/rfc6585#section-6] for ICMP :-),
and it seems like there's no objection from captive portal implementers
with respect to the basic functional elements captured in
draft-larose-capport-architecture.

Where I think some rough spots might lie for both of these is in their
integration with as-yet-undecided new behaviour.

To that point, I would like to take my co-chair hat off and ask the authors
and the group for opinions of the following.

[ draft-wkumari-capport-icmp-unreach ]

There was some unresolved discussion about the contents of any included
extension. I wonder if the extra payload parts might be removed (Dave
Dolson's comment, I think?) and thereby simplify this version of the
document.  Given that Destination Unreachable is a TCP soft error (vis. RFC
5461) I'm not sure how much the proposed extra validation semantics are
really adding.

If the document simply said that receiving and authenticating an ICMP
message with the capport code generically "MAY/SHOULD trigger the receiving
node's captive portal handling subsystem", would that be something that
folks might agree on?

We'll need to run this whole thing by intarea and 6man as well, of course.

And nothing stops us from proposing a mulit-part extension to be optionally
included in a future document, once the captive portal interaction
recommendations are more fully understood.

[ draft-larose-capport-architecture ]

I felt it was promising to hear some agreement about the functional
elements of a captive portal system as documented.

Given that the captive portal interaction process is still on-going work,
would the document authors think it worth trying to advance the document
with either (a) section 3 removed or (b) section 3 rewritten to describe
broadly how most clients behave today?  Even given the variety of clients I
think it could be roughly captured (e.g. make a few sacrificial queries to
trigger DNS/HTTP rewrites, keep trying until a sacrificial query produces
an expected result while launching an HTTP-capable application, and so on).

-Erik

---

From: Dave Dolson <[email-masked]>
Date: Sun, 23 Apr 2017 16:09:26 +0000

Regarding the sacrificial q‎ueries, I would hope these are considered temporary measures to detect existing portals, not the preferred approach.

David Dolson
Sandvine
From: Erik Kline
Sent: Sunday, April 23, 2017 10:41 AM
To: David Bird; Kyle Larose
Cc: [email-masked]
Subject: [Captive-portals] thoughts on two documents

All,

I have the vague feeling that there might be some general agreement around the idea of having an ICMP unreachable code for captive portals (like an HTTP 511 code [https://tools.ietf.org/html/rfc6585#section-6] for ICMP :-), and it seems like there's no objection from captive portal implementers with respect to the basic functional elements captured in draft-larose-capport-architecture.

Where I think some rough spots might lie for both of these is in their integration with as-yet-undecided new behaviour.

To that point, I would like to take my co-chair hat off and ask the authors and the group for opinions of the following.

There was some unresolved discussion about the contents of any included extension. I wonder if the extra payload parts might be removed (Dave Dolson's comment, I think?) and thereby simplify this version of the document.  Given that Destination Unreachable is a TCP soft error (vis. RFC 5461) I'm not sure how much the proposed extra validation semantics are really adding.

If the document simply said that receiving and authenticating an ICMP message with the capport code generically "MAY/SHOULD trigger the receiving node's captive portal handling subsystem", would that be something that folks might agree on?

And nothing stops us from proposing a mulit-part extension to be optionally included in a future document, once the captive portal interaction recommendations are more fully understood.

I felt it was promising to hear some agreement about the functional elements of a captive portal system as documented.

Given that the captive portal interaction process is still on-going work, would the document authors think it worth trying to advance the document with either (a) section 3 removed or (b) section 3 rewritten to describe broadly how most clients behave today?  Even given the variety of clients I think it could be roughly captured (e.g. make a few sacrificial queries to trigger DNS/HTTP rewrites, keep trying until a sacrificial query produces an expected result while launching an HTTP-capable application, and so on).

-Erik

---

From: Erik Kline <[email-masked]>
Date: Mon, 24 Apr 2017 07:40:09 +0900

On 24 April 2017 at 01:09, Dave Dolson <[email-masked]> wrote:

> Regarding the sacrificial q‎ueries, I would hope these are considered
> temporary measures to detect existing portals, not the preferred approach.
>

If such a section were to be included then yes, I would think I needs to be
clear that it's documenting some current behaviour.

David Dolson
> Sandvine
> *From: *Erik Kline
> *Sent: *Sunday, April 23, 2017 10:41 AM
> *To: *David Bird; Kyle Larose
> *Cc: [email-masked]
> *Subject: *[Captive-portals] thoughts on two documents
>
> All,
>
> HTTP 511 code [https://tools.ietf.org/html/rfc6585#section-6] for ICMP
> :-), and it seems like there's no objection from captive portal
> implementers with respect to the basic functional elements captured in
> To that point, I would like to take my co-chair hat off and ask the
> authors and the group for opinions of the following.
>
> And nothing stops us from proposing a mulit-part extension to be
> optionally included in a future document, once the captive portal
> interaction recommendations are more fully understood.
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 24 Apr 2017 10:19:06 +0900

If by "temporary" you mean years or decades, then yes.

On Mon, Apr 24, 2017 at 1:09 AM, Dave Dolson <[email-masked]> wrote:

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 26 Apr 2017 12:34:37 -0400

Erik Kline <[email-masked]> wrote:
    > message with the capport code generically "MAY/SHOULD trigger the
    > receiving node's captive portal handling subsystem", would that be
    > something that folks might agree on?

I think we can agree on it.

    > interaction recommendations are more fully understood.

True. We just can't make any of the extensions critical.
I think that's okay, since ignoring the ICMP is also acceptable.

    > elements of a captive portal system as documented.

Please adopt it :-)

    > Given that the captive portal interaction process is still on-going
    > work, would the document authors think it worth trying to advance the
    > document with either (a) section 3 removed or (b) section 3 rewritten
    > to describe broadly how most clients behave today?

As a roadmap document, I have no problem with section 3 as is.

    > Even given the
    > variety of clients I think it could be roughly captured (e.g. make a
    > few sacrificial queries to trigger DNS/HTTP rewrites, keep trying until
    > a sacrificial query produces an expected result while launching an
    > HTTP-capable application, and so on).

I think that this is something the WG should do after adoption.
I think that there is some IPv6 flow missing, specifically for the case where
no DHCPv6 occured (SLAAC-only).  It could be that M=1 is mandatory for
captive portals.

Is there some reason we haven't adopted draft-nottingham-capport-problem-01 yet?
I would like the problem statement to outline the mechanisms used by current
captive portals and to give the mechanism names. e.g: DNS spoofing portal,
TCP-forced-proxy portal, etc.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 26 Apr 2017 12:36:17 -0400

> If by "temporary" you mean years or decades, then yes.

It's one reason I would like standardized terminology so that, in the logs of
the device, one can see what kind of captive portal was avoided, and by what
test it was detected.

    >     Regarding the sacrificial q‎ueries, I would hope these are
    > considered temporary measures to detect existing portals, not the
    > preferred approach.

    >     David Dolson Sandvine

    >      From: Erik Kline Sent: Sunday, April 23, 2017 10:41 AM To: David
    > Bird; Kyle Larose Cc: [email-masked] Subject:
    > [Captive-portals] thoughts on two documents

    >     I have the vague feeling that there might be some general agreement
    > around the idea of having an ICMP unreachable code for captive portals
    > (like an HTTP 511 code [https://tools.ietf.org/html/rfc6585#section-6]
    > for ICMP :-), and it seems like there's no objection from captive
    > portal implementers with respect to the basic functional elements
    > captured in draft-larose-capport-architecture.

    >     Where I think some rough spots might lie for both of these is in
    > their integration with as-yet-undecided new behaviour.

    >     There was some unresolved discussion about the contents of any
    > included extension. I wonder if the extra payload parts might be
    > removed (Dave Dolson's comment, I think?) and thereby simplify this
    > version of the document. Given that Destination Unreachable is a TCP
    > soft error (vis. RFC 5461) I'm not sure how much the proposed extra
    > validation semantics are really adding.

    >     If the document simply said that receiving and authenticating an
    > ICMP message with the capport code generically "MAY/SHOULD trigger the

    > to describe broadly how most clients behave today? Even given the

    >     _______________________________________________ Captive-portals
    > mailing list [email-masked]

    > _______________________________________________ Captive-portals mailing
    > list [email-masked]