Re: [Captive-portals] Questions about PvD/API

[Martin Thomson]

Hmm, maybe we understand this very differently then.  I see PvD as
providing configuration in exactly the same way as 7710 does.

That is,

* 7710 says "here is the URL you go to for ???"  where "???" is one or
both of "web browsing" and "API" (see the API doc).  It doesn't really
say whether the endpoint is currently captive or not (and nor can it
do so).

* PvD, as I understand it, would say the same, though it might provide
separate "web browsing" and "API" URLs, if we accept that an API is
valuable (see below).  It *could* also act in the "API" role, and I
think that Tommy in particular finds that idea appealing, but my
understanding was that we would consider that to be a logically
distinct function.

If, as we seem to have agreed in Prague, consider API to be basically
reduced to "am I captive? y/n" and maybe "for how long? " for
now.

You seem to be most concerned about the potential for an API that
could make claims about whether a given host is captive or not.  Is
that the source of your concerns here?

If we agree - as seem to, based on your comments here - that the
configuration of a URL has no effect until the host discovers that it
is captive (somehow), is this a concern more about the API than the
existence of a mechanism like PvD?

(NOC == NIC?)

On 25 August 2017 at 11:49, David Bird  wrote:
> I don't see RFC7710 grouped with PvD and vs ICMP. In fact, RFC7710 is
> required in the ICMP draft.
>
> So, it should be 7710 & ICMP vs PvD. Nobody is arguing 7710 should stand
> alone, or is useful by itself.
>
> There are unique considerations when the captive portal "client" is a router
> and not the UE... In this example, no clients get 'released' from captivity
> - so, it doesn't really have to trace clients by IP address. The CPE
> firmware needs updating to have RFC7710 configurable via their management
> system -- this might be a good opportunity to have a minimal Capport ICMP
> based captive portal implemented completely in CPE firmware, perhaps Linux
> iptables w/Capport ICMP support. Assuming they don't do that (but do get RFC
> 7710 supported), the CPE can be configuring clients for Capport and ICMP
> coming multiple hops away.. validated by (yet to be defined) material in the
> original DHCP/RA, is just fine... (better, maybe the CPE reconfigures into a
> bridge and has a L2 capport in the NOC, which can maybe help users identity
> exactly which machine has the virus)
>
> There is no harm, btw, in having RFC7710 *always* configured in networks
> that support features like this... it could be a multi-purpose portal. RFC
> 7710 should always be ignored until (yet to be defined) notification is
> received.
>
>
>
>
>
>
> On Thu, Aug 24, 2017 at 4:55 PM, Martin Thomson 
> wrote:
>>
>> What is interesting about Heiko's example here is that this transition
>> is not necessarily visible to endpoints. Nor can they be forewarned
>> (assuming they are ignorant of the botnet using their link).
>> Endpoints were previously on a network without a captive portal, but
>> one is suddenly interjected.
>>
>> I see several problems, different for each of the various solutions:
>>
>> * With 7710 or PvD, the original network would have to be provisioned
>> with a captive portal, or the switch would happen and the endpoint
>> won't have a URI to talk to.  That seems relatively tractable,
>> providing that this didn't lead to a false assumption of captivity
>> (this is a problem with 7710, I think, because the existence of the
>> option seems to imply captivity, though this is quite unclear from the
>> RFC).
>>
>> * With ICMP, the signal comes from more than one hop away.  An
>> unmodified router in the home would receive the ICMP message, reduce
>> the TTL and then it looks like a random Internet host was trying to
>> deny service.
>>
>> So running through all the combinations:
>>
>> 7710/PvD + ICMP - you know where to go to get status information and
>> the network can signal
>>
>> 7710/PvD - ICMP - you know where to go to get status information, but
>> how would you decide to ask?  Is there some other trigger you would
>> use?  (This is, I think Vincent's question.)
>>
>> ICMP - 7710/PvD - you get a signal, but is it legit?  How do you validate
>> it?
>>
>> Neither - that's the situation we have today.
>>
>> It seems that there are at least a few people who think that this use
>> case is in scope.  It doesn't seem materially different from the case
>> where you run out of bytes (for networks that do accounting that way).
>> Maybe this use case can inform the design a little better.  Or maybe
>> someone would like to argue that we don't need to worry about this.
>>
>>
>>
>> On 25 August 2017 at 06:58, Vincent van Dam  wrote:
>> > I agree that the information you describe should be pulled from
>> > somewhere,
>> > however, I am more concerned _when_ they should be pulled.
>> >
>> >
>> > In this working group we acknowledged (welcomed) use cases that go
>> > beyond
>> > connecting to a network; the latest ex

Re: [Captive-portals] Questions about PvD/API

[David Bird]

I don't see RFC7710 grouped with PvD and vs ICMP. In fact, RFC7710 is
required in the ICMP draft.

So, it should be 7710 & ICMP vs PvD. Nobody is arguing 7710 should stand
alone, or is useful by itself.

There are unique considerations when the captive portal "client" is a
router and not the UE... In this example, no clients get 'released' from
captivity - so, it doesn't really have to trace clients by IP address. The
CPE firmware needs updating to have RFC7710 configurable via their
management system -- this might be a good opportunity to have a minimal
Capport ICMP based captive portal implemented completely in CPE firmware,
perhaps Linux iptables w/Capport ICMP support. Assuming they don't do that
(but do get RFC 7710 supported), the CPE can be configuring clients for
Capport and ICMP coming multiple hops away.. validated by (yet to be
defined) material in the original DHCP/RA, is just fine... (better, maybe
the CPE reconfigures into a bridge and has a L2 capport in the NOC, which
can maybe help users identity exactly which machine has the virus)

There is no harm, btw, in having RFC7710 *always* configured in networks
that support features like this... it could be a multi-purpose portal. RFC
7710 should always be ignored until (yet to be defined) notification is
received.






On Thu, Aug 24, 2017 at 4:55 PM, Martin Thomson 
wrote:

> What is interesting about Heiko's example here is that this transition
> is not necessarily visible to endpoints. Nor can they be forewarned
> (assuming they are ignorant of the botnet using their link).
> Endpoints were previously on a network without a captive portal, but
> one is suddenly interjected.
>
> I see several problems, different for each of the various solutions:
>
> * With 7710 or PvD, the original network would have to be provisioned
> with a captive portal, or the switch would happen and the endpoint
> won't have a URI to talk to.  That seems relatively tractable,
> providing that this didn't lead to a false assumption of captivity
> (this is a problem with 7710, I think, because the existence of the
> option seems to imply captivity, though this is quite unclear from the
> RFC).
>
> * With ICMP, the signal comes from more than one hop away.  An
> unmodified router in the home would receive the ICMP message, reduce
> the TTL and then it looks like a random Internet host was trying to
> deny service.
>
> So running through all the combinations:
>
> 7710/PvD + ICMP - you know where to go to get status information and
> the network can signal
>
> 7710/PvD - ICMP - you know where to go to get status information, but
> how would you decide to ask?  Is there some other trigger you would
> use?  (This is, I think Vincent's question.)
>
> ICMP - 7710/PvD - you get a signal, but is it legit?  How do you validate
> it?
>
> Neither - that's the situation we have today.
>
> It seems that there are at least a few people who think that this use
> case is in scope.  It doesn't seem materially different from the case
> where you run out of bytes (for networks that do accounting that way).
> Maybe this use case can inform the design a little better.  Or maybe
> someone would like to argue that we don't need to worry about this.
>
>
>
> On 25 August 2017 at 06:58, Vincent van Dam  wrote:
> > I agree that the information you describe should be pulled from
> somewhere,
> > however, I am more concerned _when_ they should be pulled.
> >
> >
> > In this working group we acknowledged (welcomed) use cases that go beyond
> > connecting to a network; the latest example:
> > https://www.ietf.org/mail-archive/web/captive-portals/
> current/msg00455.html
> >
> >
> > If these use cases are indeed in scope; signalling, or a solution that
> > allows detection that the walled garden is (re)activated after joining
> the
> > network, need to be in place. The alternative to a signal would be
> polling,
> > or doing some mitm on protocols that allow it. I think both mitm, and
> > polling regularly to see if the connection state is walled are bad.
> >
> >
> > Just focussing on signalling (without the semantics/api); I think that
> > leaves us with three directions:
> >
> >
> > * descope any solution that would improve the scenario where walled
> gardens
> > are (re-)activated
> >
> > * accept icmp is a valid direction, and think of a way on how we can use
> > this securely in our use-case
> >
> > * invent a new signal? something the nas is allowed to send to the ue,
> but
> > not icmp?
> >
> >
> > Gr., Vincent
> >
> >
> > 
> > Van: Captive-portals [captive-portals-boun...@ietf.org] namens Tommy
> Pauly
> > [tpa...@apple.com]
> > Verzonden: donderdag 24 augustus 2017 18:03
> > Aan: Lorenzo Colitti
> > CC: Erik Kline; Eric Vyncke (evyncke); Martin Thomson;
> > captive-portals@ietf.org; David Bird
> > Onderwerp: Re: [Captive-portals] Questions about PvD/API
> >
> > If the client OS needs to add in heuristics to reach a certain volume of
> > ICMP messages before

Re: [Captive-portals] Questions about PvD/API

[Martin Thomson]

What is interesting about Heiko's example here is that this transition
is not necessarily visible to endpoints. Nor can they be forewarned
(assuming they are ignorant of the botnet using their link).
Endpoints were previously on a network without a captive portal, but
one is suddenly interjected.

I see several problems, different for each of the various solutions:

* With 7710 or PvD, the original network would have to be provisioned
with a captive portal, or the switch would happen and the endpoint
won't have a URI to talk to.  That seems relatively tractable,
providing that this didn't lead to a false assumption of captivity
(this is a problem with 7710, I think, because the existence of the
option seems to imply captivity, though this is quite unclear from the
RFC).

* With ICMP, the signal comes from more than one hop away.  An
unmodified router in the home would receive the ICMP message, reduce
the TTL and then it looks like a random Internet host was trying to
deny service.

So running through all the combinations:

7710/PvD + ICMP - you know where to go to get status information and
the network can signal

7710/PvD - ICMP - you know where to go to get status information, but
how would you decide to ask?  Is there some other trigger you would
use?  (This is, I think Vincent's question.)

ICMP - 7710/PvD - you get a signal, but is it legit?  How do you validate it?

Neither - that's the situation we have today.

It seems that there are at least a few people who think that this use
case is in scope.  It doesn't seem materially different from the case
where you run out of bytes (for networks that do accounting that way).
Maybe this use case can inform the design a little better.  Or maybe
someone would like to argue that we don't need to worry about this.



On 25 August 2017 at 06:58, Vincent van Dam  wrote:
> I agree that the information you describe should be pulled from somewhere,
> however, I am more concerned _when_ they should be pulled.
>
>
> In this working group we acknowledged (welcomed) use cases that go beyond
> connecting to a network; the latest example:
> https://www.ietf.org/mail-archive/web/captive-portals/current/msg00455.html
>
>
> If these use cases are indeed in scope; signalling, or a solution that
> allows detection that the walled garden is (re)activated after joining the
> network, need to be in place. The alternative to a signal would be polling,
> or doing some mitm on protocols that allow it. I think both mitm, and
> polling regularly to see if the connection state is walled are bad.
>
>
> Just focussing on signalling (without the semantics/api); I think that
> leaves us with three directions:
>
>
> * descope any solution that would improve the scenario where walled gardens
> are (re-)activated
>
> * accept icmp is a valid direction, and think of a way on how we can use
> this securely in our use-case
>
> * invent a new signal? something the nas is allowed to send to the ue, but
> not icmp?
>
>
> Gr., Vincent
>
>
> 
> Van: Captive-portals [captive-portals-boun...@ietf.org] namens Tommy Pauly
> [tpa...@apple.com]
> Verzonden: donderdag 24 augustus 2017 18:03
> Aan: Lorenzo Colitti
> CC: Erik Kline; Eric Vyncke (evyncke); Martin Thomson;
> captive-portals@ietf.org; David Bird
> Onderwerp: Re: [Captive-portals] Questions about PvD/API
>
> If the client OS needs to add in heuristics to reach a certain volume of
> ICMP messages before trusting them, I think the design is flawed. Beyond
> that, the information we'd like to get isn't just as simple as a boolean
> value that can be aggregated (like unreachable would be). Among the problems
> we're trying to solve for CAPPORT is "how much time do I have left", and
> "when to re-join the portal". Having a source we can query about those
> properties seems to dramatically simplify the flow and trust model. However
> we do things, it seems like this information should be pull-able (even if it
> allows the client to open a connection on which changes are pushed or
> notified) rather than unsolicited pushes of ICMP by the network.
>
> On Aug 24, 2017, at 8:33 AM, Lorenzo Colitti  wrote:
>
> It seems to me that any solution involving coordination between two
> protocols is little different, in terms of your criticism that it will lead
> to "a higher rate of misconfiguration", from the PVD solution. (Personally I
> don't think that's a valid argument - saying that if you misconfigure the
> network it won't work well is pretty much a tautology - but you were the one
> that cited that argument in support of the ICMP solution.)
>
> As for several flows, I don't see what would stop an attacker from trying to
> spoof several flows.
>
> On Fri, Aug 25, 2017 at 12:21 AM, David Bird  wrote:
>>
>> You are both describing decisions the UE makes... perhaps the UE waits for
>> several flows (with same session-id) to indicate capport warning/errors
>> before acting on it... especially when already connected. There were a

Re: [Captive-portals] Questions about PvD/API

[Vincent van Dam]

I agree that the information you describe should be pulled from somewhere, 
however, I am more concerned _when_ they should be pulled.


In this working group we acknowledged (welcomed) use cases that go beyond 
connecting to a network; the latest example: 
https://www.ietf.org/mail-archive/web/captive-portals/current/msg00455.html


If these use cases are indeed in scope; signalling, or a solution that allows 
detection that the walled garden is (re)activated after joining the network, 
need to be in place. The alternative to a signal would be polling, or doing 
some mitm on protocols that allow it. I think both mitm, and polling regularly 
to see if the connection state is walled are bad.


Just focussing on signalling (without the semantics/api); I think that leaves 
us with three directions:


* descope any solution that would improve the scenario where walled gardens are 
(re-)activated

* accept icmp is a valid direction, and think of a way on how we can use this 
securely in our use-case

* invent a new signal? something the nas is allowed to send to the ue, but not 
icmp?


Gr., Vincent


Van: Captive-portals [captive-portals-boun...@ietf.org] namens Tommy Pauly 
[tpa...@apple.com]
Verzonden: donderdag 24 augustus 2017 18:03
Aan: Lorenzo Colitti
CC: Erik Kline; Eric Vyncke (evyncke); Martin Thomson; 
captive-portals@ietf.org; David Bird
Onderwerp: Re: [Captive-portals] Questions about PvD/API

If the client OS needs to add in heuristics to reach a certain volume of ICMP 
messages before trusting them, I think the design is flawed. Beyond that, the 
information we'd like to get isn't just as simple as a boolean value that can 
be aggregated (like unreachable would be). Among the problems we're trying to 
solve for CAPPORT is "how much time do I have left", and "when to re-join the 
portal". Having a source we can query about those properties seems to 
dramatically simplify the flow and trust model. However we do things, it seems 
like this information should be pull-able (even if it allows the client to open 
a connection on which changes are pushed or notified) rather than unsolicited 
pushes of ICMP by the network.

On Aug 24, 2017, at 8:33 AM, Lorenzo Colitti 
mailto:lore...@google.com>> wrote:

It seems to me that any solution involving coordination between two protocols 
is little different, in terms of your criticism that it will lead to "a higher 
rate of misconfiguration", from the PVD solution. (Personally I don't think 
that's a valid argument - saying that if you misconfigure the network it won't 
work well is pretty much a tautology - but you were the one that cited that 
argument in support of the ICMP solution.)

As for several flows, I don't see what would stop an attacker from trying to 
spoof several flows.

On Fri, Aug 25, 2017 at 12:21 AM, David Bird 
mailto:db...@google.com>> wrote:
You are both describing decisions the UE makes... perhaps the UE waits for 
several flows (with same session-id) to indicate capport warning/errors before 
acting on it... especially when already connected. There were also proposals to 
link the ICMP messages to the DHCP message somehow so that ICMP is 
'authenticated' against the original DHCP. Theses are solvable concerns, not 
road blocks.



On Thu, Aug 24, 2017 at 8:14 AM, Tommy Pauly 
mailto:tpa...@apple.com>> wrote:
Right, I think the difference between an unreachable destination, and a captive 
portal or walled garden, is that we expect the captive portal style interaction 
to be an Operating System-level action, and one that will have consequences on 
everything the device does while associated to a given network. You can certain 
use spoofed ICMP to disrupt connections, but (a) the user would notice and (b) 
you're not causing the Operating System to change behavior. When the OS thinks 
it is on a captive network or not, it will change what network it considers 
primary/usable, which may potentially be invisible to the user other than an 
icon change. I would be able to go onto a captive network, start sending out 
ICMP messages, and potentially bump other people's connection off the network.

Having the UE fetch some resource in order to determine captive state, 
especially if that resource can be somehow signed, makes it much harder for an 
attacker to cause the OS to take silent behavior.

Tommy

On Aug 24, 2017, at 7:40 AM, Lorenzo Colitti 
mailto:lore...@google.com>> wrote:

A forged destination unreachable can't cause someone else's device to think 
that wifi is a portal and switch to possibly expensive cellular data.

On Thu, Aug 24, 2017 at 11:29 PM, David Bird 
mailto:db...@google.com>> wrote:
Just like the rampant problem we see in ICMP Dest-Unreachable forgery attacks?

On Thu, Aug 24, 2017 at 7:01 AM, Lorenzo Colitti 
mailto:lore...@google.com>> wrote:
On Thu, Aug 24, 2017 at 10:40 PM, David Bird 
mailto:db...@google.com>> wrote:
Can you give an example of how ICMP could be misconfigured?

It doesn

Re: [Captive-portals] Questions about PvD/API

[Tommy Pauly]

If the client OS needs to add in heuristics to reach a certain volume of ICMP 
messages before trusting them, I think the design is flawed. Beyond that, the 
information we'd like to get isn't just as simple as a boolean value that can 
be aggregated (like unreachable would be). Among the problems we're trying to 
solve for CAPPORT is "how much time do I have left", and "when to re-join the 
portal". Having a source we can query about those properties seems to 
dramatically simplify the flow and trust model. However we do things, it seems 
like this information should be pull-able (even if it allows the client to open 
a connection on which changes are pushed or notified) rather than unsolicited 
pushes of ICMP by the network.

> On Aug 24, 2017, at 8:33 AM, Lorenzo Colitti  wrote:
> 
> It seems to me that any solution involving coordination between two protocols 
> is little different, in terms of your criticism that it will lead to "a 
> higher rate of misconfiguration", from the PVD solution. (Personally I don't 
> think that's a valid argument - saying that if you misconfigure the network 
> it won't work well is pretty much a tautology - but you were the one that 
> cited that argument in support of the ICMP solution.)
> 
> As for several flows, I don't see what would stop an attacker from trying to 
> spoof several flows.
> 
> On Fri, Aug 25, 2017 at 12:21 AM, David Bird  > wrote:
> You are both describing decisions the UE makes... perhaps the UE waits for 
> several flows (with same session-id) to indicate capport warning/errors 
> before acting on it... especially when already connected. There were also 
> proposals to link the ICMP messages to the DHCP message somehow so that ICMP 
> is 'authenticated' against the original DHCP. Theses are solvable concerns, 
> not road blocks. 
> 
> 
> 
> On Thu, Aug 24, 2017 at 8:14 AM, Tommy Pauly  > wrote:
> Right, I think the difference between an unreachable destination, and a 
> captive portal or walled garden, is that we expect the captive portal style 
> interaction to be an Operating System-level action, and one that will have 
> consequences on everything the device does while associated to a given 
> network. You can certain use spoofed ICMP to disrupt connections, but (a) the 
> user would notice and (b) you're not causing the Operating System to change 
> behavior. When the OS thinks it is on a captive network or not, it will 
> change what network it considers primary/usable, which may potentially be 
> invisible to the user other than an icon change. I would be able to go onto a 
> captive network, start sending out ICMP messages, and potentially bump other 
> people's connection off the network. 
> 
> Having the UE fetch some resource in order to determine captive state, 
> especially if that resource can be somehow signed, makes it much harder for 
> an attacker to cause the OS to take silent behavior.
> 
> Tommy
> 
>> On Aug 24, 2017, at 7:40 AM, Lorenzo Colitti > > wrote:
>> 
>> A forged destination unreachable can't cause someone else's device to think 
>> that wifi is a portal and switch to possibly expensive cellular data.
>> 
>> On Thu, Aug 24, 2017 at 11:29 PM, David Bird > > wrote:
>> Just like the rampant problem we see in ICMP Dest-Unreachable forgery 
>> attacks? 
>> 
>> On Thu, Aug 24, 2017 at 7:01 AM, Lorenzo Colitti > > wrote:
>> On Thu, Aug 24, 2017 at 10:40 PM, David Bird > > wrote:
>> Can you give an example of how ICMP could be misconfigured? 
>> 
>> It doesn't matter how hard it is to misconfigure, because it is trivial to 
>> forge.
>> 
>> 
>> ___
>> Captive-portals mailing list
>> Captive-portals@ietf.org 
>> https://www.ietf.org/mailman/listinfo/captive-portals 
>> 
> 
> 
> 

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Questions about PvD/API

[David Bird]

Indeed, one could just as easily misconfigure the "Captive Portal URL: "
field in the NAS. A key difference is that this configuration is enforced
the same way (with slight variation for capport) for all devices... It is
not just a misconfiguration only visible to "First Vendor to Release PvD
Client" products.

I'm trying to figure out the value the attacker is gaining (e.g. the
motivation) for putting others off the network using Capport ICMP. If they
are off-network, chances are their attacks will not work because of
firewalls. If they are on-network, particularly if this is Open SSID public
access network, I'd say they are wasting their time... Sending 802.11
Disassoc would be easier.

