[Captive-portals] AD review of draft-ietf-capport-rfc7710bis-03

Barry Leiba <barryleiba@computer.org> Fri, 24 April 2020 04:18 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: captive-portals@ietfa.amsl.com
Delivered-To: captive-portals@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E2F993A0909; Thu, 23 Apr 2020 21:18:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.218
X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.82, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 73e3fggFWrGm; Thu, 23 Apr 2020 21:18:03 -0700 (PDT)
Received: from mail-il1-f173.google.com (mail-il1-f173.google.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 133263A0900; Thu, 23 Apr 2020 21:18:00 -0700 (PDT)
Received: by mail-il1-f173.google.com with SMTP id c16so8056514ilr.3; Thu, 23 Apr 2020 21:18:00 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=dzZau+MmhgAIW+dEv/tcNBmUMgIxiDFyegDW3VbUM7c=; b=UHihGKrnoDRBQsJm5rgVceH3jYPRRD8ZD4ByLP+b1oG2tv0VRh2LkjADgSRnXkvtep BgpWZDPr0/ZcDdpFerj4HGqpvzNPpxR9JpE8okyNjW5LlbjmZ/JCt9ff4tHCaQ9P7a/f +q0hrrdAEbVI2AJcoAPllY2S82f0qxM5gtxOQN6Z8K3ROSJG/Z0Hk7dbvFOdnTO6glF+ +ljhAo+6A809uDPzpCGvI5sjUSrxKCTvWIQ0rgEw87UIwXYSrWZixUnZRxggglABfnrj Y1EEPemFovI8dvBbWMEzbQHreLbX9Is3ftjsgqKEtBZrQ/CGGiFKbuFx3nMJVgA/pVhL fSkA==
X-Gm-Message-State: AGi0PuZaj49bcQP/EgYp51VO4hHnNhyKDM1YYRGMAXQc/U75BJFK0tHY HHAyhKrllMJWAaQ3D2wU5t5Js3is1Z8fboX58KfCZofR
X-Google-Smtp-Source: APiQypJ/laiHdBxd7HILA65JxvN3jY3uANIl8wyWimiGVEsCe5CLyh++irrPFiyxersylaK4PuUBSFzGungCeKgzFSc=
X-Received: by 2002:a92:4b10:: with SMTP id m16mr6966562ilg.107.1587701878827; Thu, 23 Apr 2020 21:17:58 -0700 (PDT)
MIME-Version: 1.0
From: Barry Leiba <barryleiba@computer.org>
Date: Fri, 24 Apr 2020 00:17:48 -0400
Message-ID: <CALaySJ+tmuU_DZU6ZvC4RsnuRJAVfLgYyw_=RYbA6XBcgvgKJQ@mail.gmail.com>
To: "draft-ietf-capport-rfc7710bis.all@ietf.org" <draft-ietf-capport-rfc7710bis.all@ietf.org>
Cc: "captive-portals@ietf.org" <captive-portals@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007f30e705a401a6cc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/0QJTEioaOfI9_1S4i5_ML4X0n8U>
Subject: [Captive-portals] AD review of draft-ietf-capport-rfc7710bis-03
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of issues related to captive portals <captive-portals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/captive-portals/>
List-Post: <mailto:captive-portals@ietf.org>
List-Help: <mailto:captive-portals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Apr 2020 04:18:05 -0000

Good work on this, folks: a nice improvement on 7710, and let’s hope for
wider deployment.  Some comments below; I think we should have a quick
revised I-D before we go to last call, mostly because of the comment about
the diagrams in Sections 2.1 and 2.2, though most of the comments are

— Section 1.1 —
Please use the new BCP 14 boilerplate from RFC 8174.

— Section 2 —

   negotiation ([RFC7231] Section 3.4), captive portals implementors

Make it “captive portal implementors” (or “implementors of captive

It looks like the two consecutive paragraphs that both begin with “A
captive portal” have some duplication with regard to the absence of
“Accept” headers; please check that and adjust if you agree that some
information can be merged or removed.

   The URI SHOULD NOT contain an IP address literal.

Why not, and how does it maintain interoperability to have this as SHOULD
NOT, rather than MUST NOT?

   Networks with no captive portals MAY explicitly indicate this
   condition by using this option with the IANA-assigned URI for this
   purpose (see Section 4.1.1).  Clients observing the URI value
   "urn:ietf:params:capport-unrestricted" MAY forego time-consuming
   forms of captive portal detection.

Two things here:  I don’t see that the forward reference to 4.1.1 adds
anything, as the only thing that section does that’s useful here is to
repeat the URI that you’re already including.  And why
“capport-unrestricted” rather than “capport:unrestricted”?  The latter
would seem more in line with how “ietf:param” URNs are generally done.

— Sections 2.1 and 2.2 —
Why aren’t the diagrams for the two in the same format?  And neither
explicitly says what the length of the “len” field is.  In the v4 version,
one has to guess that it’s the same size as the “code” field, 1 byte.  In
the v6 version, one can look at the diagram.  I suggest making the diagrams
the same format (calibrated with bit/byte markings) and explicitly
specifying in the text the size of the “len” field.

— Section 3 —

   URIs learned via any of the options in Section 2 should take
   precedence over any URI learned via some other mechanism

Given the MUST that comes before this, I think the word “should” ought to
be removed, to avoid any confusion.

— Section 5 —
Purely a judgment thing here, so do what you hink is best: it seems to me
that the Security Considerations in 7710 rather buried the lede.  The
bottom line is that by removing the MitM interception, this mechanism
improves security by making the portal and its actions visible, rather than
hidden, and that vulnerabilities that exist here also existed before and
are now lessened.  I would say something like that up front, in a new first
paragraph, and then continue with the existing text as is.

But, again, as you judge best; this is just a comment.