Re: [Captive-portals] Capport return of experience and... questions :(

On Mon, Jul 18, 2022, at 17:37, Michael Richardson wrote: > 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) Tommy probably knows what is going on. Or at least can help

[Captive-portals] Fwd: [rfc-i] Document Action: Comcast's Web Notification System Design to Historic

This news might be of interest here. - Original message - From: "RFC ISE (Adrian Farrel)" To: rfc-inter...@rfc-editor.org Subject: [rfc-i] Document Action: Comcast's Web Notification System Design to Historic Date: Saturday, March 20, 2021 03:19 The ISE has approved changing the status

Re: [Captive-portals] RFC 8952 on Captive Portal Architecture

Hey everyone, Join me in thanking the editors of the new RFC. This was good work. I'll be talking to Barry now about formally closing the group. We'll leave this list open in case people want to continue to discuss new work on this topic. On Tue, Dec 1, 2020, at 13:51,

Re: [Captive-portals] [EXTERNAL] Re: [homenet] [Int-area] Evaluate impact of MAC address randomization to IP applications

There's an additional consideration that might be worth pulling out here. And it's not an impact on network operations, it's a potential for applications that interact with these network services to undo the work of lower parts of their stack. For instance, if your device connects to the same

Re: [Captive-portals] A final check on draft-ietf-capport-architecture-09

uch a thing. > > But...maybe that's a separate document? > > On Sun, Aug 9, 2020 at 5:11 PM Martin Thomson wrote: > > The editors of draft-ietf-capport-architecture have put in a huge amount of > > work over the past few weeks in addressing the review comments. > >

Re: [Captive-portals] A final check on draft-ietf-capport-architecture-09

On Mon, Aug 10, 2020, at 14:18, Michael Richardson wrote: > I've read through the diffs: Thanks! > 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?

Re: [Captive-portals] CAPPORT support in iOS 14 and macOS Big Sur betas

Tommy, this is great! Thanks for all your work here, it's good to see this turn into something concrete. On Tue, Jun 23, 2020, at 07:30, Tommy Pauly wrote: > Hello CAPPORT, > > I wanted to highlight an announcement we’ve made for the betas of iOS > and macOS released today: > > How to

Re: [Captive-portals] Martin Duke's Discuss on draft-ietf-capport-api-07: (with DISCUSS and COMMENT)

On Sun, Jun 7, 2020, at 12:53, Martin Duke wrote: > > > On Sat, Jun 6, 2020 at 4:52 PM Tommy Pauly wrote: > > > > > > I believe in this case the architecture document needs to change, or > > clarify that this MUST refers to that the mechanism needs to be *able* to > > communicate such a

Re: [Captive-portals] Secdir last call review of draft-ietf-capport-rfc7710bis-04

On Tue, May 19, 2020, at 07:08, Rifaat Shekh-Yusef wrote: >it provides the client of the API >an opportunity to authenticate the server that is hosting the API. >This authentication is aimed at *allowing a user to be reasonably >confident that the entity providing the Captive

Re: [Captive-portals] Secdir last call review of draft-ietf-capport-rfc7710bis-04

Adding more lists. On Sun, May 17, 2020, at 02:50, Rifaat Shekh-Yusef wrote: > > Here is a quote form the API document: > > "The hostname of the API SHOULD be displayed to the user in order to > > indicate the entity which is providing the API service." > > > > This seems to suggest that the

Re: [Captive-portals] Last Call: (CAPPORT Architecture) to Informational RFC

On Tue, May 12, 2020, at 22:32, Bob Harold wrote: > > How does the capport wg feel as a whole about this question? [MAC as > > identifier] > > I am also wondering the same thing. We did discuss this, if I recall. From memory, there were a few reasons not to go further: MAC randomization

Re: [Captive-portals] Last Call: (CAPPORT Architecture) to Informational RFC

Or does it coordinate with it? – > [Resolved, Please ignore] > > > > *From: *Captive-portals on behalf of > Bob Harold > *Date: *Monday, May 11, 2020 at 10:35 AM > *To: *"last-c...@ietf.org" > *Cc: *"capport-cha...@ietf.org" , > "draft

Re: [Captive-portals] Secdir last call review of draft-ietf-capport-rfc7710bis-04

I think that the standard assumption is that we can equate the ability to send a DHCP response or a RA with control of the network (or at least those aspects of the network upon which clients rely on DHCP/RA for). I don't know if that assumption is written down in a place we could cite it, but

Re: [Captive-portals] Captive-Portal Identification in DHCP / RA draft-ietf-capport-rfc7710bis-03