On Thu, Aug 24, 2017 at 8:33 AM, Lorenzo Colitti  wrote:

> It seems to me that any solution involving coordination between two
> protocols is little different, in terms of your criticism that it will lead
> to "a higher rate of misconfiguration", from the PVD solution. (Personally
> I don't think that's a valid argument - saying that if you misconfigure the
> network it won't work well is pretty much a tautology - but you were the
> one that cited that argument in support of the ICMP solution.)
>
> As for several flows, I don't see what would stop an attacker from trying
> to spoof several flows.
>
> On Fri, Aug 25, 2017 at 12:21 AM, David Bird  wrote:
>
>> You are both describing decisions the UE makes... perhaps the UE waits
>> for several flows (with same session-id) to indicate capport warning/errors
>> before acting on it... especially when already connected. There were also
>> proposals to link the ICMP messages to the DHCP message somehow so that
>> ICMP is 'authenticated' against the original DHCP. Theses are solvable
>> concerns, not road blocks.
>>
>>
>>
>> On Thu, Aug 24, 2017 at 8:14 AM, Tommy Pauly  wrote:
>>
>>> Right, I think the difference between an unreachable destination, and a
>>> captive portal or walled garden, is that we expect the captive portal style
>>> interaction to be an Operating System-level action, and one that will have
>>> consequences on everything the device does while associated to a given
>>> network. You can certain use spoofed ICMP to disrupt connections, but (a)
>>> the user would notice and (b) you're not causing the Operating System to
>>> change behavior. When the OS thinks it is on a captive network or not, it
>>> will change what network it considers primary/usable, which may potentially
>>> be invisible to the user other than an icon change. I would be able to go
>>> onto a captive network, start sending out ICMP messages, and potentially
>>> bump other people's connection off the network.
>>>
>>> Having the UE fetch some resource in order to determine captive state,
>>> especially if that resource can be somehow signed, makes it much harder for
>>> an attacker to cause the OS to take silent behavior.
>>>
>>> Tommy
>>>
>>> On Aug 24, 2017, at 7:40 AM, Lorenzo Colitti  wrote:
>>>
>>> A forged destination unreachable can't cause someone else's device to
>>> think that wifi is a portal and switch to possibly expensive cellular data.
>>>
>>> On Thu, Aug 24, 2017 at 11:29 PM, David Bird  wrote:
>>>
 Just like the rampant problem we see in ICMP Dest-Unreachable forgery
 attacks?

 On Thu, Aug 24, 2017 at 7:01 AM, Lorenzo Colitti 
 wrote:

