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

Erik Kline <> Thu, 14 May 2020 22:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B58673A0DF1; Thu, 14 May 2020 15:06:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DJGr_XjZjry3; Thu, 14 May 2020 15:06:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B8D6C3A0DC4; Thu, 14 May 2020 15:06:28 -0700 (PDT)
Received: by with SMTP id d26so331863otc.7; Thu, 14 May 2020 15:06:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=tAo9iENvnzUuAfElzYVtQdqmTTCaPgdet1laWcQkNTQ=; b=rrVbvgu/MLSSI3KMKBAFMKCwMCBDYA/mygdlGj2hr3BpIZMdDS5XwIVQYMzb27Fp+h +LO8SgcMrngBODXo97FBUdzXc6qnMZM88EAvnvoLJqup7EtXnDgEGMvnxA3GiEeYJtI6 OgpAGH+WJBIYD6HM4XtNJQpQPgJs3Qg/srL+omHLjzLqaDd2snXOUb77M7UZE0HPHOK5 Y0amTDLIzPb6TFF+vhksjIgAyb63Z4fex0NZMHuNqSjs9OH4y6TN+aJDNZ5NXH0BM8OB gjmlwYrVhzCS0VGJz7OvHNtRSoBfiGRfhmd8AzvlCKMIcGQiYQfQUKnbm1ddShPknKlb z0OA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=tAo9iENvnzUuAfElzYVtQdqmTTCaPgdet1laWcQkNTQ=; b=f+pWiVE2EmnbHEpRljeB0MkxDBamDBhd7vsO3drVG0oCG/upxidcqZm4enHEHApaIJ tCVbL3eiBF8XvumW5OWSgXjQP8mIbB4jjoMlhWM/JRU4T5cHss2MDe+qzDWJOqdtFQkz HEg1nBsbn4x2aOPWnAkp6BOQYkVL6/juPRMsaHEEwF01zibvkoYotwXkzXjvu0G5d1RH vE9pAaGqmWOcn6s9vL3cAJMZ24Znrx1EQymbsfZYqlbYIU37HGb38I/yzgjQ2gWroZb1 vXtPqs1AtdeMLENNr7Va9zIR+N7C7cmRc9IbXdFGhDzSvsHFkRQqpZLd1D/XwlhHsWWA lrrg==
X-Gm-Message-State: AOAM532oH4yPpcqOyr5RHFLnO5BZqN7lAa3kn6sMCYyEj/3PD5pu9SUx ZoZo+JLHe5/6cYIaCMgDBobvDWcPG18vfgJihSM=
X-Google-Smtp-Source: ABdhPJzDGprsPc6CqVLw745s495alZ9lII1Lgu/oIBjlYcvTiT1DDZLA4HEf5tLih+3kJICBOU1knP77oWwW0xeMM4g=
X-Received: by 2002:a9d:7988:: with SMTP id h8mr40173otm.191.1589493987729; Thu, 14 May 2020 15:06:27 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Erik Kline <>
Date: Thu, 14 May 2020 15:06:16 -0700
Message-ID: <>
To: Tim Chown <>
Cc:,, captive-portals <>,
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Captive-portals] Opsdir last call review of draft-ietf-capport-rfc7710bis-04
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of issues related to captive portals <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 May 2020 22:06:39 -0000


Thanks for taking the time to read and comment.  Replies inline below
and changes made at .

On Thu, May 14, 2020 at 7:30 AM Tim Chown via Datatracker
<> wrote:
> Reviewer: Tim Chown
> Review result: Has Nits
> General comments:
> The security considerations (Section 5) talk of potential spoofed DHCP or RA
> captive portal option messages; equally an attacker could use a rogue RA or
> DHCP message to convey (for example) a bad DNS server option, which could
> direct a client to a bad captive portal endpoint.  So the document should
> probably state that there is an assumption of RFC 6105 (RA Guard) or equivalent
> measures being in place; whether such a capability is realistic in a coffee
> shop scenario is another question.

As part of feedback from a security review we've added text and
references to RA Guard and DHCP Shield.

> I also wonder how commonly multiple provisioning domain scenarios will arise
> for school network access, where a client may see multiple captive portals. I
> note that draft-ietf-intarea-provisioning-domains-04 seems to have expired, so
> I’m not clear whether that initiative has been dropped; it seemed to have good
> potential.

The PVD doc is in the editors' queue.

> Nits:
> Abstract:
> * Clarify that the document describes and DHCPv4 and DHCPv6 option.


> * Remove the parantheses from the RA option text; these are “equal” options.


> * Perhaps rewrite “it is designed to be used in larger solutions“ to “it is
> designed to be one component of a standardised approach for hosts to interact
> with such portals.“

sounds good; done

> * And perhaps rewrite “The method of authenticating to, and interacting with
> the captive portal is out of scope of this document.” to “While this document
> defines how the network operator may convey the captive portal API endpoint to
> hosts, the specific methods of authenticating to, and interacting with the
> captive portal are out of scope of this document.”

also good; done

> Section 1:
> * This cites RFC 2131 for DHCP; I’d suggest citing RFC 3315 and RFC 8415 and
> emphasising that there are options for DHCP for IPv4 and DHCPv6.

changed to 2131 for DHCPv4 and 8415 for DHCPv6 (3315 was obsoleted by 8415).

> * It also says “how to contact an API”; probably better to say “the API
> endpoint that the host can contact” as the “how” is out of scope for this
> document.


> Section 2:
> “Implement the interception” -> “implement interception”


> Section 3:
> Second paragraph, is that a “should be logged” or “SHOULD be logged”?

No strong feelings either way, since it's a device behaviour that no
user will probably ever see.  Went with SHOULD.