Thanks for the input. Apparently great minds think alike as another reviewer found the exact same shortcoming just days ago. The next revision should have these fixed. On Tue, Apr 28, 2020, at 05:07, Tirupachur Comerica, Subash wrote: > > Hi, > > I was reviewing this draft and found a few

[Captive-portals] Publication has been requested for draft-ietf-capport-api-06

Martin Thomson has requested publication of draft-ietf-capport-api-06 as Proposed Standard on behalf of the CAPPORT working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-capport-api/ ___ Captive-portals

[Captive-portals] Publication has been requested for draft-ietf-capport-architecture-07

Martin Thomson has requested publication of draft-ietf-capport-architecture-07 as Informational on behalf of the CAPPORT working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-capport-architecture

[Captive-portals] Publication has been requested for draft-ietf-capport-rfc7710bis-03

Martin Thomson has requested publication of draft-ietf-capport-rfc7710bis-03 as Proposed Standard on behalf of the CAPPORT working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-capport-rfc7710bis

[Captive-portals] WGLC ends for all drafts

Thanks to everyone who reviewed and contributed to these drafts. That includes 7710bis, the architecture and API documents. There were a few issues raised during WGLC, but as far as I can see, nothing that would prevent us from proceeding. I've asked the editors to try to resolve those and

Re: [Captive-portals] WGLC on draft-ietf-capport-architecture and ...-api

t text recommends against a spoofable signal, but doesn't really say what it means to spoof. What do the editors of the spec think? On Tue, Mar 24, 2020, at 13:52, Gurshabad Grover wrote: > On 3/5/20 12:25 PM, Martin Thomson wrote:> This starts a joint working > group last call on these do

[Captive-portals] IETF 107 capport session cancelled

After consultation with my co-chair and our area director, we have agreed to cancel the capport meeting at IETF 107. As all of our documents are currently in WGLC, I think that it would be best for people to devote their time and attention to reviews of those documents. As a reminder, you

[Captive-portals] WGLC on draft-ietf-capport-architecture and ...-api

Hi folks, Our fine editor teams have contributed updates to these drafts. https://tools.ietf.org/html/draft-ietf-capport-architecture-06 https://tools.ietf.org/html/draft-ietf-capport-api-05 This starts a joint working group last call on these documents. Please respond this mail with your

Re: [Captive-portals] WGLC on draft-ietf-capport-rfc7710bis-01

compared to a full-fat browser. I realize that this is in tension with the desire to minimize tracking of people across points of physical connectivity. I think that the best we can do is recognize that tension and let people reach their own conclusions. On Mon, Mar 2, 2020, at 09:49, Martin

[Captive-portals] WGLC on draft-ietf-capport-rfc7710bis-01

Hi everyone, The editors of draft-ietf-capport-rfc7710bis-01 believe it to be ready for publication. Please send comments on this before 2020-03-16. Comments supporting publication as-is are valued as much as comments highlighting issues. Note that Erik is an editor of this document, so he

Re: [Captive-portals] Remediation url for CAPPORT

On Mon, Jan 20, 2020, at 17:54, Michael Richardson wrote: > There are a number of locations where you get 20 minutes free, and then you > have to purchase the extension. That doesn't seem to fit into remedial to > me. (Montreal Airport comes to mind) > > I guess such locations have an incentive

[Captive-portals] Notes from todays informal meeting

Mention PvD in the architecture as it is in AD review 7710bis link relation shall be removed codepoint 160? we should deprecate 160, register it for polycom, pick a new one, and document the experience. This requires IETF review. gStation overview - everything works fine - v4 only - dynamic

Re: [Captive-portals] Discovering captive portal API URL via DNS?

What about those resolvers that collapse CNAME responses, effectively eliding them? I assume that you are going to explicitly say that this has to be directed to the resolver provided in network configuration. If that resolver is outside the network or less tightly secured than DHCP/RAs, then

Re: [Captive-portals] Review of draft-ietf-capport-rfc7710bis

n a VLAN or bridge domain, then when a > network device—a DHCP client—that is connected to the VLAN or bridge > domain on an untrusted interface sends a DHCP request, the switching > device inserts information about the client's network location into the > packet header of that reques

Re: [Captive-portals] Call for adoption draft-ekwk-capport-rfc7710bis

On Fri, Jun 14, 2019, at 04:57, Warren Kumari wrote: > Can you please let the list know what your consensus assessment is [...]? My sincerest apologies for letting this drop. My remainder got eaten by a pet. I probably need a "does not operate any internal timers" warning printed somewhere.

[Captive-portals] Call for adoption draft-ekwk-capport-rfc7710bis

