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

From: Martin Thomson <[email-masked]>
Date: Wed, 02 May 2018 07:36:35 +0000

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 02 May 2018 08:06:11 -0400

> for signaling, such as a UDP packet to a registered port.

Have we considered TCP RST already? (I don't think it's better than ICMP, but
I don't remember it being discussed yet)

It seems like we are perhaps at the point where we need to explicitely
document the risk(s).

The only risk that I'm aware of is that the signal is sent from another party (maliciously).
Are there other risks that I have missed?

    > improvement.  More importantly, that we are not preventing the later

Agreed.

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 03 May 2018 01:02:34 +0000

> I don't remember it being discussed yet)

We can now if you like.  But not all protocols use TCP.

David (Bird) listed some of the things that are in common usage: ICMP
DestUnreach (no specific code), TCP RST, and dropping packets.  Each have
different characteristics.  I think that one product of the discussion in
London was that we don't need to be restricted to choosing from that set if
we think that there is something better.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 May 2018 09:21:22 -0400

> We can now if you like.  But not all protocols use TCP.

Yes, that's true, but essentially all of the "am I behind a captive portal"
probes do, and in the most restrictive places, that's all that works anyway.
We don't need every protocol to detect the captive portal, so long as *some*
method does.

There are two possibilities that I see with a TCP RST.

1) SYN -> RST.
   I am anware of anything that has ever put a TCP option on a TCP RST
   packet.  A quick review of rfc793 does not seem to forbid it, but
   would likely require kernel and API work to get it to the application.
   A nice point is that TCP RST gets turned into a synchronous error code on
   connect(2), and the application already has to pay attention to that.

2) SYN, SYN/ACK+option, ACK, RST.
   The TCP option goes in a more expected place, and to endpoints that do not
   speak it, this looks like the socket being closed immediately.

Some advantages:
     1) uses TCP sequence numbers for "security".
     Of course, like all other methods, any observer that can see the
     outgoing packet can spoof the responses.  But, it requires
     a passive observer that can inject packets to do that.  (Such an
     attacker can also just TCP RST every TCP connection, of course)

     2) it uses existing signaling.  No firewall (host or network based)
     can filter the TCP RST itself, although it might be confused by options
     present!!!  If it happens to work today (we'd have to do a test), then
     it probably won't change in the future, while ICMP seems to have an
     undeserved bad name.

Some disadvantages:
     1) changes required to host TCP stack!
     2) not possible for a captive portal detector application to just open a
        raw socket and look for things like ICMPs of a particular type.
     3) can not be used to remind the host to check with the API for imminent
        renewal, etc.

I think that the disadvantages and unlikelyhood that it would really work in
practice makes this a non-starter to me.

---

From: David Bird <[email-masked]>
Date: Thu, 03 May 2018 13:46:55 +0000

Agreed that TCP RST is a non-starter... While some NASs do it today, it is
protocol specific and can't convey the presence of a captive portal,
exactly; the client wouldn't know if the target server did the rst or the
NAS.

Also agreed, "ICMP seems to have an undeserved bad name"... We are looking
for a network signal - I think we already found one.

On Thu, May 3, 2018 at 6:21 AM Michael Richardson <[email-masked]>
wrote:

