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

Barry Leiba <> Mon, 27 April 2020 14:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 806DF3A0B84; Mon, 27 Apr 2020 07:28:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.219
X-Spam-Status: No, score=-2.219 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, RCVD_IN_MSPIKE_H2=-0.82, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IstENqw7JCZF; Mon, 27 Apr 2020 07:28:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1774F3A0B92; Mon, 27 Apr 2020 07:28:13 -0700 (PDT)
Received: by with SMTP id i19so19014584ioh.12; Mon, 27 Apr 2020 07:28:13 -0700 (PDT)
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=g5xiXAFtg7xb/XfA2oS822U8fUnSJQDma0aXbb98hIk=; b=ei2N+npU4B4rQPkodRrSc6tfQIjwpAzgRCI+rkB40Xtq5pZzROKJ2R39OVc0/ZmiHl rGIeroUfYoZyCpCIUfc8uJPs9UW4h0Q9uN/+GEPofBL6zY3H+WLVblM3elZDfKO/GBQl wwd7/lPAUcRDV0YakFxFH/yQaP6mvdV4vzgcf1xA7ibio63u+fo6Oge0BNkfRUe8kqYx eThDYA7JFpsw6nwNb/3uo+XFfqfKZ8lEf8VnRkxQpPXPs6JyY5y33R/tL26j3XofF97p TS3qdS1XrCc88+7JxhAekdKHpY67IumnXV+7K2zNa4+M7xx+VBtBxUmmwOWus707tJB1 te4w==
X-Gm-Message-State: AGi0PuYosfPwOiUzwiORskGSvZQbd+aEIau7bhQP6HytstRflaF7T11Z 1U25ZLlNyfWKwsS2UfURh9q9lqTuYcxnqaGt+qc=
X-Google-Smtp-Source: APiQypK/r4jqiRcIfc8d667eHE5Oemr6Yecxs+Tyx71lC88gCvUg4Fap1X+kpEHhe5kPqqVh99C+0DdoZydYJzdXpZ0=
X-Received: by 2002:a05:6638:22a:: with SMTP id f10mr20983190jaq.59.1587997692960; Mon, 27 Apr 2020 07:28:12 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Barry Leiba <>
Date: Mon, 27 Apr 2020 10:28:02 -0400
Message-ID: <>
To: Erik Kline <>
Cc: "" <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Captive-portals] AD review of draft-ietf-capport-rfc7710bis-03
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: Mon, 27 Apr 2020 14:28:16 -0000

> Thanks for the prompt review.

You're welcome, and thanks for the prompt reply!

I've eliminated the resolved items below, and leave the ones for which
issues are open, for my own quick reference.  I think they should be
easy to resolve, and then we can get a revised I-D and start last


>> 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.
> Filed issue #17.

>>    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?
> Filed issue #18.

>>    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.
> Filed issue: #19.

>> — 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.
> Filed issue: #20.

>> — Section 3 —
>>    Specifically,
>>    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.
> Filed issue: #21.

>> — 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.
> Filed issue: #22.