idnits 2.17.00 (12 Aug 2021) /tmp/idnits2421/draft-wkumari-capport-icmp-unreach-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (April 29, 2015) is 2579 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC0792' is defined on line 212, but no explicit reference was found in the text == Unused Reference: 'RFC1122' is defined on line 215, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sidr-iana-objects' is defined on line 227, but no explicit reference was found in the text == Outdated reference: draft-ietf-sidr-iana-objects has been published as RFC 6491 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 template D. Bird 3 Internet-Draft W. Kumari 4 Intended status: Informational Google 5 Expires: October 31, 2015 April 29, 2015 7 Captive Portal ICMP Destination Unreachable 8 draft-wkumari-capport-icmp-unreach-00 10 Abstract 12 This document defines a multi-part ICMP extension to signal that a 13 user's device is behind a Captive Portal. 15 [ Editor note: The IETF is currently discussing improvements in 16 captive portal interactions and user experience improvements. See: 17 https://www.ietf.org/mailman/listinfo/captive-portals ] 19 [RFC Editor: Please remove this before publication. This document is 20 being stored in github at https://github.com/wkumari/draft-wkumari- 21 capport-icmp-unreach . Authors gratefully accept pull requests, and 22 keep the latest (edit buffer) versions there, so commenters can 23 follow along at home.] 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 31, 2015. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 61 2. ICMP Dest Unreachable Captive Portal Object . . . . . . . . . 3 62 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 65 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 67 6.2. Informative References . . . . . . . . . . . . . . . . . 5 68 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 5 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 Captive Portals work by blocking (or redirecting) communications 74 outside of a "walled garden" until the user has authenticated and / 75 or acknowledged an Acceptable Use Policy (AUP). Depending on the 76 captive portal implementation, connections other than HTTP will 77 either timeout (packets dropped) or meet with a different, 78 inaccurate, error condition (like a TCP reset or ICMP Destination 79 Unreachable with existing codes). 81 A current option for captive portal networks is to reject traffic not 82 in the walled garden returning the Destination Unreachable either 83 Host or Network Administratively Prohibited. However, these codes 84 are typically permanent policies and do not specifically indicate a 85 captive portal is in use. 87 This document defines an extension object that can be appended to 88 selected multi-part ICMP messages to inform the user that they are 89 behind a captive portal. This informs the user after they have 90 attempted an initial connection and is generated by the Captive 91 Portal NAS itself. 93 [ Editor note: This is complementary, but solves a different problem 94 to: https://tools.ietf.org/html/draft-wkumari-dhc-capport-12 - 95 wkumari-dhc-capport provides information from a DHCP server (and so 96 doesn't need any changes to deployed CPs, and provides information 97 *before* the client attempts a connection. It does not, however, 98 have a way of noting that an existing connection has been 99 interrupted.] 101 1.1. Requirements notation 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC2119]. 107 2. ICMP Dest Unreachable Captive Portal Object 109 This document defines an extension object that can be appended to 110 selected multi-part ICMP messages ([RFC4884]). This extension 111 permits Captive Portal (CP) NAS devices to inform user devices that 112 their connection has been blocked by the Captive Portal NAS, and, 113 optionally, how to contact the Captive Portal to satisfy it. 115 The Dest Unreachable Captive Portal Object can be appended to the 116 ICMP Destination Unreachable messages. Figure 1 depicts the Dest 117 Unreachable Captive Portal Object. It must be preceded by an ICMP 118 Extension Structure Header and an ICMP Object Header. Both are 119 defined in [RFC4884]. 121 0 1 2 3 122 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 |W| Reserved | Validity (seconds) | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Captive Portal URL ~ 127 ~ (optional) | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 W - 1 bit Warning. Indicates that the Validity refers to when the 131 service will be interrupted. Note that the "offending" traffic 132 was forwarded, not dropped. 134 Validity - 24 bits Time, in seconds, that this result should be 135 considered valid (and the OS should not attempt to access the same 136 resource in the meantime). 138 Captive Portal URL - Variable The optional URL of the Captive 139 Portal. This allows Captive Portal detection software running on 140 the user's device to locate and connect to the captive portal to 141 improve the user experience. The length of the URL is calculated 142 from the ICMP Extension Object header Length minue the ICMP 143 Extension Object and Captive Portal Object header lengths, which 144 is zero when no URL is provided. 146 Editor note / questions. We are trying to get some feedback on A: 147 this general idea and B: this implementation. 149 Some open questions. 151 W bit or C-Type We have currently specified a single bit (W) to 152 indicate that the remaining lease time is running low, and the the 153 connection will be interrupted sometime "soon". We could, 154 instead, use a differnt C-Type. I think a bit is cleaner (and we 155 have reserved 7 bits for future flags), but could be convinced 156 (or, better yet, bribed) I'm wrong. Or that the whole "warning" 157 idea is a bad one... 159 Legacy interaction If we *do* return e.g ICMP Destination 160 Unreachable, Communication Administratively Prohibited to a 161 "legacy" (non-Dest Unreachable Captive Portal Object aware) client 162 with the 'W' bit set, what happens? In the testing I did, nothing 163 bad seemed to happen, but I *could* see that some hosts may stop 164 sending to that address, or... 166 General concept Is this idea useful? 168 3. IANA Considerations 170 The IANA is requested to assign a Class-Num identifier for the Dest 171 Unreachable Captive Portal Object from the ICMP Extension Object 172 Classes and Class Sub-types registry. 174 The IANA is also requested to form and administer the corresponding 175 class sub-type (C-Type) space, as follows: 177 Dest Unreachable Captive Portal Sub-types: 179 0 Reserved. 181 1 This message format. 183 0x02-0xF6 Available for assignment 185 0xF7-0xFF Reserved for private use 187 C-Type values are assignable on a first-come-first-serve (FCFS) 188 basis. 190 [ Editor note: Currently we are not using the C-Type for anything, 191 but I filled this in anyway. Probably we would overload it at a 192 version identifier type thing, but it could also allow further 193 extension, for example, a pointer to a status page. ] 195 4. Security Considerations 197 The obvious security consideration is how to confirm that the 198 received ICMP Message actually came from a Captive Portal, and was 199 not generated from a passive observer on the network (to force the 200 user to connect to a malicious device.). 202 5. Acknowledgements 204 The authors wish to thank the authors of RFC4950 (especially Ron 205 Bonica ) - I stole much of his text when writing the extension 206 definition. 208 6. References 210 6.1. Normative References 212 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 213 RFC 792, September 1981. 215 [RFC1122] Braden, R., "Requirements for Internet Hosts - 216 Communication Layers", STD 3, RFC 1122, October 1989. 218 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 219 Requirement Levels", BCP 14, RFC 2119, March 1997. 221 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 222 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 223 April 2007. 225 6.2. Informative References 227 [I-D.ietf-sidr-iana-objects] 228 Manderson, T., Vegoda, L., and S. Kent, "RPKI Objects 229 issued by IANA", draft-ietf-sidr-iana-objects-03 (work in 230 progress), May 2011. 232 Appendix A. Changes / Author Notes. 234 [RFC Editor: Please remove this section before publication ] 236 From -genesis to -00. 238 o Initial text. 240 Authors' Addresses 242 David Bird 243 Google 244 1600 Amphitheatre Parkway 245 Mountain View, CA 94043 246 US 248 Email: dbird@google.com 250 Warren Kumari 251 Google 252 1600 Amphitheatre Parkway 253 Mountain View, CA 94043 254 US 256 Email: warren@kumari.net