> On Thu, Aug 24, 2017 at 10:40 PM, David Bird  wrote:
>
>> Can you give an example of how ICMP could be misconfigured?
>>
>
> It doesn't matter how hard it is to misconfigure, because it is
> trivial to forge.
>


>>> ___
>>> Captive-portals mailing list
>>> Captive-portals@ietf.org
>>> https://www.ietf.org/mailman/listinfo/captive-portals
>>>
>>>
>>>
>>
>
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Questions about PvD/API

[Tommy Pauly]

Right, I think the difference between an unreachable destination, and a captive 
portal or walled garden, is that we expect the captive portal style interaction 
to be an Operating System-level action, and one that will have consequences on 
everything the device does while associated to a given network. You can certain 
use spoofed ICMP to disrupt connections, but (a) the user would notice and (b) 
you're not causing the Operating System to change behavior. When the OS thinks 
it is on a captive network or not, it will change what network it considers 
primary/usable, which may potentially be invisible to the user other than an 
icon change. I would be able to go onto a captive network, start sending out 
ICMP messages, and potentially bump other people's connection off the network. 

Having the UE fetch some resource in order to determine captive state, 
especially if that resource can be somehow signed, makes it much harder for an 
attacker to cause the OS to take silent behavior.

Tommy

> On Aug 24, 2017, at 7:40 AM, Lorenzo Colitti  wrote:
> 
> A forged destination unreachable can't cause someone else's device to think 
> that wifi is a portal and switch to possibly expensive cellular data.
> 
> On Thu, Aug 24, 2017 at 11:29 PM, David Bird  > wrote:
> Just like the rampant problem we see in ICMP Dest-Unreachable forgery 
> attacks? 
> 
> On Thu, Aug 24, 2017 at 7:01 AM, Lorenzo Colitti  > wrote:
> On Thu, Aug 24, 2017 at 10:40 PM, David Bird  > wrote:
> Can you give an example of how ICMP could be misconfigured? 
> 
> It doesn't matter how hard it is to misconfigure, because it is trivial to 
> forge.
> 
> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals