Captive-Portal Identification in DHCP and Router Advertisements (RAs)
draft-ietf-capport-rfc7710bis-11

[Ballot comment]
Thank you for the work put into this document. The document is easy to read. I really like the signaling of 'no captive portal'.

Please find below one non-blocking COMMENT (but you know the story) and 2 nits.

Please also address all Suresh's comments in his IoT review:
https://datatracker.ietf.org/doc/review-ietf-capport-rfc7710bis-07-iotdir-telechat-krishnan-2020-06-11/

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 2.2 ==
In "should not be provisioned", I would suggest to use the normative "SHOULD".
 
== NITS ==

-- Abstract --
Not all users of a captive portal are 'customers', they can be guests, students, employees, ... suggest to use 'users' (and even in the world of IoT).

-- Section 2 --
Authors, being English natives, are probably correct but " should not be provisioned via IPv6 DHCP nor IPv6 RA options." looks weird to m; why not " should be provisioned via neither IPv6 DHCP nor IPv6 RA
options." ?

[Ballot discuss]
IANA Section:

As this document is obsoleting RFC 7710 is the document that registered the options for DHCPv6 and RA. Why isn't this document updating the registrations to ensure that IANA has the current document as being owner of the codepoints?

In addition when it comes to BOOTP options code 160. What you have in this document appear to potentially lead to another future assignment end up in trouble? Wouldn't reserved be better status for this codepoint?

[Ballot comment]
Just one minor nit:

I would have preferred if the packet diagram for "IPv4 DHCP Option" looked a lot more like the one in section 2.3 for "IPv6 RA", but perhaps there is a reason why the v4 DHCP represents the URL as two separate fields.

Regards,
Rob

[Ballot comment]
Thanks for this updated document.

** I support Ben's Discuss position

** (Editorially) Is there a reason that this draft doesn’t reference draft-ietf-capport-architecture-08 and use the notional architecture and terminology it defines?  It would be clearer if it did.

** Section 2.2 and 2.3.  Per “The maximum length of the URI that can be carried in IPv4 DHCP is 255 bytes, so URIs longer than 255 bytes should not be provisioned via IPv6 DHCP options.”
-- should this be a normative SHOULD?

-- recommend stating when this length can be ignored (e.g., IPv6 only environment)

** Section 5.  Per “In the absence of security measures like RA Guard ([RFC6105], [RFC7113]) or DHCP Shield [RFC7610] …”, are these recommended for operators to use in the Captive Portal System?

[Ballot discuss]
There seems to be an internal inconsistency about whether, when the API
URL is available in a given network via multiple mechanisms, the URLs
provided by the different mechanisms must be "identical" (Section 3) or
merely "equivalent" (Section 2).  I think we need to be consistent in
the requirement, as it is possible for URLs to be equivalent but not
identical just by virtue of mundane encoding tricks, even without
getting to the question of semantic equivalence of pointed-to resources.

[Ballot comment]
There is perhaps something to be said about how us moving from DHCP code
point 160 to 114 is in effect making a mockery of the registration
policy of IETF Review, when it is in practice First Come First Served as
the squatter wins.  I think we should consider making a stronger
statement about squatting being bad (though if I understand correctly
for this case, the registration policy in this range has changed since
the creation of the registry, so maybe there are extenuating
circumstances).  [N.B. that this is the COMMENT section, not the DISCUSS section.]

I also think we should be more explicit about the potential gap in the
chain of custody for getting the user to the captive portal server to
fulfil the Captive Portal Conditions.  In order for the user to trust
that they're in the right place (even as they may be, e.g., entering
payment information), they rely on the network to only provide
legitimate versions of the signals defined in this document, blocking
sppofed ones.  At present, this seems to involve a component of "blind
faith", and though we do discuss the technical capabilities of the
attacker we don't go into how this affects the "trust chain" from
initial network attachment.  (More discussion in the section-by-section
comments.)

Abstract

  In many environments offering short-term or temporary Internet access
  (such as coffee shops), it is common to start new connections in a
  captive portal mode.  This highly restricts what the customer can do
  until the customer has authenticated.

side note: I don't remember seeing "customer" used in the architecture or API
document.

  This document describes a DHCPv4 and DHCPv6 option and a Router
  Advertisement (RA) option to inform clients that they are behind some
  sort of captive-portal enforcement device, and that they will need to
  authenticate to get Internet access.  It is not a full solution to

