Re: [Captive-portals] Signals from the network and ICMP

[Martin Thomson <[e-mail]>]

Just to reiterate what Erik said here.  Based on the discussion in London
we have a better (but not perfect) understanding of what a signal would
need to look like.  But until we have a concrete proposal that fits the
requirements, all we have is a liability.  As a chair, I'm interested in us
completing our work and decoupling a contentious - and therefore risky -
component allows us to complete some work.

I encourage those who believe that a signal is important to make a
proposal.  My strong sense from the group is that
draft-wkumari-capport-icmp-unreach is a too ambitious, but something along
the lines of what is currently described in the architecture document -
which is much more narrowly constrained along the lines Dave (Dolson)
described upthread - might reach consensus.

I think that we were close to agreement about a simple signal that prompted
checking with the API.  I know that David (Bird) has some reservations
about this regarding the layer at which signals are produced and consumed,
but my sense is that the group felt that it was easier if any rich
signaling was kept at a higher layer of the stack.

The form of that signal is next to consider.  We have discussed ICMP
DestUnreach with a both new and existing codes.  The feedback in London was
that maybe DestUnreach has some downsides and a new message would be
better.  A new ICMP message would allow for use prior to the network access
being revoked, so it has that in its favour.  Then there are other methods
for signaling, such as a UDP packet to a registered port.

If someone were willing to present a solution that meets all the
requirements (or presented arguments for why particular requirements aren't
applicable or necessary), then I think we could proceed and we would talk
about adoption.  That would allow all our documents to proceed together.

Until we have that proposal, this signaling channel is a risk.  The
solution we have isn't an ideal solution from all perspectives without this
signal.  However, I think that we have a substantial number of people (if
not consensus) that - even with no signal - what we have is an
improvement.  More importantly, that we are not preventing the later
addition of a signal.

Therefore, until we have a concrete solution, I suggest the following
concrete actions:

1. remove the "hmac-key" from the API (that's easy, and I think that we're
resolved on that point)

2. make the text on the signal generic rather than specifically talking
about ICMP

3. some to volunteer to design a simplified signal and propose a design

On this second point, I'd suggest that the editors hold off on making that
change so that we can let this discussion evolve a little more.  It seems
like we are still undecided here and I wouldn't want to make the change,
discover that we have a draft that has consensus, and then revert it soon
afterwards.

On Tue, May 1, 2018 at 1:56 PM Erik Kline <[e-mail]> wrote:

> I was unable to make it to London, but I was able to watch the session
> on Youtube.  The ICMP discussion begins here:

>      https://www.youtube.com/watch?v=tavhoXNVcP8&t=1h12m5s

> and carries on until Darshak's presentation starts at t=1h45m35s (a
> good 30+ minutes).

> My reading of that portion of the session was not that ICMP was
> "unsuitable", but rather that there wasn't consensus in the room to
> move forward with anything in particular at that time--other than a
> discussion about requirements (i.e. the thread to which Martin
> linked).

> I would say the aim here was to "unhook" the ICMP discussion from the
> other work (architecture-cum-API), so both could proceed at their
> relative paces.

> <chair_hat="off">

> There seemed to be much mic discussion about host behavior (possibly
> caching destination unreachables, the applicability of admin
> prohibiteds).  I wonder if we are in need of some kind of broader
> input on / more discussion of current popular OS behavior.

> On 16 April 2018 at 05:30, Dave Dolson <[e-mail]> wrote:
> > Having just re-read the thread, I disagree with this conclusion.
> >
> > There was a discussion about ICMP security and the conclusion that
treating
> > it as a hint to consult the API (rate limited) renders spoofed ICMP
messages
> > harmless.
> >
> > There was a discussion about whether alerts might be generated before
the
> > portal closes, which I think is feature creep.
> >
> > There was also a discussion about net neutrality (which parts of the
> > internet might be reachable), which seems orthogonal to mechanism.
> >
> > So I would like to know on what basis the chairs find ICMP unsuitable?
> >
> >
> > -Dave
> >
> >
> >
> > On 2018-04-13 6:14 AM, Martin Thomson wrote:
> >>
> >> Thanks to Lorenzo for kicking off the discussion about the desirable
> >> properties of a signal from the network.
> >>
> >> ( Thread starts:
> >>
> >>
https://mailarchive.ietf.org/arch/msg/captive-portals/pYYQqxAzJp8ZVLtfu1QLqJdMiiM/?qid=7c89d24eec00ff0608ee5398c9bb9d33
> >> )
> >>
> >> The chairs have discussed this and would like to confirm the following
> >> conclusions:
> >>
> >> 1. We don't have any current proposal for a signal that the group
> >> deems suitable.  For now, we will remove pieces from the API and
> >> architecture documents that specifically mention ICMP.
> >>
> >> 2. We will add a description of the properties we believe that a
> >> signal should have to the architecture document, but note that no such
> >> signal is defined.  That is, the signal will be sent by the network
> >> when it believes that a UE should check with the API for updated
> >> information.  The UE will treat that signal as a hint and may talk to
> >> the API as a result.  Rate-limiting will likely be needed.
> >>
> >> 3. We will consider a proposal to define a signal in future.  That
> >> would be a stand-alone proposal if it appeared.  To my reading, it is
> >> within our charter to take on work like that, but we would probably
> >> need to have a discussion with our AD at that point because we're
> >> already past our milestones.
> >>
> >>
> >> Does anyone disagree with these conclusions?  I don't think that this
> >> completely rules out the use of ICMP, though Destination Unreachable
> >> might not be an ideal fit as was discussed in London.
> >>
> >> _______________________________________________
> >> Captive-portals mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/captive-portals
> >
> >
> > _______________________________________________
> > Captive-portals mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/captive-portals
> _______________________________________________
> Captive-portals mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/captive-portals