idnits 2.17.1 draft-wkumari-capport-icmp-unreach-01.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 3284 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC0792' is defined on line 205, but no explicit reference was found in the text == Unused Reference: 'RFC1122' is defined on line 208, but no explicit reference was found in the text == Unused Reference: 'RFC3986' is defined on line 214, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sidr-iana-objects' is defined on line 224, but no explicit reference was found in the text 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-01 10 Abstract 12 This document defines a multi-part ICMP extension to ICMP Destination 13 Unreachable messages to signal that a user is behind a Captive 14 Portal. 16 [ Editor note: The IETF is currently discussing improvements in 17 captive portal interactions and user experience improvements. See: 18 https://www.ietf.org/mailman/listinfo/captive-portals ] 20 [RFC Editor: Please remove this before publication. This document is 21 being stored in github at https://github.com/wkumari/draft-wkumari- 22 capport-icmp-unreach . Authors gratefully accept pull requests, and 23 keep the latest (edit buffer) versions there, so commenters can 24 follow along at home.] 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 31, 2015. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 62 2. ICMP Dest Unreachable Captive Portal Object . . . . . . . . . 3 63 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 65 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 68 6.2. Informative References . . . . . . . . . . . . . . . . . 5 69 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 5 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 72 1. Introduction 74 Captive Portals work by blocking (or redirecting) communications 75 outside of a "walled garden" until the user has authenticated and / 76 or acknowledged an Acceptable Use Policy (AUP). Depending on the 77 captive portal implementation, connections other than HTTP will 78 either timeout (packets dropped) or meet with a different, 79 inaccurate, error condition (like a TCP reset or ICMP Destination 80 Unreachable with existing codes). 82 A current option for captive portal networks is to reject traffic not 83 in the walled garden returning the Destination Unreachable either 84 Host or Network Administratively Prohibited. However, these codes 85 are typically permanent policies and do not specifically indicate a 86 captive portal is in use. 88 This document defines an extension object that can be appended to 89 selected multi-part ICMP messages to inform the user that they are 90 behind a captive portal. This informs the user after they have 91 attempted an initial connection and is generated by the Captive 92 Portal NAS itself. 94 [ Editor note: This is complementary, but solves a different problem 95 to: https://tools.ietf.org/html/draft-wkumari-dhc-capport-12 - 96 wkumari-dhc-capport provides information from a DHCP server (and so 97 doesn't need any changes to deployed CPs), and provides information 98 *before* the client attempts a connection. It does not, however, 99 have a way of noting that an existing connection has been 100 interrupted.] 102 1.1. Requirements notation 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 2. ICMP Dest Unreachable Captive Portal Object 110 This document defines an extension object that can be appended to 111 selected multi-part ICMP messages ([RFC4884]). This extension 112 permits Captive Portal (CP) NAS devices to inform user devices that 113 their connection has been blocked by the Captive Portal NAS. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 W - 1 bit Warning. Indicates that the Validity refers to when the 128 service will be interrupted. Note that the "offending" traffic 129 was forwarded, not dropped. 131 Validity - 24 bits Time, in seconds, that this result should be 132 considered valid (and the OS should not attempt to access the same 133 resource in the meantime). 135 Editor note / questions. We are trying to get some feedback on A: 136 this general idea and B: this implementation. 138 Some open questions. 140 W bit or C-Type We have currently specified a single bit (W) to 141 indicate that the remaining lease time is running low, and the the 142 connection will be interrupted sometime "soon". We could, 143 instead, use a differnt C-Type. I think a bit is cleaner (and we 144 have reserved 7 bits for future flags), but could be convinced 145 (or, better yet, bribed) I'm wrong. Or that the whole "warning" 146 idea is a bad one... 148 Legacy interaction If we *do* return e.g ICMP Destination 149 Unreachable, Communication Administratively Prohibited to a 150 "legacy" (non-Dest Unreachable Captive Portal Object aware) client 151 with the 'W' bit set, what happens? In the testing I did, nothing 152 bad seemed to happen, but I *could* see that some hosts may stop 153 sending to that address, or... 155 General concept Is this idea useful? 157 3. IANA Considerations 159 The IANA is requested to assign a Class-Num identifier for the Dest 160 Unreachable Captive Portal Object from the ICMP Extension Object 161 Classes and Class Sub-types registry. 163 The IANA is also requested to form and administer the corresponding 164 class sub-type (C-Type) space, as follows: 166 Dest Unreachable Captive Portal Sub-types: 168 0 Reserved. 170 1 This message format. 172 0x02-0xF6 Available for assignment 174 0xF7-0xFF Reserved for private use 176 C-Type values are assignable on a first-come-first-serve (FCFS) 177 basis. 179 [ Editor note: Currently we are not using the C-Type for anything, 180 but I filled this in anyway. Probably we would overload it at a 181 version identifier type thing, but it could also allow further 182 extension, for example, a pointer to a status page. ] 184 4. Security Considerations 186 This method simply annotates existing ICMP Destination Unreachable 187 messages to inform users why their connection was blocked. This 188 technique can be used to inform captive portal detection probe 189 software that there is a captive portal present (and potentially to 190 connect to the URL handed out using draft-wkumari-dhc-capport. We 191 anticipate that there will be a new solution devised (such as a well 192 known URL / URI on captive portals) to allow the user / captive 193 portal probe to do sometyhing more useful with this information. 195 5. Acknowledgements 197 The authors wish to thank the authors of RFC4950 (especially Ron 198 Bonica ) - I stole much of his text when writing the extension 199 definition. 201 6. References 203 6.1. Normative References 205 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 206 RFC 792, September 1981. 208 [RFC1122] Braden, R., "Requirements for Internet Hosts - 209 Communication Layers", STD 3, RFC 1122, October 1989. 211 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 212 Requirement Levels", BCP 14, RFC 2119, March 1997. 214 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 215 Resource Identifier (URI): Generic Syntax", STD 66, RFC 216 3986, January 2005. 218 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 219 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 220 April 2007. 222 6.2. Informative References 224 [I-D.ietf-sidr-iana-objects] 225 Manderson, T., Vegoda, L., and S. Kent, "RPKI Objects 226 issued by IANA", draft-ietf-sidr-iana-objects-03 (work in 227 progress), May 2011. 229 Appendix A. Changes / Author Notes. 231 [RFC Editor: Please remove this section before publication ] 233 From -00 to 01. 235 o Changed the Captive Portal URL to a URI, and specificed that this 236 can ONLY contain a path element, which is appened to 237 http://. This is to prevent hijacking connections to 238 other addresses. 240 o Then removed the entire URL / URI scheme entirely. 242 From -genesis to -00. 244 o Initial text. 246 Authors' Addresses 248 David Bird 249 Google 250 1600 Amphitheatre Parkway 251 Mountain View, CA 94043 252 US 254 Email: dbird@google.com 256 Warren Kumari 257 Google 258 1600 Amphitheatre Parkway 259 Mountain View, CA 94043 260 US 262 Email: warren@kumari.net