In the terminology of the architecture doc, the client will "satisfy the
Captive Portal Conditions" (as opposed to "authenticate").  Is there a
reason to use divergent terminology?

  hosts to interact with such portals.  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.

["authenticating" again]

Section 2

  information faster and more reliably.  Note that, for the foreseeable
  future, captive portals will still need to implement interception
  techniques to serve legacy clients, and clients will need to perform
  probing to detect captive portals.

side note: I'd consider reiterating the "faster and more reliably" here
to incentivize adoption of the new mechanisms even though the legacy
ones are still needed.

  to reduce the chance of operational problems.  The maximum length of
  the URI that can be carried in IPv4 DHCP is 255 bytes, so URIs longer
  than 255 bytes should not be provisioned via IPv6 DHCP nor IPv6 RA
  options.

I'm not sure whether this text is conveying the intended meaning -- the
current version sounds like it's saying that because IPv4 DHCP is
limited, we need an entirely new mechanism to convey longer URIs,
leaving the reader to guess that this is out of some desire to keep the
existing mechanisms at feature parity.  Is the intent more along the
lines of "URIs longer than 255 bytes should not be used at all, so that
it's easier to present a consistent view across the three different
provisioning mechanisms defined in this document"?

  In all variants of this option, the URI MUST be that of the captive
  portal API endpoint, conforming to the recommendations for such URIs
  [draft-ietf-capport-api].

I'm sympathetic to the intdir reviewer's comments about the
"recommendations" from draft-ietf-capport-api not being laid out
particularly clearly.

  "user-portal-url" API key.  When performing such content negotiation
  ([RFC7231] Section 3.4), implementors of captive portals need to keep
  in mind that such responses might be cached, and therefore SHOULD
  include an appropriate Vary header field ([RFC7231] Section 7.1.4) or
  mark them explicitly uncacheable (for example, using Cache-Control:
  no-store [RFC7234] Section 5.2.2.3).

The API doc says "'private' or a more restrictive value"; do we want to
be diverging from that recommendation?

  The URI SHOULD NOT contain an IP address literal.  Exceptions to this
  might include networks with only one operational IP address family
  where DNS is either not available or not fully functional until the
  captive portal has been satisfied.

If we don't heed the SHOULD then we end up trying to speak TLS with only
an IP address for the server identifier, so we want an iPAddress
certificate, which adds complications of its own.  (Perhaps most of the
discussion of these complications should be in the API document, and
I'm pretty amenable to arguments that they are out of scope for
*extended* discussion here.  I'd still like to see a brief mention that
this scenario has some complications.)

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

It's not entirely clear that the BCP 14 "MAY" is adding much here.

Section 2.1

  o  Len: The length (one octet), in octets of the URI.

nit: comma after "in octets" as well as before.

Section 2.2

  The maximum length of the URI that can be carried in IPv4 DHCP is 255
  bytes, so URIs longer than 255 bytes should not be provisioned via
  IPv6 DHCP options.

[similar comment as above]

Section 2.3

  URI  The URI for the captive portal API endpoint to which the user
      should connect.  This MUST be padded with NULL (0x00) to make the

nit: in the context of (ASCII) characters, the octet with all bits zero
is usually written a "NUL", not "NULL".

  Note that the URI parameter is not guaranteed to be null terminated.

(ditto)

  The maximum length of the URI that can be carried in IPv4 DHCP is 255
  bytes, so URIs longer than 255 bytes should not be provisioned via
  IPv6 RA options.

[similar comment as above]

Section 4

Shouldn't we also request the reference be updated for the DHCPv6 option
code and RA option type?

Section 4.1

(I assume the question of "capport:unrestricted" vs.
"capport-unrestricted" was discussed already and don't wish to rehash it
again.)

Section 4.2

If this document is just de-registering the former capport use of code
160, what process is going to mark it as used for the polycom thing?

Section 5

RFC 7227 (BCP 187) "strongly advises" authors of documents defining new
DHCP options to define validation measures for recipients of such
options.  I don't see any such validation measures specified in this
document; why is it okay to diverge from the BCP recommendation?

  By removing or reducing the need for captive portals to perform MITM
  hijacking, this mechanism improves security by making the portal and
  its actions visible, rather than hidden, and reduces the likelihood
  that users will disable useful security safeguards like DNSSEC
  validation, VPNs, etc.  In addition, because the system knows that it

Perhaps we should say why the users would be disabling those mechanisms
in the absence of this mechanism?

  credentials, etc.  By handing out a URI which is protected with TLS,
  the captive portal operator can attempt to reassure the user that the
  captive portal is not malicious.

It's not entirely clear how successful such attempts will be, though, as
the trustworthiness of the captive-portal provisioning signal depends on
the network operator implementing (e.g.) RA-guard and DHCP sheild to
prevent the client from receiving signals not authorized by the network
operator, and the client does not in general know whether or not that is
the case.  (While we do talk about those mechanisms in the following
paragraph, we don't really talk about how the user can('t) know for sure
that those mechanisms are in place.)

  However, as the operating systems and application that make use of
  this information know that they are connecting to a captive-portal
  device (as opposed to intercepted connections) they can render the

I think we want to clarify in the parenthetical that for the case of
intercepted connections the OS/application may not know that they are
connecting to a captive-portal or hostile device.

Appendix B

  2.  Clarify that the option URI SHOULD be that of the captive portal
      API endpoint.

I couldn't find where this is done -- I just see descriptive text that
the URI is the URI of the API endpoint.

[Ballot comment]
Nice work.  A couple of minor things:

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"?

In Sections 2.1 and 2.2, the lists are bulleted and the names being described are delimited by colons.  I suggest the same be done for 2.3.

> Thanks IANA!

RFC8126 should've required this of all documents.

[Ballot comment]
Thank you for the work put into this document. The document is easy to read. I really like the signaling of 'no captive portal'.

Please find below one non-blocking COMMENT (but you know the story) and 2 nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 2.2 ==
In "should not be provisioned", I would suggest to use the normative "SHOULD".
 
== NITS ==

-- Abstract --
Not all users of a captive portal are 'customers', they can be guests, students, employees, ... suggest to use 'users' (and even in the world of IoT).

-- Section 2 --
Authors, being English natives, are probably correct but " should not be provisioned via IPv6 DHCP nor IPv6 RA options." looks weird to m; why not " should be provisioned via neither IPv6 DHCP nor IPv6 RA
options." ?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-capport-rfc7710bis-04. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

We understand that, upon approval of this document, there are two actions which we must complete.

First, Section 4.1 states that "This document registers a new entry under the IETF URN Sub-namespace defined in [RFC3553]" however, the registry at https://www.iana.org/assignments/params defined by RFC 3553 is actually the IETF URN Sub-namespace for Registered Protocol Parameter Identifiers registry. In addition, neither registry's columns match the columns named in the registration.

IANA Question --> The authors provide the following registration information in Section 4.1 of the draft:

Registry name: Captive Portal Unrestricted Identifier
URN: urn:ietf:params:capport:unrestricted
Specification: RFC TBD (this document)
Repository: RFC TBD (this document)
Index value: Only one value is defined (see URN above). No hierarchy is defined and therefore no sub-namespace registrations are possible.

The IETF URN Sub-namespaces registry records the following information:

Sub-namespace
Reference
IANA Registry Reference

And the IETF URN Sub-namespace for Registered Protocol Parameter Identifiers provide the following information:

Registered Parameter Identifier
Reference
IANA Registry Reference

Is the registration information in Section 4.1 of the draft for a different registry; or, is the information provided different from the requirements for the IETF URN Sub-namespace for Registered Protocol Parameter Identifiers registry?

Second, two changes are to be made in the BOOTP Vendor Extensions and DHCP Options registry on the Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters registry page located at:

https://www.iana.org/assignments/bootp-dhcp-parameters/

The current registration:

Tag: 114
Name: URL
Data Length: N
Meaning: URL
Reference: [RFC3679]

is to be changed to:

Tag: 114
Name: DHCP Captive-Portal
Data Length: N
Meaning: DHCP Captive-Portal
Reference: [ RFC-to-be ]

And, the current registration:

Tag: 160
Name: DHCP Captive-Portal
Data Length: N
Meaning: DHCP Captive-Portal
Reference: [RFC7710]

is to be changed to:

Tag: 160
Name: REMOVED/Unassigned
Data Length:
Meaning:
Reference: [ RFC-to-be ][RFC7710]

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-05-13):

