| < draft-wkumari-capport-icmp-unreach-00.txt | draft-wkumari-capport-icmp-unreach-01.txt > | |||
|---|---|---|---|---|
| template D. Bird | template D. Bird | |||
| Internet-Draft W. Kumari | Internet-Draft W. Kumari | |||
| Intended status: Informational Google | Intended status: Informational Google | |||
| Expires: October 31, 2015 April 29, 2015 | Expires: October 31, 2015 April 29, 2015 | |||
| Captive Portal ICMP Destination Unreachable | Captive Portal ICMP Destination Unreachable | |||
| draft-wkumari-capport-icmp-unreach-00 | draft-wkumari-capport-icmp-unreach-01 | |||
| Abstract | Abstract | |||
| This document defines a multi-part ICMP extension to signal that a | This document defines a multi-part ICMP extension to ICMP Destination | |||
| user's device is behind a Captive Portal. | Unreachable messages to signal that a user is behind a Captive | |||
| Portal. | ||||
| [ Editor note: The IETF is currently discussing improvements in | [ Editor note: The IETF is currently discussing improvements in | |||
| captive portal interactions and user experience improvements. See: | captive portal interactions and user experience improvements. See: | |||
| https://www.ietf.org/mailman/listinfo/captive-portals ] | https://www.ietf.org/mailman/listinfo/captive-portals ] | |||
| [RFC Editor: Please remove this before publication. This document is | [RFC Editor: Please remove this before publication. This document is | |||
| being stored in github at https://github.com/wkumari/draft-wkumari- | being stored in github at https://github.com/wkumari/draft-wkumari- | |||
| capport-icmp-unreach . Authors gratefully accept pull requests, and | capport-icmp-unreach . Authors gratefully accept pull requests, and | |||
| keep the latest (edit buffer) versions there, so commenters can | keep the latest (edit buffer) versions there, so commenters can | |||
| follow along at home.] | follow along at home.] | |||
| skipping to change at page 2, line 18 ¶ | skipping to change at page 2, line 21 ¶ | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| described in the Simplified BSD License. | described in the Simplified BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 | 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 | |||
| 2. ICMP Dest Unreachable Captive Portal Object . . . . . . . . . 3 | 2. ICMP Dest Unreachable Captive Portal Object . . . . . . . . . 3 | |||
| 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 | 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 | 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 | |||
| 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 | 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 | 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 | |||
| 6.2. Informative References . . . . . . . . . . . . . . . . . 5 | 6.2. Informative References . . . . . . . . . . . . . . . . . 5 | |||
| Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 5 | Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 5 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 1. Introduction | 1. Introduction | |||
| Captive Portals work by blocking (or redirecting) communications | Captive Portals work by blocking (or redirecting) communications | |||
| skipping to change at page 2, line 51 ¶ | skipping to change at page 3, line 5 ¶ | |||
| This document defines an extension object that can be appended to | This document defines an extension object that can be appended to | |||
| selected multi-part ICMP messages to inform the user that they are | selected multi-part ICMP messages to inform the user that they are | |||
| behind a captive portal. This informs the user after they have | behind a captive portal. This informs the user after they have | |||
| attempted an initial connection and is generated by the Captive | attempted an initial connection and is generated by the Captive | |||
| Portal NAS itself. | Portal NAS itself. | |||
| [ Editor note: This is complementary, but solves a different problem | [ Editor note: This is complementary, but solves a different problem | |||
| to: https://tools.ietf.org/html/draft-wkumari-dhc-capport-12 - | to: https://tools.ietf.org/html/draft-wkumari-dhc-capport-12 - | |||
| wkumari-dhc-capport provides information from a DHCP server (and so | wkumari-dhc-capport provides information from a DHCP server (and so | |||
| doesn't need any changes to deployed CPs, and provides information | doesn't need any changes to deployed CPs), and provides information | |||
| *before* the client attempts a connection. It does not, however, | *before* the client attempts a connection. It does not, however, | |||
| have a way of noting that an existing connection has been | have a way of noting that an existing connection has been | |||
| interrupted.] | interrupted.] | |||
| 1.1. Requirements notation | 1.1. Requirements notation | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
| document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
| 2. ICMP Dest Unreachable Captive Portal Object | 2. ICMP Dest Unreachable Captive Portal Object | |||
| This document defines an extension object that can be appended to | This document defines an extension object that can be appended to | |||
| selected multi-part ICMP messages ([RFC4884]). This extension | selected multi-part ICMP messages ([RFC4884]). This extension | |||
| permits Captive Portal (CP) NAS devices to inform user devices that | permits Captive Portal (CP) NAS devices to inform user devices that | |||
| their connection has been blocked by the Captive Portal NAS, and, | their connection has been blocked by the Captive Portal NAS. | |||
| optionally, how to contact the Captive Portal to satisfy it. | ||||
| The Dest Unreachable Captive Portal Object can be appended to the | The Dest Unreachable Captive Portal Object can be appended to the | |||
| ICMP Destination Unreachable messages. Figure 1 depicts the Dest | ICMP Destination Unreachable messages. Figure 1 depicts the Dest | |||
| Unreachable Captive Portal Object. It must be preceded by an ICMP | Unreachable Captive Portal Object. It must be preceded by an ICMP | |||
| Extension Structure Header and an ICMP Object Header. Both are | Extension Structure Header and an ICMP Object Header. Both are | |||
| defined in [RFC4884]. | defined in [RFC4884]. | |||
| 0 1 2 3 | 0 1 2 3 | |||
| 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 | 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 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |W| Reserved | Validity (seconds) | | |W| Reserved | Validity (seconds) | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Captive Portal URL ~ | ||||
| ~ (optional) | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| W - 1 bit Warning. Indicates that the Validity refers to when the | W - 1 bit Warning. Indicates that the Validity refers to when the | |||
| service will be interrupted. Note that the "offending" traffic | service will be interrupted. Note that the "offending" traffic | |||
| was forwarded, not dropped. | was forwarded, not dropped. | |||
| Validity - 24 bits Time, in seconds, that this result should be | Validity - 24 bits Time, in seconds, that this result should be | |||
| considered valid (and the OS should not attempt to access the same | considered valid (and the OS should not attempt to access the same | |||
| resource in the meantime). | resource in the meantime). | |||
| Captive Portal URL - Variable The optional URL of the Captive | ||||
| Portal. This allows Captive Portal detection software running on | ||||
| the user's device to locate and connect to the captive portal to | ||||
| improve the user experience. The length of the URL is calculated | ||||
| from the ICMP Extension Object header Length minue the ICMP | ||||
| Extension Object and Captive Portal Object header lengths, which | ||||
| is zero when no URL is provided. | ||||
| Editor note / questions. We are trying to get some feedback on A: | Editor note / questions. We are trying to get some feedback on A: | |||
| this general idea and B: this implementation. | this general idea and B: this implementation. | |||
| Some open questions. | Some open questions. | |||
| W bit or C-Type We have currently specified a single bit (W) to | W bit or C-Type We have currently specified a single bit (W) to | |||
| indicate that the remaining lease time is running low, and the the | indicate that the remaining lease time is running low, and the the | |||
| connection will be interrupted sometime "soon". We could, | connection will be interrupted sometime "soon". We could, | |||
| instead, use a differnt C-Type. I think a bit is cleaner (and we | instead, use a differnt C-Type. I think a bit is cleaner (and we | |||
| have reserved 7 bits for future flags), but could be convinced | have reserved 7 bits for future flags), but could be convinced | |||
| skipping to change at page 5, line 12 ¶ | skipping to change at page 4, line 47 ¶ | |||
| C-Type values are assignable on a first-come-first-serve (FCFS) | C-Type values are assignable on a first-come-first-serve (FCFS) | |||
| basis. | basis. | |||
| [ Editor note: Currently we are not using the C-Type for anything, | [ Editor note: Currently we are not using the C-Type for anything, | |||
| but I filled this in anyway. Probably we would overload it at a | but I filled this in anyway. Probably we would overload it at a | |||
| version identifier type thing, but it could also allow further | version identifier type thing, but it could also allow further | |||
| extension, for example, a pointer to a status page. ] | extension, for example, a pointer to a status page. ] | |||
| 4. Security Considerations | 4. Security Considerations | |||
| The obvious security consideration is how to confirm that the | This method simply annotates existing ICMP Destination Unreachable | |||
| received ICMP Message actually came from a Captive Portal, and was | messages to inform users why their connection was blocked. This | |||
| not generated from a passive observer on the network (to force the | technique can be used to inform captive portal detection probe | |||
| user to connect to a malicious device.). | software that there is a captive portal present (and potentially to | |||
| connect to the URL handed out using draft-wkumari-dhc-capport. We | ||||
| anticipate that there will be a new solution devised (such as a well | ||||
| known URL / URI on captive portals) to allow the user / captive | ||||
| portal probe to do sometyhing more useful with this information. | ||||
| 5. Acknowledgements | 5. Acknowledgements | |||
| The authors wish to thank the authors of RFC4950 (especially Ron | The authors wish to thank the authors of RFC4950 (especially Ron | |||
| Bonica ) - I stole much of his text when writing the extension | Bonica ) - I stole much of his text when writing the extension | |||
| definition. | definition. | |||
| 6. References | 6. References | |||
| 6.1. Normative References | 6.1. Normative References | |||
| [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, | [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, | |||
| RFC 792, September 1981. | RFC 792, September 1981. | |||
| [RFC1122] Braden, R., "Requirements for Internet Hosts - | [RFC1122] Braden, R., "Requirements for Internet Hosts - | |||
| Communication Layers", STD 3, RFC 1122, October 1989. | Communication Layers", STD 3, RFC 1122, October 1989. | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
| [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | ||||
| Resource Identifier (URI): Generic Syntax", STD 66, RFC | ||||
| 3986, January 2005. | ||||
| [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, | [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, | |||
| "Extended ICMP to Support Multi-Part Messages", RFC 4884, | "Extended ICMP to Support Multi-Part Messages", RFC 4884, | |||
| April 2007. | April 2007. | |||
| 6.2. Informative References | 6.2. Informative References | |||
| [I-D.ietf-sidr-iana-objects] | [I-D.ietf-sidr-iana-objects] | |||
| Manderson, T., Vegoda, L., and S. Kent, "RPKI Objects | Manderson, T., Vegoda, L., and S. Kent, "RPKI Objects | |||
| issued by IANA", draft-ietf-sidr-iana-objects-03 (work in | issued by IANA", draft-ietf-sidr-iana-objects-03 (work in | |||
| progress), May 2011. | progress), May 2011. | |||
| Appendix A. Changes / Author Notes. | Appendix A. Changes / Author Notes. | |||
| [RFC Editor: Please remove this section before publication ] | [RFC Editor: Please remove this section before publication ] | |||
| From -00 to 01. | ||||
| o Changed the Captive Portal URL to a URI, and specificed that this | ||||
| can ONLY contain a path element, which is appened to | ||||
| http://<gateway_ip>. This is to prevent hijacking connections to | ||||
| other addresses. | ||||
| o Then removed the entire URL / URI scheme entirely. | ||||
| From -genesis to -00. | From -genesis to -00. | |||
| o Initial text. | o Initial text. | |||
| Authors' Addresses | Authors' Addresses | |||
| David Bird | David Bird | |||
| 1600 Amphitheatre Parkway | 1600 Amphitheatre Parkway | |||
| Mountain View, CA 94043 | Mountain View, CA 94043 | |||
| End of changes. 11 change blocks. | ||||
| 23 lines changed or deleted | 29 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||