Re: [Captive-portals] A new draft / idea - draft-wkumari-capport-icmp-unreach
David Bird <db...@google.com> wrote: > The risk of requiring certs for the CP-NAS interface is that WISPs will > probably just use self-signed certs and make the user suffer the > browser warnings... (Or, worse, they will not use the spec and everyone > has a Legacy experience). I think that the bypass for self-signed certs will be further buried in browsers, and so WISPs that do that will simply have either no customers, or massive calls to the support desk. I'm happy with either result, but I still would like a new SubjectAltName for appliances, yes, including home routers. (The Home CPE that has no uplink configured is a defacto captive portal) -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Follow up on hackathon results
Kyle Larose <klar...@sandvine.com> wrote: > • Tcpdump: https://github.com/ThreadedThinking/tcpdump > If anyone has worked on this since then/has newer locations or stuff, > please let the mailing list know! Hi, I sure hope you have pcap files with the captured new ICMPs, for the tcpdump tests/ subdirectory. Please touch ".devel" and run "make check" And please send pull request; your code looks well formed to me. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Not good....
Martin Thomson <martin.thom...@gmail.com> wrote: > On 2 April 2017 at 17:27, Michael Richardson <mcr+i...@sandelman.ca> wrote: >> One of the things we are going to need to do is to find a way use the >> stick as well as the carrot when it comes to poorly behaved sites. > The big stick I see here is the increased use of HTTPS. Do we really > need anything more? Well, we can wish, but I don't know that it will feedback to the right place. (On my laptop, I open a disposable firefox profile (without HTTPS everywhere), and I have to find some site that has an http redirect. I can usually depend upon my city's web site to be clueless. That's a lot of effort and I'm technically clueful. The Freehand Chicago had all these problems, plus their DNS was intolerant of requests.) So I don't see HTTPS as fixing or shaming any portals; rather I just see users getting frustrated and going someplace else without knowing why. They don't call support; and if they do, support will ask them to "turn it off and on", and to please try IE6. What they might do is write a review, and this is where I think we need to do something. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
[Captive-portals] captive portal detectors
Michael Richardson <mcr+i...@sandelman.ca> wrote: > Yes, I agree. That's the carrot part. "Do X and life will be better" > But, I was talking about the stick part: "Until you do X, you'll get a > bad review" > I realize that this isn't a protocol we can write. It is something > that the occured when we did the ECN experiment. > I am suggesting that when a platform fails to find X, I think it SHOULD > let the user know about it. I was thinking more about IETF actions relating to poorly behaved legacy portals. I would like to propose that this WG write a document detailing how legacy portals attempt to deceive hosts, standardizing the descriptions. For each case where the host concludes that they have detected some specific kind of deception, the document would provide a standardized description of what kind of event was detected. We would provide simplified (but common) english descriptions of the kind of deception (i.e. "DNS request for wellknown.example.com returned lie", or "DNSSEC bits were turned off", or ICMP to 8.8.8.8 is not answered, or port-443 to wellknown.example.com returns invalid certificate, etc...) along with an error code such that the descriptions could be translated. As an extension the user agents could collect the information for upload to reputation systems of the end user's choice. (or not, as the user wishes) (I suspect that MILE has all the common infrastructure we want for the format) So in effect, I'm asking for a standardized interface from a user space application (an "app") to the captive portal detection system inside the OS. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Arguments against (any) Capport "API"
Dave Dolson <ddol...@sandvine.com> wrote: > I’d like to hear from browser vendors as to why the browser gets > sandboxed when interacting with a captive portal. Security in layers. The browser contains lots of interesting cookies and other state. A captive portal could, for instance, provide a stack of img URLs to places where the user might have cookies, and the browser may reach out to try to load things. Even if those URLs are HTTPS and the captive portal lets them through, just observing the size of the packets would tell the portal operator whether or not the user has a relationship to that entity. Of course, if they put http URLs in then snooping is obvious. (The operator can, of course, do this anyway, but the user does have a point where they can, for instance, bring up a VPN to protect all their traffic. My Android phone now apparently does this for me automatically when I'm on high-quality public WiFI. More cool is that it appears to use IPv6 on the inside. More funny was that google then alerted me to suspicious activity from an IPv6 I'd never before logged into... which was the inner tunnel IP...) > If one could trust the URL came from the local network (via DHCP), > could restrictions be lifted? I don't think this matters at all. > If the URL were HTTPS, and certificates were valid (e.g., valid cert of > Chicago OHare Airport), could restrictions be lifted? I don't think so. I'm also unclear how the end-user can be sure that the certificate in question is really from the location they are in. In many cases, it's not "chicago-ord.com", but rather, "ord.boingo.com"... -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Arguments against (any) Capport "API"
David Bird <db...@google.com> wrote: > A note about capport detection evasion: It is not always on purpose... > As more hotspots do "social login" applications, they are opening up > the walled garden surprisingly wide to get that to work... I think that within the Android ecosystem (which I know a lot about), that it should be possible to form an intent from the captive browser to the system to invoke the appropriate app and return an OAUTH2 token. This doesn't have to happen within JS from within the captive browser. I imagine that iOS ecosystem can handle something similar, but I believe that it hasn't (yet?) got Intents that are as flexible. On a desktop system there are fewer options, but given dbus, and OSX/microsoft equivalents, I don't see why it couldn't happen. The "gcalapi" python script nicely asks my browser for an oauth token today. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Arguments against (any) Capport "API"
David Bird <db...@google.com> wrote: > -- We tend to ignore what the venue/Hotspot operator wants.. They WANT > you at the captive portal... Hence, why they went out of their way to > have a CAPTIVE portal. We could define an alternative method for the > portal, but why? Do Hotspot operators WANT more interfaces, with > unknown user experiences, that limit their options? There is a reason > why in WISPr the browser method was called the "Universal Access > Method"... because, well, it's universal. (Moreover, Hotspot operators > are largely marketing companies -- they are very used to designing Web > user experiences, that is their business). That's only one view. Some operators need a record of who used their network for legal reasons. It's not all about advertising either; at Midway Airport, it was about having me pay after my free sample wore off. At my hotel, it was about keeping the network from being overrun by riff-raff. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
[Captive-portals] time-based walled gardens
David Bird <db...@google.com> wrote: > Should the aim be to provide a > general hint of network restriction, or on a per-destination > basis? Consider access to higher bandwidth content (video). A number of places might want to restrict access to such content during certain periods, or from certain places. A school might restrict it during school hours (simply for fairness: people got other things to do), yet a teacher ought to be able to stream an instructional video. Colleges might restrict its use when in a lecture hall. Airlines might want to restrict streaming video to those who paid more. (So there might even be multiple levels of walled garden!) My mobile ISP does not charge me "overages" but, rather limits my bit-rate after I hit my datacap. I can buy more; and they SMS me about it, but a data-only plan wouldn't have an SMS attached to it. All of these things would seem to be doable with the ICMP plus RESTful API.It seems that the session-ID can deal with these changes, and the validity could indicate things like valid until the end-of-school day. ICMP says: Any change in this value between ICMP messages from the same source IP address MUST be considered by the client to mean a change in access policy has occurred and previous notifications are no longer valid. I don't know what it means if an ICMP comes from a different source IP. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Arguments against (any) Capport "API"
David Bird <db...@google.com> wrote: > portal (or when the venue evaded your detection). Maybe the captive > portal networks wants to offer these services in their walled > garden... and it is likely the user would be happy about that > (provided they selected the network on purpose). Consider a school that uses Google Apps (like my sons'). They run a somewhat loose firewall that blacklists stuff; but probably would be better off to whitelist things. The ICMP reply could very well be used to trigger the teacher override. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] thoughts on two documents
Lorenzo Colitti <lore...@google.com> wrote: > 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. > On Mon, Apr 24, 2017 at 1:09 AM, Dave Dolson <ddol...@sandvine.com> > wrote: > Regarding the sacrificial queries, 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: captive-portals@ietf.org 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. > [ 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 > ___ 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 -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Improve the user experience of captive portals as they're commonly understood and currently deployed
James Wood <james.w...@purplewifi.com> wrote: > 4. Walled garden. It's a nightmare having to manage lists of domains/IP's > across all the different vendors kit out there. For example to offer a > social login through Facebook we need to allow certain domains like > facebook.com, akamaihd.net and connect.facebook.net etc. This is all > static It seems that maybe facebook could be more involved here. I think it's clearly in their interest to make this easier. > lists inside an AP/controller, and would be a nightmare to update should > Facebook change the URLs they send authentication requests throught etc. How > about some way to dynamicly pass back a list of domains as part of the DHCP > option or some other way to allow the operator to set the required domains > at time of connection? Or, how about, as part of the capport API, we are > able to send a list of domains back to the AP, so if someone chooses > Facebook, we open the Facebook domains for that MAC for a few minutes to > allow them to login. As Erik and Lorenzo had said, on Android at least, one reason for the captive browser is because it's the only way to connect to the new network before the 3G is disconnected. Passing a list of domains to the browser seems like a fail to me. > I had a look at "draft-wkumari-capport-icmp-unreach-02". I note that it > describes the example URL that could be returned as part of the captive > portal URL: https://wifi.domain.com/portal?icmp_session=10_class=100. > However, what about the other traditional parameters that a captive portal > redirect injects? As a minimum, we need the ap_mac, client_mac and login_url > to which we post the login request back to (traditional captive portal login > request). Without such parameters, we cannot identify the venue/ap/client > and provide the relevant portal splash page and user specific options. I may > have misunderstood this? I think you are missing the point of the URL. It's not after login, but it's how to find the login page. Once you have it, you can do anything. Also, I think you can include any additional parameters you want. It's descriptive, not prescriptive. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"
Mark Nottingham <m...@mnot.net> wrote: > That's useful as long as the client is a human is behind a browser. It > can also break lots of stuff... Exactly why the ICMP is useful :-) -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"
Erik Kline <e...@google.com> wrote: > 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? 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 <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] [adoption call] draft-donnelly-capport-detection
Erik Kline <e...@google.com> wrote: > As indicated in the minutes from Prague > [https://datatracker.ietf.org/doc/minutes-99-capport/], there was a > general hum in favor of the API document: > """ > 4. API document: do we need a milestone? Humming: in favor. > 5. Is this document a good basis. Humming in favor. > """" > This email is to initiate a two week call for adoption for: > https://datatracker.ietf.org/doc/draft-donnelly-capport-detection/ I like the approach, please adopt it. After adoption, I think the WG should consider if describing the JSON in YANG would make sense. I've been through this in netconf/anima/6tisch now, and while it seems like a silly annoyance at first, it seems to have some advantages in the long run. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Questions about PvD/API
Erik Kline <e...@google.com> wrote: >> 5.1.1. Associating User Equipment with its URL >> >> The CAPPORT API Server SHOULD associate an incoming request with a >> particular User Equipment consistently. [TODO: specify how this >> would happen.] >> >> This becomes a pretty important point because it can't be that each DHCP or >> RA is custom formatted for each station with a UE specific URL. It also >> needs to be a MUST if the API is returning information about >> 'bytes_remaining' and such. Or, does the UE self report it's MAC to the >> API/PvD? The service needs some way of associating that API/PvD session with >> the RADIUS accounting stream. > > This is a very critical question, imho. > No captive portal vendor would want to trust clients to self-identify > their MAC addresses. And even non-malicious clients might be prone to > introducing errors (say, by presenting the random MAC used during > scanning and not [as a result of a bug] the actual MAC used for the > session). Not only do we have a problem with the clients presenting the wrong MAC by accident, they could also present the wrong MAC on purpose to gain information about adjacent clients. A simple multiple PING harvests that list. > Given that, it seems the network infrastructure itself must be the > element that adds MAC addresses, or some equivalent token, in > communications with the API endpoint. Yes? It must provide a token based upon the MAC, but I think it must protect it as well. In only the simplest cases will the portal/API receiver be on the same link as the client, so even though we can get the MAC address via DHCP relay, the portal can't verify the address is the correct one accessing it anyway. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] YANG schemas (was Re: [adoption call] draft-donnelly-capport-detection)
Martin Thomson <martin.thom...@gmail.com> wrote:
> Do you know if the outer object can be stripped off? Context is
> usually sufficient to avoid that extra layer (and HTTP provides
> content-type to provide that context).
I don't know; it does have the advantage of making the JSON self-identifying,
and also providing built-in versioning. So while annoying to strip off a
layer, it isn't hard. It's just esthetically displeasing.
> module capport {
> yang-version 1.1;
> namespace "urn:...:ietf:...:capport";
> prefix "capport";
> import ietf-yang-types {
> prefix yang;
> }
> // ... metadata stuff
> container top {
> leaf captive {
> type boolean;
> }
> leaf end {
> type yang:date-and-time;
> }
> }
> }
See, and we are done :-)
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] IETF 100: ICMP Discussion Summary
Dave Dolson <ddol...@sandvine.com> wrote: > Regarding multiple IPv6 addresses, consider these two alternatives: > 1. Associate the new address with an existing capport "session", for > uninterrupted experience. ... > I propose that the capport API permits new IP addresses to be assigned > to an existing session, by providing an appropriate token. Given an approriate HTTP Cookie which is not tied to a particular v6 end point, then one could call some API, having already authenticated. So I can see that this could perhaps work. The downside is that if I pass this cookie around to my friends, then my friends can get service via me. Unless the enforcement point enforces L2 addresses, which if it did, then we would have no problem. I'm not sure if we can require that the new IP address be added from an address that is already authenticated. Not only does it mean that my host has to figure out how to use what might be an expired temporary address, but it also means that I could add my friends' IPs to my ACL rather easily. How many can I add? All 2^64 of them? :-) -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] IETF 100: ICMP Discussion Summary
{did not make it in person, and had a conflict and I haven't watched the
session on youtube yet}
Kyle Larose <klar...@sandvine.com> wrote:
> - Question was raised about whether we should restrict the number of v6
> addresses (one address, one prefix, etc).
Was there any consensus?
I don't see a way to restrict the number of v6 addresses per UE except via
stateful
DHCPv6, and few use that.
> - I recall something about restricting the UE, API server and ED to be
> on the same link (or provisioning domain?) from the UE's perspective to
> simplify the passive identification. Didn't see it in the notes,
> though, so I may be imagining it.
The term provisioning domain is probably more precise.
> - There seemed to be general support for a simple form of the ICMP
> option (i.e. keep it a simple notification of a problem, rather than
> communicating further state within it). We need to work on what exactly
> this entails, and what we lose by taking out the more advanced
> capabilities (i.e. maybe first round has the simple methods, but we can
> add more extensions as the base technology is adopted).
+1
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] client identifying info between API and enforcement
Erik Kline <e...@google.com> wrote: > I was expecting this is what might be required, given the > architectures that are currently in use: I think that I got you, but I need a picture. > [3] login service updates enforcement point about token_1's state > (assuming login success) I think that login service updating enforcement point can simply say: "allow the L2 address associated with token_1" If the tokens are big enough (16 bytes or more), they could be the L2 address encrypted (privately) by the enforcement point, making the enforcement point stateless. I think that the access decisions need to be made by the enforcement device at the L2 level for a bunch of different reasons including auditing. At this point I think the industry has established that L2-mac-address randomization is good, but that having it totally random is bad. It should be the same whenever the ESSID/AP is the same, with some caveats, and this gets us the nice property that access control doesn't have to be done every time one visits the same place. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Signals from the network and ICMP
Warren Kumari <war...@kumari.net> wrote: >> 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. > I'll start off by admitting that this is a cheap shot, but: > https://access.redhat.com/security/vulnerabilities/3442151 (yeah, so that's as much about using shell for things it was never designed to do.) > 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... 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. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Signals from the network and ICMP
Erik Kline <e...@google.com> wrote: > One problem with UDP is that if the enforcement point is well upstream of > 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? > 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. I feel I need a digram to explain this. (Is this even in scope?) > 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. So, we should use an old type (unreachable), but a new code? I sure prefer ICMP from an architectural point of view. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Signals from the network and ICMP
Erik Kline <e...@google.com> wrote: > 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. 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? > [3] NetworkMonitor already rate limits requests from applications > to revalidate the network, and these would likely be no different (or > pretty much the same). Or would NetworkMonitor do this anyway, and it has all the priviledges it needs anyway? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails[ -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Signals from the network and ICMP
Martin Thomson <martin.thom...@gmail.com> wrote: > On Wed, May 2, 2018 at 10:06 PM Michael Richardson <mcr+i...@sandelman.ca> > wrote: >> Have we considered TCP RST already? (I don't think it's better than ICMP, >> but >> I don't remember it being discussed yet) > 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. > 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. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] API access and .well-known
Tommy Pauly <tpa...@apple.com> wrote: > The benefit of this approach (get [API-URL] first, and follow it to > [HTML-URL]) is that we pave the way towards more flexibility when we > don’t necessarily need the [HTML-URL] to do traditional captive > portals, but instead can do interaction models designed for watch-like > devices, or multiple devices that don’t ever need a follow-on URL. +1 >>> c. find some way to get two URIs, like revising 7710 or finding an >>> alternative mechanism (such as the one in RFC 5986) > I think that this approach is effectively saying that [API-URL] and > [HTML-URL] are both signaled explicitly in the discovery > mechanism. While this avoids the problem of ambiguity, it bakes in the > notion of a legacy captive portal URL, and takes up more space in the > discovery mechanism. > I’d vote for some variation on (a), but we can just explain the meaning > of the URL we discover more clearly, instead of using a well known > URL. I think that we need the 7710 mechanism to get the HOST part, and that the URL part SHOULD be .well-known/blah, but MAY be something else. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] API access and .well-known
Adam Roach <a...@nostrum.com> wrote: > I agree that we should strictly avoid synthesizing URLs in general, > and should try to avoid .well-known URLs in particular. Sometimes > you're forced to use .well-known (e.g., when there's literally no way > to get a full URL to the client), but that doesn't seem to be the case > here. Is it reasonable for different enforcements points to return different URLs to different clients? If so, that solves much of the multi-tenancy problems, and I guess I recant some of my previous message. I'd still like to register a /.well-known value as a suggestion. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] I-D Action: draft-ietf-capport-api-00.txt
Lorenzo Colitti <lore...@google.com> wrote:
> Over the years on this list we have seen many use-cases come
> through, I recall:
> - A school/library network that allows most of the Internet,
> but captures and redirects for certain networks / sites
> - A network allows all sorts of protocols - IMAP, HTTPS, for
> example - but not others - like HTTP, SMTP - and want to
> redirect / signal portal
> - A network that allows all Internet traffic, but just at a
> low QoS tier. No "captive" portal, but a portal is yet
> available for upgrading tier
> - Any network that allows a large walled garden, or even a
> *very large* garden, but otherwise has a captive portal
> - A network that will 99.99% of the time allow all traffic,
> but will (perhaps because of virus detection) interrupts
> sessions into captive state [technically, this is a "boolean"
> use-case, but one where polling would just be huge noise]
lc> I don't see why you would want to signal any of these to the UE,
lc> because they're not really actionable. Even if the UE distinguishes
Not actionable by an UE.
Might other things care?
Is it useful for diagnostics?
(Why doesn't webrtc work here?)
lc> between these categories, application developers are likely not going
lc> to want to do so and in the main are going to do whatever the UE
lc> decides to do. As Martin says, the human using the UE might be
lc> interested (e.g., in the upgrading case), but that's not hard to do by
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Comment on Captive Portal Architecture
Nasir Hafeez wrote: > Another option that occurred to me was using LLDP for capport > signaling. Do you think there is any utility in pursuing this? It would be interesting for a capable captive portal to send and listen on LLDP *as well*. In particular, LLDP lets the captive portal get MUD signals from the new device as well. This is important as captive portals won't be able to challenge many devices that might be carried by people in the future, and it would be a nice addition if a person could authorize a second device they happen to own via their laptop. This is very much out of scope for current work. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] IETF 104 Prague -- call for agenda items
Alexander Roscoe wrote: > I was thinking about allocating some time for the hackathon. Is there any > work or ideas that we could test out? Also, there is a hackdemo time on Monday. > On Mon, Feb 25, 2019 at 8:51 PM Remi NGUYEN VAN > wrote: > Although I am still unsure I can have something ready by then, I would be > glad to show some simple demo for Android. To be confirmed later, but if > we have a slot, maybe I can have something set up. > Cheers, > Remi > On Wed, Feb 20, 2019 at 10:33 AM Erik Kline > wrote: > All, > Things have been rather quiet around here, but I thought we should > see who's planning to be in Prague and whether anyone would like to > request agenda time. > At a minimum, we would have a bit of chairs' time to discuss the > general state of things. (Our milestones need updating, too.) > Additionally, it seems as though some folks from the Wireless > Broadband Alliance (wballiance.com) may be able to attend and present > about their work in the Captive Network Portals space. I would > reserve some agenda time for their liaison presentation and follow-on > discussions. > Let us know if you'd like some agenda time.. There was some > implementation discussion in Bangkok; demos would of course be > welcome too. > Thanks, > -Erik > ___ > 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 > -- > Alexander Roscoe > 484-716-9048 > > Alternatives: > > ___ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] poor captive port design --- A Deep Dive on the Recent Widespread DNS Hijacking Attacks — Krebs on Security
Michael Richardson quoted: > From https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/ > "The two people who did get popped, both were traveling and were on their > iPhones, and they had to traverse through captive portals during the hijack > period,” Woodcock said. “They had to switch off our name servers to use the > captive portal, and during that time the mail clients on their phones checked > for new email. Aside from that, DNSSEC saved us from being really, thoroughly > owned.” Christian Saunders wrote: > The active element here seems to be the forced use of insecure DNS > servers. I disagree. It's due to forced use of the captive portal's DNS. A device will in general have no trust relationship with a captive portal. It has no reason to trust the captive portal to do DNS correctly (and no way to get privacy for the requests either). > The fact that the insecure DNS configuration was forced in order to navigate > a Captive Portal is incidental, though unfortunate. So to me, all captive portal DNS systems are by definition insecure. If one needs to do a DNS lookup in order to get traffic and get a redirection, then the portal is insecure. And that's why we need an API that involves more than just capture port-80 and redirect. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
[Captive-portals] customizing API URLs vs ???
Chris Spencer wrote:
> Would not a feed of option 82 rather than create a new API work? option
> 82 can carry MAC/IP (it could create a GUID/UUID) and other location
> identifiers? if the external portal could get a feed of this, the
> portal at layer 3 could look up the device MAC from the option 82
> elements by the IP? or if the DHCP server is centralised along with
> the portal architecture and DHCP relay is used on the local site?
Option 82 is usually inserted by a DHCP relay when forwarding to a
centralized DHCP server. It certainly could be used to customize the URL,
but in many systems this isn't going to work.
In a vast majority of "coffee shop" systems, the DHCP/RA function occurs on
premises in the router there, but the captive portal is out in the "cloud".
This is particularly prevalent in the smallest multisite installations
(10 locations across a single city), and the biggest multisite installations
("Harbucks" with 10,000 locations) where the operation of the captive portal
itself is outsourced to another company, or just centralized.
It probably occurs less in places like airports, hotels and enterprises where
there is more local operational clue.
So I just don't see how option 82 helps with IPv6 RAs.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works|IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
signature.asc
Description: PGP signature
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Discovering captive portal API URL via DNS?
Lorenzo Colitti wrote: > During discussions with captive portal operators about implementing the > capport API, one of the stumbling blocks that keeps coming up is that > the captive portal operator does not always control the DHCP > configuration and thus cannot easily use RFC7710. Agreed. > The WG has previously rejected the option of using a well-known DNS > name to discover the URL, because the API itself requires TLS, and > without a hostname it is not possible (or at least not easy) to > validate the server. However, what if the client did a CNAME query for > capport.arpa (or equivalent other local-only, non-DNSSEC-signed name), > got back a CNAME for the real server, and then assumed that the API > server was https:///capport-api ? > Alternatively, Erik and Warren suggest RFC 7553. In this scheme the > client would do a URI lookup for "capport.arpa" or equivalent, and > would take the result of that URL as the API endpoint. RFC7553 seems like a better choice than a CNAME hack. So we are trading the assumption that captive portal operator can control DHCP to one where captive portal operator can control/influence DNS, and that things like DoT/DoH can not be used by the captive portal client. (I just want to make the assumption explicit. I'm not complaining about it) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Discovering captive portal API URL via DNS?
Tommy Pauly wrote: > I wanted to clarify the issue a bit before diving into the > mitigations. Do these captive portal operators have *no* relationship > to the DHCP configuration? Presumably, the captive portal enforcement I think that the issue is that the relationship is adversarial: different silos. The example that was given previously was that DHCP belonged to the "desktop" group, while DNS belongs to the "network" group in some enterprise. The DHCP all backends (via relays) to some DHCP servers, while the DNS is operated by the "Internet" group. That probably means that capport.arpa (and ipv4.arpa) will get populated, and all of the non-captive desktops will see that. I think that this is okay. > Since the mitigation below is specific to modifying the DNS, I assume > that we are talking about captive portal solutions that work, in part, > by intercepting DNS. I don't think that is necessarily the case. The Internet group probably controls the routers, just not the DHCP. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Discovering captive portal API URL via DNS?
Lorenzo Colitti wrote: mcr> that things like DoT/DoH can not be used by the captive portal mcr> client. (I just want to make the assumption explicit. I'm not mcr> complaining about it) > That's not really an assumption - the fact that the captive portal > client can't do DoT/DoH is mostly true today, because unless the portal > is open, 443 and 853 are likely to be blocked. By and large, DoT / DoH > clients probably already know not to attempt them on captive portals. Well, a captive portal could leave HTTPS to cloudflare open, the same way that they might leave Do53 open to themselves, or to quadX. That works today for some portals. And if the portal doesn't let just *any* Do53, but only to known public resolvers (which they can even proxy if they want), then they can be sure to defeat DNS-VPN mechanisms. Some portals today *do* depend upon creating answers for names that aren't real. That fails today if you do DNSSEC validation. Of course, some still depend upon lying about all DNS requests, and but we have agreed that this is bad. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] customizing API URLs vs ???
Nicolas Mailhot wrote: >> It probably occurs less in places like airports, hotels and >> enterprises where there is more local operational clue. > In entrerprises the dhcp layer is mostly owned by desktop IT (ADs, in > the hands of people still stuggling to come to terms with the way > Microsoft adopted networking and the cloud with a vengeance) while > access to the internal network (or from the "safe" internal network to > the wild internet, or from low-security visitor networks to high- > security internal networks) is managed by network or security teams. I'm not sure why you are bringing up desktop IT when I mention DHCPv4. In an enterprise captive portal use, I would expect it would be for visitors. The APs would have a second ESSID, and this would be operated by the network/security team. Whether they do DHCP locally or backhauled, would be their business, not desktop IT? Or are you saying that someone in desktop IT would say, "WE HAVE TO DO ALL DHCP", just because silos? > Network/security teams will want to plop the security portal in a > single tighly controled place (a datacenter, or a set of datacenters > for redundancy), while local/desktop IT would not care less about > security considerations (but then, they are not asked to care about > them). > Therefore, deep collaboration between local networking and the portal > is wishful thinking. The security dialog has to happen between the > client and the central portal, with as little constrains and smartness > as possible delegated to the local networking kit (ideally, just let > everyone talk to the portal, and let IP/Macs/whatever requires as > little effort as possible to identify a system talk to other network > ranges, as long as they match the whitelist published by the central > portal for those ranges). If the Captive Portal Enforcement Point is not on the AP itself, but in some part of the network, then I guess the need for colloboration between wifi people and network people is less. Network people would simply have all the guest traffic on some VLAN, do nothing on the APs themselves (other than VLAN tagging). What is your preference: does the client API have to have the client self-identify, or do we have to find a way to send unique URLs in IPv6 RAs? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
[Captive-portals] customizing API URLs vs ???
{trying to get this into it's own thread}
Remi NGUYEN VAN wrote:
> I think we can either try to solve this problem by having the client
> send an identifier to the API, or state that the API needs to be hosted
> inside the network.
> If we go with option 2, I'm afraid many vendors
> may just rely on DHCPv4 or Link-Relation redirects to give different
> URLs based on the client, which would hurt IPv6 adoption. So I'm
> wondering if option 1 (for example having the client send an identifier
> in the host header of the API request) might be strategically better.
It's relatively easy to customize the URL that a local DHCPv4 server gives out.
Yes, it could also be done by a DHCPv4 relay (with option 82).
As you identify, this hurts enabling IPv6 in captive portals.
An advantage of having the URL change is that the token that is added can be
opaque to the client. Something encrypted. It could even be a JWT. The
client can't screw with the token to attempt to do API calls for a different
client.
If we go with something the client has to make up and provide (which I also
prefer), then we have to worry about how authentic it is. That at least
means that the client has to POST it's info to the captive portal API, and
then get back some things that identify it for subsequent API calls. That's
normal web interaction stuff, so not terribly innovative, but we do need to
think about this.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works|IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
signature.asc
Description: PGP signature
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals
[Captive-portals] API and URL problems for IPv6 RA
A hallway conversation with Lorenzo and Jean Rickard [Rickard Jean], led me to re-read the API and rfc7110bis documents. https://tools.ietf.org/html/draft-ietf-capport-api-03 }4.1. URI of Captive Portal API endpoint } } The URI of the API endpoint MUST be accessed using HTTP over TLS } (HTTPS) and SHOULD be served on port 443 [RFC2818]. The client } SHOULD NOT assume that the URI for a given network attachment will } stay the same, and SHOULD rely on the discovery or provisioning } process each time it joins the network. Depending on how the Captive } Portal system is configured, the URI MIGHT BE UNIQUE FOR EACH CLIENT } HOST AND BETWEEN SESSIONS FOR THE SAME CLIENT HOST. It is typical the case today that the URL that the client is sent to includes the MAC address of the client system, or a token that refers to or contains the (encrypted) mac address. This is often the case because the Portal web server is *not* located on the same L2 network as the client. The discussion was how can this be implemented in IPv6 RAs. The options seem to be: 1) IPv6 RAs will have to be unicast with unique URLs, and the unique info needs to be remembered across clients. (This might be a win on WIFI anyway) 2) The client will need to post it's MAC address to the captive portal URL. How can the captive portal know it's not lying? (Is there an incentive to lie?) 3) It's not work for IPv6-only SLAAC-only networks. 4) There will need to be mechanism to map L3 addresses to L2 addresses between portal system and first-hop router 5) captive mechanism will have to be done for L3 addresses, which means doing it for v4, v6 and each privacy address. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] (no subject)
Brian Shields wrote: > That said, the WBA would like to engage with the IETF to address the issues > as well as provide support to push some of the current IETF capport That sounds exciting. What we really need is more involvment from captive portal operators, and more document review so that we can progress. We have some involvement From smartphone OS vendors already, but things work best when we can have people writing code engage with the documents. > activities to practical trials. The WBA next event will be in Frankfurt on > Oct 2-3, and we would be glad to invite a IETF delegation to discuss a way > forward on the joint collaboration and potentially trials kick-off. So, the IETF is not a single entity, so it's hard to invite "us" You may find this useful --- https://www.ietf.org/about/participate/tao/ > A few of us are planning to join the capport IETF 105 session virtually and > look forward to engaging with everyone there. Thanks very much. Cool. > Brian Shields > VP, Engineering at Boingo > Project Lead, Captive Network Portal Standards for Wi-Fi Workgroup, WBA > > Alternatives: > > ___ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] (no subject)
Brian Shields wrote: > activities to practical trials. The WBA next event will be in Frankfurt on > Oct 2-3, and we would be glad to invite a IETF delegation to discuss a way > forward on the joint collaboration and potentially trials kick-off. I will be in Belgrade Oct. 5-6, but I don't represent the WG. ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
[Captive-portals] putting quarantined IoT devices behind a captive portal (fwd) Michael Richardson: putting quarantined IoT devices behind a captive portal
Again, a WG whose ML is not the WG name, and there is no alias. ARGH.
Here are some emails that didn't get to captive-portals@ietf.org.
Sorry for the duplication for others.
--- Begin Message ---
Between editing drafts yesterday, I got to thinking about CAPPORT.
I have been working on what to do when an IoT device violates it's MUD
profile. There are a bunch of issues around this.
Yesterday, it occured to me that when such a device is quarantined
(I really think it should be "quaranteed", but that's not a word)
that the capport controls and APIs should be available to the device to
learn what went on.
This is not new, I think that this as been the approach of most enterprise
NEA systems upon encountering "infection". This has, I assume, involved
forced HTTP proxies to inform human. But, if we have APIs, we can inform
device as well.
Is this on anyone's radar?
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
Eliot Lear wrote:
> I’m not quite certain how it would work. Can you show a flow that will
> work for an IoT device (e.g., headless and no display)?
Device gets quarantined, and the MUD-controller moves it into an isolated
"VLAN". I put air/scare quotes around VLAN, because it's a "MAC-address
VLAN", not an 802.1Q thing. It's really just a layer-2 ACL.
{We have no way to force the mishaving device into tagging it's packets, nor
can we force it onto some other ESSID. We can't do a "port-based" VLAN,
because wifi has no ports, and we don't really know how many unmanaged
switches might be on the port anyway.
One might map this onto a IEEE 802.1Q VLAN across a backbone}
Instead of just dropping all traffic for a device in this category,
all traffic (other than excepted traffic if you implement
https://datatracker.ietf.org/doc/draft-richardson-shg-mud-quarantined-access/)
would go into a captive portal system.
Such a system would, according to
https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/
receive a message when it initiates connections which are not allowed.
(While the capport WG contemplated an ICMP unreachable message with a
URI in it at one point, that is not the current design)
Actually, I have no idea from reviewing the documentation what the
appropriate "you might be captive" ICMP is now.. THERE IS ONE RIGHT?
Once the IoT device gets such a message, it can use the API
described at: https://datatracker.ietf.org/doc/draft-ietf-capport-api/
to retrieve a JSON object telling it that it is captive. At which point, it
can flash a LED, or attempt a firmware upgrade, or maybe just reboot if a
timer goes off. (%)
This requires that the IoT device get the captive portal API end point, which
https://datatracker.ietf.org/doc/draft-ietf-capport-rfc7710bis/ can deliver
via DHCPv4/v6 or RA.
>> On 9 Jul 2019, at 16:41, Michael Richardson
>> wrote:
>>
>> Signed PGP part
>>
>> Between editing drafts yesterday, I got to thinking about CAPPORT. I
>> have been working on what to do when an IoT device violates it's MUD
>> profile. There are a bunch of issues around this.
>>
>> Yesterday, it occured to me that when such a device is quarantined (I
>> really think it should be "quaranteed", but that's not a word) that
>> the capport controls and APIs should be available to the device to
>> learn what went on.
>>
>> This is not new, I think that this as been the approach of most
>> enterprise NEA systems upon encountering "infection". This has, I
>> assume, involved forced HTTP proxies to inform human. But, if we have
>> APIs, we can inform device as well.
>>
>> Is this on anyone's radar?
>>
>> --
>> Michael Richardson , Sandelman Software Works
>> -= IPv6 IoT consulting =-
>>
>>
>>
>>
>>
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
--- End Message ---
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] DHCP/Captive Portal Experiment at IETF106 - SIN
Christopher Morrow wrote: > During setup at the IETF meeting this week in Singapore the noc folk > setup an experiment on the IETF wireless network, specifically on the > IETF SSID to test your shiny new DHCP option(s) for captive portal, > information about that is detailed here: > https://tickets.meeting.ietf.org/wiki/CAPPORT > So far, during our setup we noticed Polycom conference phones are > 'unhappy' with this DHCP option (over ipv4). The Polycoms appear to > believe that option 160 is for 'boot file location' :( Ingesting a json > file for booting makes the Polycom sad :( So, did they squat on this option, and should CAPPORT ask for a new number? signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] DHCP/Captive Portal Experiment at IETF106 - SIN
Erik Kline wrote: > Some of the comments in that thread seem very disappointing and > aggravating even (saying they'll use 161 if they need to, for example, > which is allocated for MUD). DHCP options are not hard to get. Polycom should know better. signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] DHCP/Captive Portal Experiment at IETF106 - SIN
Warren Kumari wrote: >> Christopher Morrow wrote: > During >> setup at the IETF meeting this week in Singapore the noc folk > setup >> an experiment on the IETF wireless network, specifically on the > IETF >> SSID to test your shiny new DHCP option(s) for captive portal, > >> information about that is detailed here: > >> https://tickets.meeting.ietf.org/wiki/CAPPORT >> >> > So far, during our setup we noticed Polycom conference phones are > >> 'unhappy' with this DHCP option (over ipv4). The Polycoms appear to > >> believe that option 160 is for 'boot file location' :( Ingesting a >> json > file for booting makes the Polycom sad :( >> >> So, did they squat on this option, and should CAPPORT ask for a new >> number? > So, I had a very brief chat with IANA about this - because the > assignment is in an RFC, changing it will be hard - it would require > deprecating RFC7710, and publishing a new one with just the port > changed... Oh, yes.. I forgot that it was in the RFC not the new ID. > Seeing as RFC7719bis is almost done (hopefully!) it seem to me that it > would make more sense to just ask for a new port in that. I think that we can do that. Unless the result is that polycom devices brick, in which case, I think we should stick with 160, and Polycom can deal with being bad netizens. > What would be interesting would be to try figure out if the next few > codes (162 - 174) are “clean”. Yes, I agree that we need to do that, and to recycle 160 to the end of the list to be marked as unused and to be allocated at the end. I'm so glad we discovered this now. > E.g: Wyze seems to squat on 162, 163 is > “Cisco-client-last-transaction-time” (?), etc. > The current conflict with Polycom seems really bad (People having > remote meetings often travel with polycoms). We really shouldn’t let > squatters-rights drive our decisions, and I don’t think that conflicts > with others will be as bad Warren, I'd like to ask the IAB Program that produced draft-iab-protocol-maintenance to consider some set of processes for squatters. (Squatters are tolerated by by being liberal in what you accept) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] CAPPORT API with real Captive Portals and Linux Client: End-to-End demo
Heng Liu wrote: > We were wondering if a demo of such would be useful to the committee in > the coming IETF 106 in Singapore if CAPPORT API is a topic of interest. You could certainly put it online during the Hackathon. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Onboarding devices and Captive Portal API
M. Ranganathan wrote:
> There are scenarios involving device onboarding where Captive Portal
> capability seems like a good fit.
> Consider a device that has been securely onboarded onto a network. The
> device wants to present a signed credential to the network (e.g. it
> could present its signed MUD URL) that can be evaluated challenged by
> the captive portal server.
> Following up on a suggestion by Michael Richardson, can the Captive
> Portal API be extended to do this?
I think that there are two important things here:
1) the capport interface provides a high-level (vs low-level RA) interface
between a
host and the operator of the network.
--> new interfaces can be offered by extending the json file.
2) networks that have devices that use RFC8520(MUD), will want to run capport
in order to be able to communicate the fact that device has been quarantined.
{I think that I owe an ID on this concept}
> 1. Device onboards and presents its certificate, and signed MUD URL to
> the captive portal server.
If the onboarding mechanism uses an IDevID, then that part has already been
communicated. The MUD URL can be embedded into the IDevID certificate, and
the URL is signed by the *manufacturer*, not the device itself.
The device proves who it is by possession of private key.
This is different than the DHCP mechanism for MUD, which is entirely under
control of the device, and thus the malware.
> 2. Captive portal server verifies the
> certificate using the manufacturer certificate.
> 3. If certificate and
> signature are valid, then Captive Portal server removes the device from
> quarantine and allows it onto the network. It could optionally
> challenge the device to authenticate it but presumably that step has
> already been done during onboarding.
I don't think that we should do these things with the captive portal.
> Another situation where captive portal could be useful is BRSKI. Not
> sure if these use cases are too far removed from the intended use of
> this specification.
I don't think this is quite the direction I had in mind.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| network architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
signature.asc
Description: PGP signature
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] option 160 conflict
Warren Kumari wrote: >> One option we have is to use Code 114, which was reserved for use by >>Apple as a "URL" option. That particular codepoint wasn't ever used, so >>it should be open to be reclaimed as a CAPPORT API URL. Since this is in >>the range below 128, it should be safer to use. > I *really* like this idea - the options even contains something that > looks like a URL :-) I also like it. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] AD review of draft-ietf-capport-architecture-07
Barry Leiba wrote: > Martin, should I hold the telechat scheduling of the other two > documents to make sure that architecture is on the same telechat as > they are, so the IESG is reviewing them all together? I think that's > best, but can be convinced not to have the others wait. So you want to have: 1) API 2) architecture 3) rfc7710bis all on the 2020-05-21 telechat? That would be awesome! -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] [homenet] [Int-area] [EXTERNAL] Re: Evaluate impact of MAC address randomization to IP applications
Christian Huitema wrote: > Martin is making an important point here. There are a number of privacy > enhancing technologies deployed at different layers: MAC address > randomization at L2, Privacy addresses at L3, various forms of > encryption and compartments at L4 and above. Each of these technologies > is useful by itself, but they can easily be defeated by deployment > mistakes. For example: You are spot on. But, even your four points muddle things. We need some diagrams that we can all agree upon, and we need to name the different observers. Each thing defends against different kinds of observers, and not all observers can see all things. Some observers may collaborate (I invoke, the WWII French resistance emotion for this term...) Some observers may have strong reasons not to. > 1) Using the same IP address with different MAC addresses negates a lot > of the benefits of randomized MAC addresses, This assumes that a single observer can observe both at the same time. WEP++ leaves MAC addresses visible, but encrypts the rest of L3 content. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] [homenet] [Int-area] [EXTERNAL] Re: Evaluate impact of MAC address randomization to IP applications
<#secure method=pgpmime mode=sign>
Brian Dickson wrote:
> Any host/interface that uses ARP (not sure whether any flavor of WiFi
> does, or if so which flavors), exposes the L3/L2 mapping.
Yes, WIFI does use ARP. On all flavours.
Encrypted WIFI, which is mostly the default now, encrypts everything above
the L2, so the L3 part of the mapping is not seen by passive EM observers.
ARP broadcasts as you mention, so other stations on the network could see the
mapping, and the AP by default helpfully re-encrypts broadcasts to every
station. But, that's not a passive observer: the observer is on the network.
Many APs filter ARP broadcasts as being useless chatter.
> So, wired
> IPv4 for certain (except in very locked-down enterprise settings with
> static MAC addresses, perhaps) leaks this information to every host on
> the same broadcast domain (same subnet and possibly additional subnets
> on the same LAN/VLAN).
Yes, but that's not wifi. Phones do not have wired connections.
> ARP L2 broadcasts solicit information about IP addresses, and at a
> minimum each such query exposes its own MAC and IP address. Responses
> may be unicast or broadcast, not sure which. An active compromised
> host can easily solicit that information by iterating over all the IP
> addresses on the subnet and performing an ARP for each one.
It will be good if we can get a document from the MAC randomization
proponents (if there is such a group), to explain the thread profile.
I don't think it includes active compromised hosts.
Such hosts can also ARP/ND spoof, and can even do that for the router (".1"),
capturing all the traffic on the network.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] [homenet] [Int-area] [EXTERNAL] Re: Evaluate impact of MAC address randomization to IP applications
Stephen Farrell wrote: > On 29/09/2020 19:41, Michael Richardson wrote: >> It will be good if we can get a document from the MAC randomization >> proponents (if there is such a group), to explain the thread profile. >> I don't think it includes active compromised hosts. > That is a problem yes. I no longer think "compromised host" is the > correct term there though. In the case of android, we found google play > services regularly calls home linking all these identifiers and more > (phone#, sim serial, imei...) [1] for Google's own uses. I'd be very I feel that you have confounded two things, and I don't think it's helpful. I won't dispute your observatrions about surveillance capitalism, but I feel that you've sensationalized what I thought was a pretty specific technical point. Namely: You can't see into the L3 layer of WIFI, even when there are ARP broadcasts, unless your are also part of that L2 network. I'm sure that Google Play calls home and tells Google all the your L2/L3/IMEI/etc. I don't doubt it. I don't see how this relates to a local passive eavesdropping observing the L2 frames with the encrypted L3. One not involved with the operation of the wifi, nor connected to that link. Unless you are saying that Google Play operates as active eavesdropper on all the networks on which it is connected? I.e. it sends the L2/L3 mappings for all devices on that network? > More on-topic, I do think MAC address randomisation has a role to play > for WiFi as it does for BLE, but yes there is a lack of guidance as to > how to implement and deploy such techniques well. It's a bit tricky > though as it's fairly OS dependent so maybe not really in scope for the > IETF? The IEEE has a spec on how to do MAC address ramdomization. It says nothing about how to automatically update the accept-list rules created by RFC8520, or RFC8908/RFC8910 (CAPPORT). Or EAP-FOO. > (For the last 3 years I've set a possible student project in > this space, but each time a student has considered it, it turned out > "too hard";-) :-( -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] [Int-area] [homenet] Evaluate impact of MAC address randomization to IP applications
Pascal Thubert \(pthubert\) wrote: > Hello Dave and all: > So far I have not seen how the MAC randomization deals with: > - differentiated environments - the preferred behavior on a highway or > at a coffee shop may differ from that at in a corporate or a DC > network. In the corporate network, we can expect something like .1x to > undo the privacy, for good reasons. And we can expect state to be > maintained for each IP and each MAC. When a MAC changes, there can be > unwanted state created and remaining in the DHCP server, LISP MSMR, > SAVI switch, etc... Privacy MAC is only an additional hassle that we > want to minimize. If we can assume 802.1X using an Enterprise scheme, and using a TLS1.3 substrate, then if the identity resides in a (Client) TLS Certificate, it will not been by a passive attacker. The MAC address is outside of the WEP encryption, so it is always seen, even if the traffic is otherwise encrypted. An EAP-*TLS based upon TLS1.2 would reveal the identity, at least the first time. Perhaps this is a reason to support resumption tokens in EAP-TLS! -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] [homenet] [Int-area] Evaluate impact of MAC address randomization to IP applications
Bob Hinden wrote: > I have read the emails and the draft . I am not clear what the goal of the BOF is. > Could the proponents state it clearly? I can't speak for the proponents, but at the simplest, one could add: "how can we do X if the MAC cannot be used as identity" > • LAN gateway NAPT forwarding - (PRESENTER TBD) > • Static NAPT policies - (PRESENTER TBD) > • Persistent DHCP IP address assignments - (PRESENTER TBD) > • Device-to-user or group association for malware protection - (PRESENTER TBD) > • Device-to-user or group association for parental controls - (PRESENTER TBD) > • Device-to-user or group association to restrict or authorize unwanted > or unverified device connections to the LAN - (PRESENTER TBD) I don't get the NAPT issue though. The NAPT issues are because DHCP gave the device a different IP(v4), right? If you solve persistent DHCP, then you solve those, don't you? -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] [Int-area] Evaluate impact of MAC address randomization to IP applications
Damn. Spelt captive-portal without the s again. Reposting, sorry for duplicates. I hate when WG names and list names do not match, and that we can't have aliases. And I think that reply-to gets filtered. Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/14Skgm84GslPZ9UcGoWY3uzmK6I> To: int-a...@ietf.org, captive-por...@ietf.org, home...@ietf.org From: Michael Richardson Date: Tue, 22 Sep 2020 16:34:33 -0400 This thread was started today on the INTAREA WG ML. While I don't object to a BOF, I don't know where it goes. What I see is that much of this problem needs to be resolved through increased use of 802.1X: making WPA-Enterprise easier to use and setup, this changing core identity from MAC Address to IDevID. My understanding is that Apple intends to randomize MAC every 12 hours, even on the same "LAN" (ESSID), and that they will just repeat the WPA authentication afterwards to get back on the network. If the per-device unique policy (including CAPPORT authorization) can be tied to the device better, than the MAC address based "physical" exception can be updated. But, WPA-PSK doesn't work, because it does not, in general, distinguish between different devices. It can be made to work if every device is given a unique PSK, and there are some successful experiments doing exactly that. Mostly it just works, but the challenge is communicating the unique PSK through an unreliable human. BRSKI can certainly do this, and it can leverage that unencrypted ESSID present at most hospitality locations to get onto the encrypted WPA-Enterprise. Or BRSKI-TEEP, or some other BRSKI-EAP method. The unencrypted SSID is not going away at those locations. Thus QR-code based methods are best, yet those do not work for many IoT devices. EMU's EAP-NOOB can help in certain cases, but we, as a community need be clear on what direction we want to go. One answer is that IoT devices have little reason to randomize their MAC if they are not generally ported. On 2020-09-22 3:49 p.m., Lee, Yiu wrote: > Hi team, > > We proposed a BoF. The agenda is in > https://github.com/jlivingood/IETF109BoF/blob/master/109-Agenda.md and the > proposal is in > https://github.com/jlivingood/IETF109BoF/blob/master/BoF-Proposal-20200918.md. > You > can also find the draft here > https://tools.ietf.org/html/draft-lee-randomized-macaddr-ps-01. > > At this stage, we are looking for inputs for more use cases and interests > of working together in this domain. Please post your comments in the > mailing list. > > Thanks > -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] [homenet] [EXTERNAL] Re: [Int-area] Evaluate impact of MAC address randomization to IP applications
Martin Thomson wrote: > Maybe that is out of scope for your draft, but it shouldn't be out of > scope for a group that attempts to look more closely at providing > advice for dealing with these features. > (Does this thread really need to be cross-posted so widely? Can we decide on a single venue?) Blame me :-) It's only three lists. It's not like I CC'ed to ADD, emailcore and the dns* groups :-) I didn't think that Yiu's post to int-area would catch all the right flies. Apparently it might get a BOF ML soon. and I felt that it deserved wider review and excitement. Our mailman strips off Reply-To: since we did that DMARC avoidant hack (AFAIK), so redirecting replies only works if we all agree. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] [homenet] [Int-area] Evaluate impact of MAC address randomization to IP applications
Brian Dickson wrote:
>> I don't get the NAPT issue though.
>> The NAPT issues are because DHCP gave the device a different IP(v4),
right?
>> If you solve persistent DHCP, then you solve those, don't you?
>>
> I think there are some environments where that isn't technically accurate,
> or might not be 100% accurate.
> E.g. The difference between DHCP6 and that other wacky thing that is doing
> random self-assigned IPv6 addresses.
Sure. If there is a port mapping (or PCP created incoming ACL for IPv6),
which is bound to a particular IPv6 (however assigned), and that the IPv6
changes, then the mapping will break right?
This is independant of MAC address randomization right?
If we changed the MAC address, and then kept the IP address involved, then ND
would fix things up, and things would continue just fine.
> (E.g. maintaining the IP address when the MAC changes, defeats at least
one
> possible purpose of changing the MAC.)
I strongly disagree here.
We use privacy IPv6 addresses in order to keep legitimate distant end points
(and their associated snoops) from tracking one for place to place.
We use different MAC addresses for different networks to keep from being
tracked by a federation of local snoops from place to place.
We change our MAC address at the same network to hide our time of use and
presence from local snoops. But, also to deal with malicious attackers who
put up a common ESSID ("Starbucks"). We can, and do encrypt our IPv6
address on those networks. But, we can't encrypt our MAC address, because as
you say, it used for media access control.
> I sense a potential rat-hole, but also the possibility of finding common
> ground to fix a bunch of things that are problematic to some degree or
> another.
I hope so too.
> I'm hopeful that something like 802.1x can be made use of effectively, but
> again a lot depends on the use cases and will likely require pretty deep
> dives on each of the relevant technologies and implementations.
> IMNSHO, MACs should be relegated to the role reflected in their name:
Media
> Access Control, basically a disambiguator, not an identity.
> Maybe MACs should be used the way the initial values selected by the two
> parties doing DH key exchange are used, just as a stepping stone in
> establishing a cryptographically-strong "thing" that only they know.
> I.e. use the initial MAC (regardless of what it is) as an initial layer-2
> communications things, during the set-up of {whatever the BOF/WG output
> is}, after which the MAC gets changed to {something else}.
An interesting idea.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] [homenet] [Int-area] [EXTERNAL] Re: Evaluate impact of MAC address randomization to IP applications
Stephen Farrell wrote: >> Stephen Farrell wrote: >> >> > On 29/09/2020 19:41, Michael Richardson wrote: >> It will be good if >> we can get a document from the MAC randomization >> proponents (if >> there is such a group), to explain the thread profile. >> I don't >> think it includes active compromised hosts. >> >> > That is a problem yes. I no longer think "compromised host" is the > >> correct term there though. In the case of android, we found google >> play > services regularly calls home linking all these identifiers and >> more > (phone#, sim serial, imei...) [1] for Google's own uses. I'd be >> very >> >> I feel that you have confounded two things, and I don't think it's >> helpful. I won't dispute your observatrions about surveillance >> capitalism, but I feel that you've sensationalized what I thought was >> a pretty specific technical point. Namely: You can't see into the L3 >> layer of WIFI, even when there are ARP broadcasts, unless your are >> also part of that L2 network. > I disagree about sensationalising, obviously;-) > The point is that we tended to think of a compromised host as one that > had been subject to a successful attack often run by an unknown > party. For mobile phones, the privacy adversary seems more often to be > an entity that the phone user has accepted one way or another, whether > that be the OS or handset vendor or whoever wrote that cute spirit- > level app. My take home from your work is that MAC address randomization is a useless waste of time. It causes significant costs to the network operator(s) without actually providing any benefit to the mobile phone owner, because the adversary is inside the device, invited in by the owner. In such a situation, MAC randomization feels like security theatre to me. [I'm reminded of various systems of magic in fiction, where you are safe as long as you don't unwittingly invite the bad guys in] You have defined the security perimeter as being from "top" of the phone. (Between the screen and the human) I have defined the security perimeter as being the "bottom" of the phone (between the phone and the Internet). I think that we can do more here, and I think that the cost to the operator (moving from unencrypted, MAC-address excepted networks, to encrypted 802.1X authenticated networks with provisioned identities) with some correspondant benefits to the operator as well as the end user. > PS: to be clear - the above's not really anti-google - we've seen > similar looking traffic from handset vendors' pre-installed s/w too. Agreed. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Murray Kucherawy's No Objection on draft-ietf-capport-rfc7710bis-07: (with COMMENT)
Murray Kucherawy via Datatracker wrote:
> In Section 2, paragraph 2, it says the operator "SHOULD ensure that the
URIs
> provisioned by each method are equivalent". Does "equivalent" here mean
> "identical", or just "synonymous"?
{speaking as a WG member}
synonymous, I think that we are not insisting that each method have identical
names, because there might be different connectivity to each. Imagine:
"ipv6.portal.example"
"portal.example"
"v4.portal.example"
and since DHCPv4/v6 can customize the answer with a URL that includes
a ?query, while RA's can not, that it a further reason why they might not be
the same.
The sentence leading up to this word speaks of different classes of clients
already.
HOWEVER, I think that we might be in error in section 3, where we say that
they have to be identical. Oops.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works|IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
signature.asc
Description: PGP signature
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] A final check on draft-ietf-capport-architecture-09
Martin Thomson wrote: >> I'd rather we didn't allow for iPAddress SANs, but it's not a sword I'll die on. > Ack. Personally, I'm more concerned about implementations allowing an > override option other than through modifying the trust store. A domain > name is equally problematic there (let's hope we don't see .home > addresses...). But I don't see any easy path to a per-host override > based on what I've seen in implementations so far. Again, some enterprise PHB will point to this paragraph and tell the techie that s/he doesn't need to do things the right way. I've been there. So I would like to know why we added it. We can specify a subset of RFC6125. >> The next part says: >> An Enforcement Device SHOULD allow access to any >> services that User Equipment could need to contact to perform >> certificate validation, such as OCSP responders, CRLs, and NTP >> servers; >> >> That's a good list, and that list can be seen from looking at the >> certificates that the captive portal operator is going to use. >> But, aren't there *also* systems (Mozilla? Chrome?) where the respective >> vendors are collecting that info into a central place to make stuff go >> faster? I can't quite find what I'm looking for in a search, because >> OCSP-Stapling is not what I'm talking about, and eliminates the need. > Yes, browsers are providing systems that help with revocation. Mozilla > has OneCRL and CRLite; Chrome has CRLSets; offhand, I don't know what > Microsoft and Apple might be doing differently. Those systems that I'm > aware of don't require network access at validation time. The whole > point being to provide timely information about revocation without > depending on a live OCSP or CRL fetch (which have poor privacy > properties in addition to adding to fragility). Ah, okay. The CRL is "built-in", so it does not need to be fetched while in captivity. Thank you. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] A final check on draft-ietf-capport-architecture-09
I've read through the diffs: One that jumped out at me: If the API server is identified by IP address, the iPAddress subjectAltName is used to validate the behavior described above. This was added based upon some review comment. While I can't really object to the idea, I am concerned. What are the transports that result in only being able to provide a public IP address? How many common PKI trust anchors are supporting iPAddress SANs today? This seems like it's opening a situation where someone will deploy on RFC1918 addresses and then expect clients to do some exception processing. Particularly in corporate guest networks where they only tested with their devices that already have their private PKI anchors. I can think of a few captive portal product managers that I have interacted with that would simply not understand this. I'd rather we didn't allow for iPAddress SANs, but it's not a sword I'll die on. The next part says: An Enforcement Device SHOULD allow access to any services that User Equipment could need to contact to perform certificate validation, such as OCSP responders, CRLs, and NTP servers; That's a good list, and that list can be seen from looking at the certificates that the captive portal operator is going to use. But, aren't there *also* systems (Mozilla? Chrome?) where the respective vendors are collecting that info into a central place to make stuff go faster? I can't quite find what I'm looking for in a search, because OCSP-Stapling is not what I'm talking about, and eliminates the need. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] CAPPORT support in iOS 14 and macOS Big Sur betas
Not really a CAPPORT protocol problem... but... Tommy Pauly wrote: > One point I wanted to clarify: the iOS and macOS betas support for > CAPPORT discovery and APIs still goes through the standard and existing > UI flow for captive portals. The times in which the captive portal UI > is shown is limited, for example to times when the user is in WiFi > settings. Is there a simple way for the user to get back to the portal page from the notification bar? Can the user choose to keep it open longer? I noticed on the Thalys train that if you closed the portal page that it tended to kick you off the network. That is definitely an anti-pattern!!! I don't know how we will cope with it, while at the same time, making it clear that it's a bad design. Worse was that the portal page had a nice tiled map with the current location... AND THE TILES WERE NOT LOCAL. So as more and more people learnt to keep the page open... the network got significantly slower. > Thus, while adoption should indeed be easy and only require > adding a small bit of infrastructure in order to provide a flow that > doesn’t require redirects, the set of circumstances in which a network > can display content to the user is not increased. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Benjamin Kaduk's Discuss on draft-ietf-capport-architecture-08: (with DISCUSS and COMMENT)
Benjamin Kaduk via Datatracker wrote: > (3) Probably a "discuss discuss", but ... in Section 1 we have: >* Solutions SHOULD NOT require the forging of responses from DNS or > HTTP servers, or any other protocol. In particular, solutions SHOULD > NOT require man-in-the-middle proxy of TLS traffic. > I'd like to understand the motivation for this one a little better. > Naively, it seems like we could get away with "MUST NOT require" while > still allowing it to be done. Am I missing something obvious? Speaking as a contributor, a) I hate "SHOULD NOT", and "MUST NOT", because I find it confusing to non-native english speakers, and so I'd rather write in the form of positive statements. Solutions MUST permit clients to perform DNSSEC validation, which rules out solutions that forge DNS responses. Solutions SHOULD permit clients to detect and avoid TLS man-in-the-middle attacks without requiring a human to perform any kind of "exception" processing. b) I think that we have "SHOULD NOT" for TLS, because there are many Windows-Group-Policy situations which have been deployed where the MITM is official and is authenticated, but this fails for BYOD. While most of the captive portals we are aware of are at airports, etc. they are also used for corporate guest networks, and when writing an RFP for such a thing, we need this document to describe something sensible. > -- > COMMENT: > -- > I'd like to see some more discussion of which signals are authenticated > and how, and what kind of authorization checks are possible. In > well-run networks DHCP and RA signals should be relatively trustworthy, > but clients don't always have a good indicator for whether a given > network falls into that category. Are there (other) mechanisms that > can be used to give trust in the authenticity of a given Captive Portal > API URI and that that API is authorthorized to provide unconstrained > access for the network in question? Yes, there are mechanisms, but they are very specific to the client operating systems involved, and they are not standardized. Most index upon the ESSID identity to catagorize the network into "Home" / "Work" / "Public", to use the Windows terminology. I think that the WG decided that this was a rathole we did not need to go into, particularly for a PS. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] [Technical Errata Reported] RFC8910 (6620)
RFC Errata System wrote: > - > In RFC8908 the relevant Content-Type is defined as > "application/captive+json" and not "application/capport+json". Wow, thank god for the summary, and even with it, I had to read four times to really see the difference! Sounds legit, and a great way to show off the XML patcher! -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Capport return of experience and... questions :(
Xavier BEAUDOUIN wrote: > We are a national Wi-Fi provider in Luxembourg and we provide public > Wi-Fi hostpots all around the country (~20K users / day). Few weeks Wow, thank you so much for doing this... I'm sorry that it caused problems... > # The device requested 2 times the captive portal > landing page too # Notes : That seems weird. > # * The user has just activated his wi-fi > session (his state passes from captive=true to captive=false) > # * The > device decided to open again the captive portal pop-up without checking > for the captivity current state The thing that I'm thinking about is ETag, Caching, etc. headers on the replies. I think that there should never be caching, but it feels like maybe iOS is caching something. I can't say if it's a bug or what. I'm hoping we'll find soneone replying here about this, perhaps offering to debug this with you. (This might be a job for the IETF Hackathon VPN... which does L2 stuff) > Unfortunatly we decided to stop support of capport on our national > network until we are able to fix a workaround about this. :-( -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