Erik and Warren have helpfully provided this draft that updates RFC 7710. Today we discussed this and there seemed to be general agreement to adopt. Please respond to this email before 2019-04-12 stating whether you think we should adopt or not. If not, please share your reasons when you

[Captive-portals] Agenda for next week

. ~~~ CAPPORT Working Group IETF 104 Prague 2019-03-27 11:20-13:20 Second Wednesday session, Karlin 3 Chairs: Erik Kline, Martin Thomson Materials: https://github.com/capport-wg/wg-materials/tree/master/ietf104 Agenda Administrivia 5 Chairs - Agenda bash Draft Status

[Captive-portals] Meeting at IETF 103

After not having any concrete agenda for a meeting, I cancelled our meeting. However, there was considerable interest in meeting from a few people. I've reserved the IAB room (Boromphimarn 5, on the third floor) at 11:20 on Thursday, the time we were originally scheduled. We need to be out by

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

Just to reiterate what Erik said here. Based on the discussion in London we have a better (but not perfect) understanding of what a signal would need to look like. But until we have a concrete proposal that fits the requirements, all we have is a liability. As a chair, I'm interested in us

Re: [Captive-portals] Fixing RFC 7710

On Sat, Mar 3, 2018 at 8:58 AM, Ólafur Guðmundsson wrote: > Fixing or make RFC7710 more useful ? Both, I hope. Thanks for your reply. >> Erik and I would like to propose a plan for that work. We would keep >> this to addressing the issues that we have identified thus

Re: [Captive-portals] I-D Action: draft-ietf-capport-api-00.txt

On Tue, Feb 6, 2018 at 12:07 PM, David Bird wrote: >> I'd say that the amount of information provided here is rich enough >> that you want to talk to a human. Very few networks permit sending of >> arbitrary packets to arbitrary hosts and the receipt of similar. The >> point

Re: [Captive-portals] I-D Action: draft-ietf-capport-api-00.txt

On Tue, Feb 6, 2018 at 8:41 AM, David Bird wrote: >> I have heard UE vendors express a strong desire to be able to know >> about status before they attempt to use the network. >> > > Hm, but (assuming you are using the provided network for DNS, CRL checks, > and the API itself),

Re: [Captive-portals] I-D Action: draft-ietf-capport-api-00.txt