From: The IESG
To: IETF-Announce
CC: Martin Thomson , mt@lowentropy.net, captive-portals@ietf.org, capport-chairs@ietf.org, draft-ietf-capport-rfc7710bis@ietf.org, barryleiba@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Captive-Portal Identification in DHCP / RA) to Proposed Standard


The IESG has received a request from the Captive Portal Interaction WG
(capport) to consider the following document: - 'Captive-Portal
Identification in DHCP / RA'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-05-13. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  In many environments offering short-term or temporary Internet access
  (such as coffee shops), it is common to start new connections in a
  captive portal mode.  This highly restricts what the customer can do
  until the customer has authenticated.

  This document describes a DHCP option (and a Router Advertisement
  (RA) extension) to inform clients that they are behind some sort of
  captive-portal enforcement device, and that they will need to
  authenticate to get Internet access.  It is not a full solution to
  address all of the issues that clients may have with captive portals;
  it is designed to be used in larger solutions.  The method of
  authenticating to, and interacting with the captive portal is out of
  scope of this document.

  This document replaces RFC 7710.  RFC 7710 used DHCP code point 160.
  Due to a conflict, this document specifies 114.

  [ This document is being collaborated on in Github at:
  https://github.com/capport-wg/7710bis.  The most recent version of
  the document, open issues, etc should all be available here.  The
  authors (gratefully) accept pull requests.  Text in square brackets
  will be removed before publication. ]




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-capport-rfc7710bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-capport-rfc7710bis/ballot/


No IPR declarations have been submitted directly on this I-D.

Publication request writeup for draft-ietf-capport-rfc7710bis-03

Intended status: Proposed Standard
Working group: capport
Document shepherd: Martin Thomson

Technical Summary:

This document defines DHCP and RA options that allow a network to indicate the
location of a captive portal.

This version of the document replaces RFC 7710 with clarifications about what
the "location of a captive portal" means, a means for a network to indicate the
absence of a captive portal, and a new DHCP code point that we believe to be
uncontested.

Working Group Summary:

This document was fairly uncontroversial in discussions.

Document Quality:

The document is a considerable refinement over the previous version, which left
many aspects undefined.  Experiments (and multiple implementations) revealed
that the previous version was undeployable due to the DHCP option conflict.  We
have several implementations and have validated this.  Those implementations are
prototype quality, but implemented in major operating system stacks, so we are
confident that this is implementable.

Personnel:

Martin Thomson is document shepherd.  Barry Leiba is the responsible Area Director.

Important information:

This document represents the consensus of the capport WG.  There were no
significant problems with this particular document.

It is the understanding of the shepherd that extensive collaboration was
undertaken by authors with IANA, DHC, and the DHCP registry experts in reaching
the conclusions in the draft.

IPR disclosures from authors have been checked.  No IPR disclosures have been
made with reference to this work.

IANA considerations were checked and cleaned up.  Entries are registered, but no
new registries created.

Validation is limited to nits check (which only has false positives).

Publication request writeup for draft-ietf-capport-rfc7710bis-03

Intended status: Proposed Standard
Working group: capport
Document shepherd: Martin Thomson

Technical Summary:

This document defines DHCP and RA options that allow a network to indicate the
location of a captive portal.

This version of the document replaces RFC 7710 with clarifications about what
the "location of a captive portal" means, a means for a network to indicate the
absence of a captive portal, and a new DHCP code point that we believe to be
uncontested.

Working Group Summary:

This document was fairly uncontroversial in discussions.

Document Quality:

The document is a considerable refinement over the previous version, which left
many aspects undefined.  Experiments (and multiple implementations) revealed
that the previous version was undeployable due to the DHCP option conflict.  We
have several implementations and have validated this.  Those implementations are
prototype quality, but implemented in major operating system stacks, so we are
confident that this is implementable.

Personnel:

Martin Thomson is document shepherd.  Barry Leiba is the responsible Area Director.

Important information:

This document represents the consensus of the capport WG.  There were no
significant problems with this particular document.

It is the understanding of the shepherd that extensive collaboration was
undertaken by authors with IANA, DHC, and the DHCP registry experts in reaching
the conclusions in the draft.

IPR disclosures from authors have been checked.  No IPR disclosures have been
made with reference to this work.

IANA considerations were checked and cleaned up.  Entries are registered, but no
new registries created.

Validation is limited to nits check (which only has false positives).