>     >> Have we considered TCP RST already? (I don't think it's better than
> ICMP,
>     >> but

---

From: Erik Kline <[email-masked]>
Date: Wed, 16 May 2018 22:49:44 +0900

> We don't need every protocol to detect the captive portal, so long as *some*

We really need to consider not just the likely traffic mix "on first
attach" as it stands today but also (a) changes in traffic mix in the
future and (b) signaling on "steady-state" traffic when a captive
portal re-asserts itself after session expiry (or on reboot / loss of
state at the enforcement point).

In the latter case especially, what becomes clear is that the UE needs
to be able to receive an unsolicited packet.  ICMP is a canonical
example of receiving and processing an unsolicited packet.  But it
could also be something like a UDP socket listening on a well known
port that receives a 1-byte datagram, which causes the UE to enqueue
(for rate-limiting purposes) a captive API query.

Naively, my expectation for a simple Android implementation was
something along the lines of:

    [1] on network attach, create an ICMP socket (or 2, one each for
v4 and v6) and attach a filter to only get messages of the right type
or code or whatever we decide.

    [2] when a matching packet arrives, lob a message over to
NetworkMonitor (which houses the captive portal checking logic).

    [3] NetworkMonitor already rate limits requests from applications
to revalidate the network, and these would likely be no different (or
pretty much the same).

Since the UE expected action, I'm assuming, would be to reconnect to
the API I'm not sure I see the benefit of any interaction more complex
than this.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 May 2018 19:16:39 -0400

> (for rate-limiting purposes) a captive API query.

On POSIX systems, it's clearly a lot easier to open a UDP socket from an
unpriviledged application than to open an ICMP socket.

Is this a consideration for you?

    > to revalidate the network, and these would likely be no different (or

Or would NetworkMonitor do this anyway, and it has all the priviledges it
needs anyway?

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

---

From: Vincent van Dam <[email-masked]>
Date: Thu, 17 May 2018 09:21:39 +0200

> On 16 May 2018, at 15:49, Erik Kline <[email-masked]> wrote:
> 

I think UDP on a well-known port could be a viable alternative to ICMP. The interface should have deliver at least the same level of trust as the ICMP unreachable can provide. In the unreachable ICMP it is possible to relate the packet to the packet that caused the notification. I am not claiming the UDP interface (or other interface) should use this exact same approach for reliability, but if we use it as just a single byte message, we would actually make it easier for malicious users to trigger calls to the capport-api (even though it’s rate limited). Maybe some token as payload, or a better idea that has lesser dependencies on moving parts in the capport deployment.

Gr.,
Vincent van Dam

---

From: Erik Kline <[email-masked]>
Date: Thu, 17 May 2018 17:00:27 +0900

> Or would NetworkMonitor do this anyway, and it has all the priviledges it

The fewer privilege escalation points the better, I suppose.  From that
perspective a UDP socket may be less concerning, but perhaps not by much.
NetworkMonitor has the appropriate privileges to do the needful, regardless.

---

From: Erik Kline <[email-masked]>
Date: Thu, 17 May 2018 17:09:01 +0900

> I think UDP on a well-known port could be a viable alternative to ICMP.
The interface should have deliver at least the same level of trust as the
ICMP unreachable can provide. In the unreachable ICMP it is possible to
relate the packet to the packet that caused the notification. I am not
claiming the UDP interface (or other interface) should use this exact same
approach for reliability, but if we use it as just a single byte message,
we would actually make it easier for malicious users to trigger calls to
the capport-api (even though it’s rate limited). Maybe some token as
payload, or a better idea that has lesser dependencies on moving parts in
the capport deployment.

Well, if we're doing application protocol stuff (like UDP), then perhaps we
could revisit the API key used for signing messages (which I think was
removed from the API doc :).

One problem with UDP is that if the enforcement point is well upstream of
several firewalls, it likely won't get through.

Consider the case of a DSLAM doing some captive portal enforcement on a
per-line-ID basis.  Originating a packet from the DSLAM back to the sender
can reasonably be expected to get to the home CPE (DSL modem), but if the
user has installed firewall devices downstream of this then ICMP stands a
better chance of getting through than UDP, I feel.

Thinking about this case in particular suggests to me that /new/ ICMP types
for "captive portal in force" may not work well either, as I strongly
suspect that firewall devices/software inspects ICMP messages.

---

From: Warren Kumari <[email-masked]>
Date: Thu, 17 May 2018 10:09:40 +0200

> NetworkMonitor has the appropriate privileges to do the needful,
regardless.

I'll start off by admitting that this is a cheap shot, but:
https://access.redhat.com/security/vulnerabilities/3442151

I'm uncomfortable with the "let's have all machines which might possibly
connect to a network with a captive portal have a daemon listening on a
well-known UDP port" idea. Yes, it is very similar to "let's have all
machines which might possibly connect to a network with a captive portal
have a thingie watching for special ICMP messages", but somehow it feels
very different. Yes, I understand the irony of building networks based on
what makes Warren uncomfortable,  but...

W

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
    ---maf

---

From: Erik Kline <[email-masked]>
Date: Thu, 17 May 2018 18:19:08 +0900

The point about UDP was primarily that the key attribute is the ability to
receive an unsolicited packet, not that it was better than ICMP.

> > >      > In the latter case especially, what becomes clear is that the
UE
> > needs

> > >      > to revalidate the network, and these would likely be no
different
> > (or

---

From: Michael Richardson <[email-masked]>
Date: Thu, 17 May 2018 09:57:21 -0400

> several firewalls, it likely won't get through.

... because random UDP is evil?
I thought it was just enterprise firewalls that felt this way.
Surely, people setting up a captive portal could configure things to work?

    > better chance of getting through than UDP, I feel.

I feel I need a digram to explain this.
(Is this even in scope?)

    > suspect that firewall devices/software inspects ICMP messages.

So, we should use an old type (unreachable), but a new code?
I sure prefer ICMP from an architectural point of view.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 17 May 2018 10:13:35 -0400

> https://access.redhat.com/security/vulnerabilities/3442151

(yeah, so that's as much about using shell for things it was never designed to do.)

    > what makes Warren uncomfortable,  but...

I agree, it's different. ICMP is generally handled centrally by the kernel,
and it isn't handed off to random shell scripts.  The kernel does some
validation of the incoming packet.