On Tue, Feb 6, 2018 at 5:03 AM, David Bird wrote: > Thanks Darshak and Tommy, this is really helpful. Yes, thank you both. > Some comments: > > In 2. Workflow: Does it make sense to reorder 2) and 3)? It would seem > 'Enforcement' should come before determining status (of said

Re: [Captive-portals] API access and .well-known

On Fri, Jan 19, 2018 at 9:33 AM, Adam Roach wrote: > Sure, either in a 3xx response; or, if we're using Link: relations, those > URLs can vary based on the client. If you want to get fancy about it, you > can even have your DHCP server hand out different URLs in the RFC7710

Re: [Captive-portals] API access and .well-known

ticular. 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. > > > On 1/14/18 11:39 PM, Martin Thomson wrote: > > a. use .well-known and just provide better justification

[Captive-portals] API access and .well-known

(see also https://github.com/capport-wg/api/issues/2) Currently the API draft proposes use of .well-known for finding the API. Generally speaking, there's a trend toward avoiding use of .well-known except when either: * it is difficult to configure or provide a full URL, or * the .well-known

[Captive-portals] UE Identification

Thanks Kyle for the summary of the discussion. The chairs would like to focus your attention on the issue of User Equipment identification. The basic problem is that the enforcement point and API are two different entities. They might also need to talk about the UE with other entities (RADIUS

[Captive-portals] Capport at the hackathon

FYI, I've tentatively registered interest in capport work at the hackathon. For those interested in participating, I hope that you can join us. See https://www.ietf.org/registration/MeetingWiki/wiki/doku.php?id=100hackathon ___ Captive-portals mailing

Re: [Captive-portals] [adoption call] draft-larose-capport-architecture

I've created a repository for the architecture draft at https://github.com/capport-wg/architecture I'll send a separate email with the process I think we should use for GitHub. Kyle and David, you have been invited to the repository. If you need help setting the repository up, let me know (I

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

; * invent a new signal? something the nas is allowed to send to the ue, but > not icmp? > > > Gr., Vincent > > > > Van: Captive-portals [captive-portals-boun...@ietf.org] namens Tommy Pauly > [tpa...@apple.com] > Verzonden: donderdag 24

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

overt channel for protocol message exchange is an important > consideration, given an example scenario where user A subscribes to >location information for user B, then every time A gets a location >update, an (external) observer of the subscription notification may >kn

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

Hi David, Can you explain more about why you believe that a lower-layer protocol needs to be used? I remember a similar discussion about this about 10 years ago with GEOPRIV. Then it was asserted that DHCP was the only protocol that could deliver location information to user equipment. That

Re: [Captive-portals] Milestones changed for capport WG

As discussed, Erik and I have proposed new milestones. These aren't yet approved, but I've spoken to Adam about this. Also, the tool seems to have made a hash of the notification. The new milestones will be: Aug 2018 - Capture Portal Architecture Aug 2018 - API for Captive Portal Interaction

Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"

On 2 June 2017 at 22:47, Livingood, Jason wrote: > I’m merely confirming that others share the same use case specified by the > German Federal Office for Information Security. Yeah, I can agree that this is a very common desire. And I'm glad that it's the use case

Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"

On 1 June 2017 at 08:23, Livingood, Jason wrote: > In any case, this is very much in scope IMO – so agree with others here. With > the rise of IoT compromises the need for these sorts of notifications will > only rise and will be critical to maintaining the security

Re: [Captive-portals] Arguments against (any) Capport "API"

On 7 April 2017 at 22:08, David Bird wrote: > To be clear, Gmail hyperlinked boingo.com for me... but, the point is that > the UE/capport detection parsed and validated (checked the cert and cert > status) of the FQDN. It is not some URL with questionable formatting... I think

Re: [Captive-portals] Arguments against (any) Capport "API"

On 7 April 2017 at 10:44, David Bird wrote: > the more familiar "boingo.com" in the FQDN You mean boıngo.com ? Looks legit. On the larger subject, as a browser person, the real reason for sandboxing is - I believe - privacy. One basic security assumption for the web is

Re: [Captive-portals] Not good....

On 2 April 2017 at 17:27, Michael Richardson 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

[Captive-portals] Review of draft-wkumari-capport-icmp-unreach-01

(As a contributor only.) David, Warren, Looking at this draft, I think that there are a few fairly major changes that this could benefit from. # Extension payload The presence of the extension is sufficient signaling for this channel. If we accept that there will be a protocol for asking the

[Captive-portals] Minutes from capport session posted

Thanks to everyone for a productive discussion yesterday. The minutes are here: https://datatracker.ietf.org/doc/minutes-98-capport/ My gratitude to David Schinazi for his excellent minutes. ___ Captive-portals mailing list Captive-portals@ietf.org

[Captive-portals] Draft Agenda for IETF 98

I've just uploaded an agenda for the meeting. Those who are identified here, please get me your slides before the meeting starts (ideally before the 26th, for all except the last, which I don't expect to need a presentation). Plan on no more than 10 minutes of presenting so that we can have some

Re: [Captive-portals] Proposals to discover Provisioning Domains (& Captive Portals)

There's also this terrible idea from an age ago, which like 7710 uses DHCP: https://datatracker.ietf.org/doc/rfc5986/ Unlike 7710, it produces a name. On 13 March 2017 at 07:14, David Bird wrote: > HI Tommy, > > I agree, there is synergy, particularly as it relates to our

Re: [Captive-portals] FW: New Version Notification for draft-larose-capport-architecture-00.txt

On 10 March 2017 at 11:12, Dave Dolson wrote: > ‎I think a separate draft might be appropriate for the API. Yep. I wouldn't expect this doc to get sidetracked too much. > To take an initial stab at it, we think a GET to the ‎URI provides a JSON > document of information

Re: [Captive-portals] Capport project at the IETF 98 hackathon

Thanks for arranging this Kyle. I'll be floating around the hackathon, at least on Saturday and would be happy to lend a hand. On 3 March 2017 at 03:17, Kyle Larose wrote: > Hello everyone, > > I've put up some ideas for hackathon projects related to captive portal on >

[Captive-portals] Requests for time in Chicago

We have a meeting slot set for Chicago. Right now I have one subject to discuss. If you want some agenda time, let me know. ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Feedback requested: Charter text.

On 9 July 2015 at 07:16, Warren Kumari war...@kumari.net wrote: Here is what I currently have. LGTM. On 9 July 2015 at 08:46, Yoav Nir ynir.i...@gmail.com wrote: I would like the endpoint to be able to authenticate the captive portal (captor? MitM?). This is a fine secondary requirement; I

Re: [Captive-portals] Feedback requested: Charter text.

On 1 July 2015 at 06:13, Tero Kivinen kivi...@iki.fi wrote: Which means every time I go to the Helsinki Airport, I need to start browser, and try to access something so I can click I agree so I can get my emails downloading in the background. That may be a legal constraint. The network they