From alexander.roscoe@gmail.com Fri Aug 26 08:15:16 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE83A12D698 for ; Fri, 26 Aug 2016 08:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UqP8VCiZihq for ; Fri, 26 Aug 2016 08:15:15 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFC4E12D59F for ; Fri, 26 Aug 2016 08:15:14 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id k90so142927248uak.1 for ; Fri, 26 Aug 2016 08:15:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=t1vsJhPJoD0gXEADaFQoWnohx4ELhjItyM0a5NYMdG0=; b=n+kP5tICs5G6fDi14lTa1fnpTFaPkccaHDO8aPnpe2HjmF4VVT5+/Zu67Xn1nU4nQ1 SD8/UsrMsJHmN/kwsZyNhiucHUrt5G+eekRwvGA9zfi/Ok64sBPjrWvkosZrvtbyTKTt ok2rASUCBRAPNPPymAnw/GIxP+zKeBmrFlEh5ZLh7MLDmqg6LgRvqE6noeOiQGTkrfGA RJpViUG9TJY+9fff3/ea+YK47PedQNDWPI1BRSudfzodT4D3LxKvVKI3rjBWi3Lc5Pai eXh/J9NyYHXVpcT3EDRWfT00A6K5TMo8jaHLO6Kf0WgIX9dFnzyV+Kp3L2iIKIM7H7DO /XDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=t1vsJhPJoD0gXEADaFQoWnohx4ELhjItyM0a5NYMdG0=; b=QoVmb1FgjYiv8+mJE2X9+5vXqFW0KI0dethPo37mcX+dJvonDhTGbWNx1lJCL75jo1 6AU4OtRiWUcbbMwiivwEFCbMV6+pFeZ7Ea513zA3eaRjVTUpJ4yyYk3O9PPU4aGW6Msk 4q/zE7pLg7uNP88Da1p4zM3+iH/0LuoiTsXFLRRCND7pVUsijAkhXxMSQNC4to87OgNa l4AOHuuQob4JO1cSpy3HiQpuJu/MqhW4sU8mu1ib/vKKqnO5CJFoq0bVp303qaIDuwnO 8s2MKq8cWuVuI9Ib33lNs9XXnnF3s1+q20036UEHZYSiPrwqeCEeDe2Q0N+VH3zHpdQZ fgJQ== X-Gm-Message-State: AE9vXwPuGK8s4vRZgqdjhEAqelAsXPKLKJV8up24fwxWHq4cE93ITYcTrsf5DYSnoXH8lW4Rx+NZ4joAUrCY0A== X-Received: by 10.31.136.70 with SMTP id k67mr2409443vkd.13.1472224513878; Fri, 26 Aug 2016 08:15:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.85.212 with HTTP; Fri, 26 Aug 2016 08:14:53 -0700 (PDT) From: Alexander Roscoe Date: Fri, 26 Aug 2016 11:14:53 -0400 Message-ID: To: captive-portals@ietf.org Content-Type: multipart/alternative; boundary=001a11440bb62df691053afafb39 Archived-At: Subject: [Captive-portals] IPv6 RA URI option X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 26 Aug 2016 15:16:20 -0000 --001a11440bb62df691053afafb39 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am looking over RFC 7710 concerning how the URI is communicated to the end user. I really like the IPv4 DHCP solution, I think this could easily be implemented in a DHCP server. I think it could be easily implemented in the RA for IPv6 as well however I do see a challenge when each connected client needs a unique URI such as it containing the parameter for the client mac. For example, a url like https://captiveportal/?client-mac=3D11:22:33:44:55:66. The RA is sent to everyone and cannot be tailored to each client while DHCP is very client specific and can be changed on-the-fly. Most captive portals rely on the client mac address during the authentication process. I am aware of networks using the IP address to associate the user at the AAA server but from my understanding this is a rare network setup. I think a potential solution for the IPv6 RA would be to define an HTTP POST parameter in which the client can use like =E2=80=98client-mac=E2=80=99 and let the client pos= t it the URI https://captiveporta/. Thoughts? Ideas? --=20 Alexander Roscoe 484-716-9048 --001a11440bb62df691053afafb39 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am looking over RFC 7710 concerning how the URI is communicated to the end user= .=C2=A0 I really like the IPv4 DHCP solution, =C2=A0I think this could easi= ly be implemented in a DHCP server.=C2=A0 I think it could be easily implem= ented in the RA for IPv6 as well however I do see a challenge when each con= nected client needs a unique URI such as it containing the parameter for th= e client mac. For example, a url like https://captiveportal/?client-mac=3D11:22:33:4= 4:55:66. The RA is sent to everyone and cannot be tailored to each clie= nt while DHCP is very client specific and can be changed on-the-fly.=C2=A0 = Most captive portals rely on the client mac address during the authenticati= on process. I am aware of networks using the IP address to associate the us= er at the AAA server but from my understanding this is a rare network setup= .=C2=A0 I think a potential solution for the IPv6 RA would be to define an = HTTP POST parameter in which the client can use like =E2=80=98client-mac=E2= =80=99 and let the client post it the URI https://captiveporta/. =C2=A0 Thoughts? Ideas?


--
Alexa= nder Roscoe
484-716-9048
--001a11440bb62df691053afafb39-- From nobody Fri Aug 26 10:09:01 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B89AA12D197 for ; Fri, 26 Aug 2016 10:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqMAkMRtxp8D for ; Fri, 26 Aug 2016 10:08:58 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E82812D195 for ; Fri, 26 Aug 2016 10:08:58 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0294.000; Fri, 26 Aug 2016 13:08:56 -0400 From: Dave Dolson To: Alexander Roscoe , "captive-portals@ietf.org" Thread-Topic: [Captive-portals] IPv6 RA URI option Thread-Index: AQHR/6zOJHWZPicJ1E2dyKn7lSMga6BbdZtg Date: Fri, 26 Aug 2016 17:08:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E98310920B2wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [Captive-portals] IPv6 RA URI option X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 26 Aug 2016 17:09:00 -0000 --_000_E8355113905631478EFF04F5AA706E98310920B2wtlexchp2sandvi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxleGFuZGVyLA0KU3VwcG9zZSBpbnN0ZWFkIG9mIHByb3ZpZGluZyBhIFVSTCBmb3IgdGhlIGxh bmRpbmcgcGFnZSwgdGhlIFJBIHByb3ZpZGVkIHRoZSBVUkkgZm9yIGEgc3RhbmRhcmRpemVkIFJF U1QgaW50ZXJmYWNlOyB0aGUgY2xpZW50IGNvdWxkIHBvc3QgaXRzIGRldGFpbHMgKE1BQyBhZGRy ZXNzLCBkZXZpY2UgdHlwZT8pIHRvIHRoaXMgaW50ZXJmYWNlLCB3aGljaCB3b3VsZCByZXR1cm4g dGhlIFVSTCBmb3IgdGhlIGJyb3dzZXIgbGFuZGluZyBwYWdlLCBhbmQgcG9zc2libHkgYW55IG51 bWJlciBvZiBvdGhlciBkZXRhaWxzIGFuZCBtZWNoYW5pc21zLCBlLmcuLCBpbiBhIEpTT04gcmVz cG9uc2UuDQoNClRoaXMgYWRkcyBhIGxldmVsIG9mIGluZGlyZWN0aW9uIHRoYXQgc2ltcGxpZmll cyB3aGF0IG5lZWRzIHRvIGdvIGluIHRoZSBSQS4NCg0KSSB0aGluayB0aGVyZSBpcyBhbHNvIGZs ZXhpYmlsaXR5IGluIGxldHRpbmcgdGhlIGNsaWVudCBrbm93IGRldGFpbHMgYWJvdXQgdGhlIGNh cHBvcnQgc2l0dWF0aW9uIGluIHRoZSBBUEkuIEUuZy4sIGhvdyBvZnRlbiB3aWxsIHRoZSBwYWdl IG5lZWQgdG8gYmUgdmlzaXRlZD8NCg0KUkEtLT5jbGllbnQ6ICDigJxUaGlzIGlzIHRoZSBVUkkg Zm9yIGdldHRpbmcgY2FwcG9ydCBpbmZvOiBodHRwOi8vY2FwcG9ydC5leGFtcGxlLmNvbS9hcGni gJ0NCkNsaWVudC0tPmNhcHBvcnQvYXBpOiDigJxNeSBNQUMgYWRkcmVzcyBpcyAwMTowMjowMzow NDowNTowNiBhbmQgbXkgSVAgYWRkcmVzcyBpcyDigKbigJ0NCkNhcHBvcnQvYXBpLS0+Y2xpZW50 OiDigJxZb3VyIGxhbmRpbmcgcGFnZSBpcyBodHRwczovL2NhcHBvcnQuZXhhbXBsZS5jb20vbGFu ZGluZy9tYWM9MDE6MDI6MDM6MDQ6MDU6MDYgOyByZWZyZXNoIGV2ZXJ5IDYwbWlu4oCdDQoNCg0K DQotRGF2ZQ0KDQoNCkZyb206IENhcHRpdmUtcG9ydGFscyBbbWFpbHRvOmNhcHRpdmUtcG9ydGFs cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWxleGFuZGVyIFJvc2NvZQ0KU2VudDog RnJpZGF5LCBBdWd1c3QgMjYsIDIwMTYgMTE6MTUgQU0NClRvOiBjYXB0aXZlLXBvcnRhbHNAaWV0 Zi5vcmcNClN1YmplY3Q6IFtDYXB0aXZlLXBvcnRhbHNdIElQdjYgUkEgVVJJIG9wdGlvbg0KDQpJ IGFtIGxvb2tpbmcgb3ZlciBSRkMgNzcxMDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj NzcxMD4gY29uY2VybmluZyBob3cgdGhlIFVSSSBpcyBjb21tdW5pY2F0ZWQgdG8gdGhlIGVuZCB1 c2VyLiAgSSByZWFsbHkgbGlrZSB0aGUgSVB2NCBESENQIHNvbHV0aW9uLCAgSSB0aGluayB0aGlz IGNvdWxkIGVhc2lseSBiZSBpbXBsZW1lbnRlZCBpbiBhIERIQ1Agc2VydmVyLiAgSSB0aGluayBp dCBjb3VsZCBiZSBlYXNpbHkgaW1wbGVtZW50ZWQgaW4gdGhlIFJBIGZvciBJUHY2IGFzIHdlbGwg aG93ZXZlciBJIGRvIHNlZSBhIGNoYWxsZW5nZSB3aGVuIGVhY2ggY29ubmVjdGVkIGNsaWVudCBu ZWVkcyBhIHVuaXF1ZSBVUkkgc3VjaCBhcyBpdCBjb250YWluaW5nIHRoZSBwYXJhbWV0ZXIgZm9y IHRoZSBjbGllbnQgbWFjLiBGb3IgZXhhbXBsZSwgYSB1cmwgbGlrZSBodHRwczovL2NhcHRpdmVw b3J0YWwvP2NsaWVudC1tYWM9MTE6MjI6MzM6NDQ6NTU6NjYuIFRoZSBSQSBpcyBzZW50IHRvIGV2 ZXJ5b25lIGFuZCBjYW5ub3QgYmUgdGFpbG9yZWQgdG8gZWFjaCBjbGllbnQgd2hpbGUgREhDUCBp cyB2ZXJ5IGNsaWVudCBzcGVjaWZpYyBhbmQgY2FuIGJlIGNoYW5nZWQgb24tdGhlLWZseS4gIE1v c3QgY2FwdGl2ZSBwb3J0YWxzIHJlbHkgb24gdGhlIGNsaWVudCBtYWMgYWRkcmVzcyBkdXJpbmcg dGhlIGF1dGhlbnRpY2F0aW9uIHByb2Nlc3MuIEkgYW0gYXdhcmUgb2YgbmV0d29ya3MgdXNpbmcg dGhlIElQIGFkZHJlc3MgdG8gYXNzb2NpYXRlIHRoZSB1c2VyIGF0IHRoZSBBQUEgc2VydmVyIGJ1 dCBmcm9tIG15IHVuZGVyc3RhbmRpbmcgdGhpcyBpcyBhIHJhcmUgbmV0d29yayBzZXR1cC4gIEkg dGhpbmsgYSBwb3RlbnRpYWwgc29sdXRpb24gZm9yIHRoZSBJUHY2IFJBIHdvdWxkIGJlIHRvIGRl ZmluZSBhbiBIVFRQIFBPU1QgcGFyYW1ldGVyIGluIHdoaWNoIHRoZSBjbGllbnQgY2FuIHVzZSBs aWtlIOKAmGNsaWVudC1tYWPigJkgYW5kIGxldCB0aGUgY2xpZW50IHBvc3QgaXQgdGhlIFVSSSBo dHRwczovL2NhcHRpdmVwb3J0YS8uICAgVGhvdWdodHM/IElkZWFzPw0KDQoNCi0tDQpBbGV4YW5k ZXIgUm9zY29lDQo0ODQtNzE2LTkwNDgNCg== --_000_E8355113905631478EFF04F5AA706E98310920B2wtlexchp2sandvi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWxleGFuZGVyLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TdXBwb3NlIGluc3RlYWQgb2YgcHJvdmlkaW5nIGEg VVJMIGZvciB0aGUgbGFuZGluZyBwYWdlLCB0aGUgUkEgcHJvdmlkZWQgdGhlIFVSSSBmb3IgYSBz dGFuZGFyZGl6ZWQgUkVTVCBpbnRlcmZhY2U7IHRoZSBjbGllbnQgY291bGQgcG9zdCBpdHMgZGV0 YWlscyAoTUFDIGFkZHJlc3MsDQogZGV2aWNlIHR5cGU/KSB0byB0aGlzIGludGVyZmFjZSwgd2hp Y2ggd291bGQgcmV0dXJuIHRoZSBVUkwgZm9yIHRoZSBicm93c2VyIGxhbmRpbmcgcGFnZSwgYW5k IHBvc3NpYmx5IGFueSBudW1iZXIgb2Ygb3RoZXIgZGV0YWlscyBhbmQgbWVjaGFuaXNtcywgZS5n LiwgaW4gYSBKU09OIHJlc3BvbnNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhpcyBhZGRzIGEgbGV2ZWwgb2YgaW5k aXJlY3Rpb24gdGhhdCBzaW1wbGlmaWVzIHdoYXQgbmVlZHMgdG8gZ28gaW4gdGhlIFJBLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SSB0aGluayB0aGVyZSBpcyBhbHNvIGZsZXhpYmlsaXR5IGluIGxldHRpbmcgdGhlIGNs aWVudCBrbm93IGRldGFpbHMgYWJvdXQgdGhlIGNhcHBvcnQgc2l0dWF0aW9uIGluIHRoZSBBUEku IEUuZy4sIGhvdyBvZnRlbiB3aWxsIHRoZSBwYWdlIG5lZWQgdG8gYmUgdmlzaXRlZD88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlJBLS0mZ3Q7Y2xpZW50OiZuYnNwOyDigJxUaGlzIGlzIHRoZSBVUkkgZm9yIGdldHRpbmcg Y2FwcG9ydCBpbmZvOiBodHRwOi8vY2FwcG9ydC5leGFtcGxlLmNvbS9hcGnigJ08bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2xpZW50LS0mZ3Q7Y2FwcG9ydC9hcGk6IOKAnE15IE1BQyBh ZGRyZXNzIGlzIDAxOjAyOjAzOjA0OjA1OjA2IGFuZCBteSBJUCBhZGRyZXNzIGlzIOKApuKAnTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DYXBwb3J0L2FwaS0tJmd0O2NsaWVudDog4oCc WW91ciBsYW5kaW5nIHBhZ2UgaXMgaHR0cHM6Ly9jYXBwb3J0LmV4YW1wbGUuY29tL2xhbmRpbmcv bWFjPTAxOjAyOjAzOjA0OjA1OjA2IDsgcmVmcmVzaCBldmVyeSA2MG1pbuKAnTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4tRGF2ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IENhcHRpdmUtcG9y dGFscyBbbWFpbHRvOmNhcHRpdmUtcG9ydGFscy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5BbGV4YW5kZXIgUm9zY29lPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgQXVn dXN0IDI2LCAyMDE2IDExOjE1IEFNPGJyPg0KPGI+VG86PC9iPiBjYXB0aXZlLXBvcnRhbHNAaWV0 Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0NhcHRpdmUtcG9ydGFsc10gSVB2NiBSQSBVUkkg b3B0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBsb29raW5n IG92ZXIgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc3MTAiPg0KUkZD IDc3MTA8L2E+IGNvbmNlcm5pbmcgaG93IHRoZSBVUkkgaXMgY29tbXVuaWNhdGVkIHRvIHRoZSBl bmQgdXNlci4mbmJzcDsgSSByZWFsbHkgbGlrZSB0aGUgSVB2NCBESENQIHNvbHV0aW9uLCAmbmJz cDtJIHRoaW5rIHRoaXMgY291bGQgZWFzaWx5IGJlIGltcGxlbWVudGVkIGluIGEgREhDUCBzZXJ2 ZXIuJm5ic3A7IEkgdGhpbmsgaXQgY291bGQgYmUgZWFzaWx5IGltcGxlbWVudGVkIGluIHRoZSBS QSBmb3IgSVB2NiBhcyB3ZWxsIGhvd2V2ZXIgSSBkbyBzZWUgYSBjaGFsbGVuZ2UNCiB3aGVuIGVh Y2ggY29ubmVjdGVkIGNsaWVudCBuZWVkcyBhIHVuaXF1ZSBVUkkgc3VjaCBhcyBpdCBjb250YWlu aW5nIHRoZSBwYXJhbWV0ZXIgZm9yIHRoZSBjbGllbnQgbWFjLiBGb3IgZXhhbXBsZSwgYSB1cmwg bGlrZQ0KPGEgaHJlZj0iaHR0cHM6Ly9jYXB0aXZlcG9ydGFsLz9jbGllbnQtbWFjPTExOjIyOjMz OjQ0OjU1OjY2Ij5odHRwczovL2NhcHRpdmVwb3J0YWwvP2NsaWVudC1tYWM9MTE6MjI6MzM6NDQ6 NTU6NjY8L2E+LiBUaGUgUkEgaXMgc2VudCB0byBldmVyeW9uZSBhbmQgY2Fubm90IGJlIHRhaWxv cmVkIHRvIGVhY2ggY2xpZW50IHdoaWxlIERIQ1AgaXMgdmVyeSBjbGllbnQgc3BlY2lmaWMgYW5k IGNhbiBiZSBjaGFuZ2VkIG9uLXRoZS1mbHkuJm5ic3A7IE1vc3QgY2FwdGl2ZQ0KIHBvcnRhbHMg cmVseSBvbiB0aGUgY2xpZW50IG1hYyBhZGRyZXNzIGR1cmluZyB0aGUgYXV0aGVudGljYXRpb24g cHJvY2Vzcy4gSSBhbSBhd2FyZSBvZiBuZXR3b3JrcyB1c2luZyB0aGUgSVAgYWRkcmVzcyB0byBh c3NvY2lhdGUgdGhlIHVzZXIgYXQgdGhlIEFBQSBzZXJ2ZXIgYnV0IGZyb20gbXkgdW5kZXJzdGFu ZGluZyB0aGlzIGlzIGEgcmFyZSBuZXR3b3JrIHNldHVwLiZuYnNwOyBJIHRoaW5rIGEgcG90ZW50 aWFsIHNvbHV0aW9uIGZvciB0aGUgSVB2Ng0KIFJBIHdvdWxkIGJlIHRvIGRlZmluZSBhbiBIVFRQ IFBPU1QgcGFyYW1ldGVyIGluIHdoaWNoIHRoZSBjbGllbnQgY2FuIHVzZSBsaWtlIOKAmGNsaWVu dC1tYWPigJkgYW5kIGxldCB0aGUgY2xpZW50IHBvc3QgaXQgdGhlIFVSSQ0KPGEgaHJlZj0iaHR0 cHM6Ly9jYXB0aXZlcG9ydGEvIj5odHRwczovL2NhcHRpdmVwb3J0YS88L2E+LiAmbmJzcDsgVGhv dWdodHM/IElkZWFzPzxicj4NCjxicj4NCjxicj4NCi0tIDxicj4NCkFsZXhhbmRlciBSb3Njb2U8 YnI+DQo0ODQtNzE2LTkwNDg8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_E8355113905631478EFF04F5AA706E98310920B2wtlexchp2sandvi_-- From nobody Fri Aug 26 11:00:26 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D7812D533 for ; Fri, 26 Aug 2016 11:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2wnPBEAnYjg for ; Fri, 26 Aug 2016 11:00:23 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3212C12D511 for ; Fri, 26 Aug 2016 11:00:23 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id l203so120691042oib.1 for ; Fri, 26 Aug 2016 11:00:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=e3dkVX9CfCK/KIDyYl28gjtYEYwC5XJlE3iDnOuF/WE=; b=bmgchPRRY/uM0n2K5qpyOVO3jpQYZpDywE/3ud823nM3ZZUZ9AQhYKU1yc9yOO80bC B5lEXkHUCn51RYocoI/iC7pPlJdZB1z/ul/vx106xUHHRD6lkVRYqJqWCsX3M22d8xHb 8vnddRhE3qsQjnv5ELqpDRgXtfVfON2yu9K10kRzH5Cc4DxjpHj1VLmDMH+lmIH7Mrcf ecHadyfqumEpqPEYcZ2wRjA9HcJc5vSV/z54j/ia8Ev1XnsQGUC0K56QLdLBPklLF2/V Qu1vplHlPvXRaVvVfbD+FpJbyI4ZNQfp0gIaYxbQW9dLuE3fXTsD8Z30FXdeqgOys2Os 3sZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=e3dkVX9CfCK/KIDyYl28gjtYEYwC5XJlE3iDnOuF/WE=; b=B34nUh93MOkSSSmPJjdoxhkROPU7vvKCFAq2doQRjBufsSUUpHG0/YU7IoFBKhb7HO Dk0h5TQSV5afP+ABp/IFxcwWVWgbbPm4BYOoquzwEcaJ4lHJBuX91ek21lUF6utLcPbw 2sICL1mFBHgQiVhLFkHosm9tamIaCmP3gvoTKVscVLF88stnkUTu3w4zWvwG9HJpIX8p G8WbOj2HuH3LTo2obpHYUdDyZ69n33ZYQGS2L1WXQQ4EGKJk9CA2ypIopHesGJpLkJnA oyi6wQjeqbOy8Ldrs2e/aiyJS1Scvf8gqEcoxR0poL7LmX9q3CfsFbspxtfT8x3GIObk VVnQ== X-Gm-Message-State: AE9vXwPv87/WbeedVKKdRavRFYMlvxZHF9xwYC2esRorQvxLbhmZJYA12dTcOo6PIApph0eq+F6CgnmtESQ9aHH1 X-Received: by 10.202.56.85 with SMTP id f82mr3505718oia.107.1472234422422; Fri, 26 Aug 2016 11:00:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.175.19 with HTTP; Fri, 26 Aug 2016 11:00:21 -0700 (PDT) In-Reply-To: References: From: David Bird Date: Fri, 26 Aug 2016 11:00:21 -0700 Message-ID: To: Dave Dolson Content-Type: multipart/alternative; boundary=001a113cc266c6b41c053afd49ac Archived-At: Cc: "captive-portals@ietf.org" , Alexander Roscoe Subject: Re: [Captive-portals] IPv6 RA URI option X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 26 Aug 2016 18:00:25 -0000 --001a113cc266c6b41c053afd49ac Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable RFC 7710 says, ".. provides the URI to access an authentication page." Obviously, this will need further clarification should it point to an API end-point. As it is written, I think it is clear that the URI should be the same (or will redirect you to the same) URL as a HTTP hijack takes you to (minus any "original URL"). In CoovaChilli, at least, there is already an internal/local URL that is suitable for RFC7710. In that the URL http://:/prelogin in chilli hooks into the hijacking routine to redirect the user to the captive portal URL specific to them (e.g. the hijacking routine adds the query string params specific to station/session). https://github.com/coova/coova-chilli/pull/274/commits/1e95a2cf97e981f2f538= 26e38cd12372555a809c On Fri, Aug 26, 2016 at 10:08 AM, Dave Dolson wrote: > Alexander, > > Suppose instead of providing a URL for the landing page, the RA provided > the URI for a standardized REST interface; the client could post its > details (MAC address, device type?) to this interface, which would return > the URL for the browser landing page, and possibly any number of other > details and mechanisms, e.g., in a JSON response. > > > > This adds a level of indirection that simplifies what needs to go in the > RA. > > > > I think there is also flexibility in letting the client know details abou= t > the capport situation in the API. E.g., how often will the page need to b= e > visited? > > > > RA-->client: =E2=80=9CThis is the URI for getting capport info: > http://capport.example.com/api=E2=80=9D > > Client-->capport/api: =E2=80=9CMy MAC address is 01:02:03:04:05:06 and my= IP > address is =E2=80=A6=E2=80=9D > > Capport/api-->client: =E2=80=9CYour landing page is https://capport.examp= le.com/ > landing/mac=3D01:02:03:04:05:06 ; refresh every 60min=E2=80=9D > > > > > > > > -Dave > > > > > > *From:* Captive-portals [mailto:captive-portals-bounces@ietf.org] *On > Behalf Of *Alexander Roscoe > *Sent:* Friday, August 26, 2016 11:15 AM > *To:* captive-portals@ietf.org > *Subject:* [Captive-portals] IPv6 RA URI option > > > > I am looking over RFC 7710 > concerning how the URI is communicated to the end user. I really like th= e > IPv4 DHCP solution, I think this could easily be implemented in a DHCP > server. I think it could be easily implemented in the RA for IPv6 as wel= l > however I do see a challenge when each connected client needs a unique UR= I > such as it containing the parameter for the client mac. For example, a ur= l > like https://captiveportal/?client-mac=3D11:22:33:44:55:66. The RA is sen= t > to everyone and cannot be tailored to each client while DHCP is very clie= nt > specific and can be changed on-the-fly. Most captive portals rely on the > client mac address during the authentication process. I am aware of > networks using the IP address to associate the user at the AAA server but > from my understanding this is a rare network setup. I think a potential > solution for the IPv6 RA would be to define an HTTP POST parameter in whi= ch > the client can use like =E2=80=98client-mac=E2=80=99 and let the client p= ost it the URI > https://captiveporta/. Thoughts? Ideas? > > > -- > Alexander Roscoe > 484-716-9048 > > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals > > --001a113cc266c6b41c053afd49ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
RFC 7710 says, "..=C2=A0provides the URI to access an=C2=A0authentication page." Obvi= ously, this will need further clarification should it point to an API end-p= oint. As it is written, I think it is clear that the URI should be the same= (or will redirect you to the same) URL as a HTTP hijack takes you to (minu= s any "original URL").

In CoovaChilli, at least, there is already an interna= l/local URL that is suitable for RFC7710. In that the URL http://<nas-ip= >:<port>/prelogin in chilli hooks into the hijacking routine to re= direct the user to the captive portal URL specific to them (e.g. the hijack= ing routine adds the query string params specific to station/session).

https://github.com/coova/coova-chilli/pull/2= 74/commits/1e95a2cf97e981f2f53826e38cd12372555a809c


On Fri, Aug 26, 2016 at 10:08 AM, Dave Dolson <= ddolson@sandvine.= com> wrote:

Alexander,<= /span>

Suppose instead of provid= ing a URL for the landing page, the RA provided the URI for a standardized = REST interface; the client could post its details (MAC address, device type?) to this interface, which would return the URL for the browse= r landing page, and possibly any number of other details and mechanisms, e.= g., in a JSON response.

=C2=A0

This adds a level of indi= rection that simplifies what needs to go in the RA.

=C2=A0

I think there is also fle= xibility in letting the client know details about the capport situation in = the API. E.g., how often will the page need to be visited?

=C2=A0

RA-->client:=C2=A0 =E2= =80=9CThis is the URI for getting capport info: http://capport.example.com/api= =E2=80=9D

Client-->capport/api: = =E2=80=9CMy MAC address is 01:02:03:04:05:06 and my IP address is =E2=80=A6= =E2=80=9D

Capport/api-->client: = =E2=80=9CYour landing page is https://capport.example.com/landing/mac=3D01:02:03:04:05:06 ; refresh every 60min=E2=80=9D

=C2=A0

=C2=A0

=C2=A0

-Dave

=C2=A0

=C2=A0

From: Captive-= portals [mailto:captive-portals-bounces@ietf.org] On Behalf Of Alexander Roscoe
Sent: Friday, August 26, 2016 11:15 AM
To: ca= ptive-portals@ietf.org
Subject: [Captive-portals] IPv6 RA URI option

=C2=A0

I am looking over RFC 7710 concerning how the URI is communicated to the end user.=C2=A0 = I really like the IPv4 DHCP solution, =C2=A0I think this could easily be im= plemented in a DHCP server.=C2=A0 I think it could be easily implemented in= the RA for IPv6 as well however I do see a challenge when each connected client needs a unique URI such as it containing the pa= rameter for the client mac. For example, a url like https://captiveportal/?client-mac=3D11:22:33:44:55:66. Th= e RA is sent to everyone and cannot be tailored to each client while DHCP i= s very client specific and can be changed on-the-fly.=C2=A0 Most captive portals rely on the client mac address during the authentication process. = I am aware of networks using the IP address to associate the user at the AA= A server but from my understanding this is a rare network setup.=C2=A0 I th= ink a potential solution for the IPv6 RA would be to define an HTTP POST parameter in which the client can use l= ike =E2=80=98client-mac=E2=80=99 and let the client post it the URI https://captiveporta/. =C2=A0 Thoughts? Ideas?


--
Alexander Roscoe
484-7= 16-9048


_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/capt= ive-portals


--001a113cc266c6b41c053afd49ac-- From nobody Fri Aug 26 11:29:32 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7CC12D783 for ; Fri, 26 Aug 2016 11:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKax5vJPNsyO for ; Fri, 26 Aug 2016 11:29:29 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9D7112D778 for ; Fri, 26 Aug 2016 11:29:28 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id k90so151985940uak.1 for ; Fri, 26 Aug 2016 11:29:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F6ctTmuIylP+K/+MTbpqUxWF01OEc4lEm5Ai+qlHO2s=; b=hG4kJuo/9TX0VcYHrTQv1cDF23G4N8sz2RR8+R9O5BI1qBm4766m+PhdsX4sdaSlm0 r+qC582UwyqshkCrSMR7Yuq+VsmWrYqidMYCObRIZ9A/fPuG3domV8j45tEMOrZAzyY2 fPT1z5OzynfKCi0meA0UcSo6OhGNeNH8gFCeAHzJnWMrlLQgvdn2vPtLS+tz6YoCdLZh BREFBttgwxwEkosSyqfgKj6g0t1+aohj562t73rZ4VqD9M1Qa/G7TEQl/Et5boIk7hm6 5fcKOQdVE3ZYwWiVg6xroDchazoxfkxlxueWfWIcpQN4wSP3uZnpx6NvI4khPo1UeJGr 8mkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=F6ctTmuIylP+K/+MTbpqUxWF01OEc4lEm5Ai+qlHO2s=; b=gptkWjjTeTgptcBlQ1sAy2uGw6ljyLXjKAmU0roI2OqQbJG8iyIuoJ3SzPFFbnXfCM aJ87u7PftenBy3ag0R7mYI2cMOFlK05LayJHY0Qi8msMPm6Rkg9vr160JCMZiY9LwW8m 8wNzZ2O+g32PZr65G4OJg/JHg4Ivo7NcYgG+nG1cRGn1PJeV2+vUnufKgxbsKtCYvbNW lBMmDp4XsFZ/I3JuXp8U3EOZK7Hq5Zy+b5pcwW2KxNNPGkAVGoz6cIb7MNaRvr8Xpj+f RJinc0nfTi0IW/I/vZPq73Yzan2kHerfdcZtVHEmHDxSPnScPACi7ABbmme6DCvnRHSL TooA== X-Gm-Message-State: AE9vXwPZn3k42PzviDAtDMH79gk40SxPDImY5rXwFxdyy6gA+YZNHp5GeDkgBJxedFhvjdl12KIIa/WiHaLUBg== X-Received: by 10.31.190.147 with SMTP id o141mr3067549vkf.133.1472236167833; Fri, 26 Aug 2016 11:29:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.85.212 with HTTP; Fri, 26 Aug 2016 11:29:07 -0700 (PDT) In-Reply-To: References: From: Alexander Roscoe Date: Fri, 26 Aug 2016 14:29:07 -0400 Message-ID: To: David Bird Content-Type: multipart/alternative; boundary=001a1143a438cf33c2053afdb1eb Archived-At: Cc: "captive-portals@ietf.org" , Dave Dolson Subject: Re: [Captive-portals] IPv6 RA URI option X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 26 Aug 2016 18:29:31 -0000 --001a1143a438cf33c2053afdb1eb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi David, I am not too familiar with CoovaChili internals, does the hijacking routine add the string params(station/session) to the DHCP option or is it scripted to use the option82 data and add the parameters after the user goes to http://:/prelogin? On Fri, Aug 26, 2016 at 2:00 PM, David Bird wrote: > RFC 7710 says, ".. provides the URI to access an authentication page." > Obviously, this will need further clarification should it point to an API > end-point. As it is written, I think it is clear that the URI should be t= he > same (or will redirect you to the same) URL as a HTTP hijack takes you to > (minus any "original URL"). > > In CoovaChilli, at least, there is already an internal/local URL that is > suitable for RFC7710. In that the URL http://:/prelogin in > chilli hooks into the hijacking routine to redirect the user to the capti= ve > portal URL specific to them (e.g. the hijacking routine adds the query > string params specific to station/session). > > https://github.com/coova/coova-chilli/pull/274/commits/ > 1e95a2cf97e981f2f53826e38cd12372555a809c > > > On Fri, Aug 26, 2016 at 10:08 AM, Dave Dolson > wrote: > >> Alexander, >> >> Suppose instead of providing a URL for the landing page, the RA provided >> the URI for a standardized REST interface; the client could post its >> details (MAC address, device type?) to this interface, which would retur= n >> the URL for the browser landing page, and possibly any number of other >> details and mechanisms, e.g., in a JSON response. >> >> >> >> This adds a level of indirection that simplifies what needs to go in the >> RA. >> >> >> >> I think there is also flexibility in letting the client know details >> about the capport situation in the API. E.g., how often will the page ne= ed >> to be visited? >> >> >> >> RA-->client: =E2=80=9CThis is the URI for getting capport info: >> http://capport.example.com/api=E2=80=9D >> >> Client-->capport/api: =E2=80=9CMy MAC address is 01:02:03:04:05:06 and m= y IP >> address is =E2=80=A6=E2=80=9D >> >> Capport/api-->client: =E2=80=9CYour landing page is >> https://capport.example.com/landing/mac=3D01:02:03:04:05:06 ; refresh >> every 60min=E2=80=9D >> >> >> >> >> >> >> >> -Dave >> >> >> >> >> >> *From:* Captive-portals [mailto:captive-portals-bounces@ietf.org] *On >> Behalf Of *Alexander Roscoe >> *Sent:* Friday, August 26, 2016 11:15 AM >> *To:* captive-portals@ietf.org >> *Subject:* [Captive-portals] IPv6 RA URI option >> >> >> >> I am looking over RFC 7710 >> concerning how the URI is communicated to the end user. I really like t= he >> IPv4 DHCP solution, I think this could easily be implemented in a DHCP >> server. I think it could be easily implemented in the RA for IPv6 as we= ll >> however I do see a challenge when each connected client needs a unique U= RI >> such as it containing the parameter for the client mac. For example, a u= rl >> like https://captiveportal/?client-mac=3D11:22:33:44:55:66. The RA is se= nt >> to everyone and cannot be tailored to each client while DHCP is very cli= ent >> specific and can be changed on-the-fly. Most captive portals rely on th= e >> client mac address during the authentication process. I am aware of >> networks using the IP address to associate the user at the AAA server bu= t >> from my understanding this is a rare network setup. I think a potential >> solution for the IPv6 RA would be to define an HTTP POST parameter in wh= ich >> the client can use like =E2=80=98client-mac=E2=80=99 and let the client = post it the URI >> https://captiveporta/. Thoughts? Ideas? >> >> >> -- >> Alexander Roscoe >> 484-716-9048 >> >> _______________________________________________ >> Captive-portals mailing list >> Captive-portals@ietf.org >> https://www.ietf.org/mailman/listinfo/captive-portals >> >> > --=20 Alexander Roscoe 484-716-9048 --001a1143a438cf33c2053afdb1eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi David,

I am not too familiar with Co= ovaChili internals, =C2=A0does the hijacking routine add the string params(= station/session) to the DHCP option or is it scripted to use the option82 d= ata and add the parameters after the user goes to=C2=A0http://<nas-ip>:<port>/= prelogin?

On Fri, Aug 26, 2016 at 2:00 PM, D= avid Bird <dbird@google.com> wrote:
RFC 7710 says, "..=C2=A0provides the URI to access an=C2=A0authentication page.&= quot; Obviously, this will need further clarification should it point to an= API end-point. As it is written, I think it is clear that the URI should b= e the same (or will redirect you to the same) URL as a HTTP hijack takes yo= u to (minus any "original URL").

In CoovaChilli, at least, there is already = an internal/local URL that is suitable for RFC7710. In that the URL http://= <nas-ip>:<port>/prelogin in chilli hooks into the hijackin= g routine to redirect the user to the captive portal URL specific to them (= e.g. the hijacking routine adds the query string params specific to station= /session).



On Fri, Aug 26, 2016 at 10:08 AM, Dave Dolson <ddolson@sandvine.com<= /a>> wrote:

Alexander,<= /span>

Suppose instead of provid= ing a URL for the landing page, the RA provided the URI for a standardized = REST interface; the client could post its details (MAC address, device type?) to this interface, which would return the URL for the browse= r landing page, and possibly any number of other details and mechanisms, e.= g., in a JSON response.

=C2=A0

This adds a level of indi= rection that simplifies what needs to go in the RA.

=C2=A0

I think there is also fle= xibility in letting the client know details about the capport situation in = the API. E.g., how often will the page need to be visited?

=C2=A0

RA-->client:=C2=A0 =E2= =80=9CThis is the URI for getting capport info: http://capport.example.com/api= =E2=80=9D

Client-->capport/api: = =E2=80=9CMy MAC address is 01:02:03:04:05:06 and my IP address is =E2=80=A6= =E2=80=9D

Capport/api-->client: = =E2=80=9CYour landing page is https://capport.example.com/la= nding/mac=3D01:02:03:04:05:06 ; refresh every 60min=E2=80=9D

=C2=A0

=C2=A0

=C2=A0

-Dave

=C2=A0

=C2=A0

From: Captive-= portals [mailto:captive-portals-bounces@ietf.org] On Behalf Of Alexander Roscoe
Sent: Friday, August 26, 2016 11:15 AM
To: ca= ptive-portals@ietf.org
Subject: [Captive-portals] IPv6 RA URI option

=C2=A0

I am looking over RFC 7710 concerning how the URI is communicated to the end user.=C2=A0 = I really like the IPv4 DHCP solution, =C2=A0I think this could easily be im= plemented in a DHCP server.=C2=A0 I think it could be easily implemented in= the RA for IPv6 as well however I do see a challenge when each connected client needs a unique URI such as it containing the pa= rameter for the client mac. For example, a url like https://captiveportal/?client-mac=3D11:22:33:44:55:66. Th= e RA is sent to everyone and cannot be tailored to each client while DHCP i= s very client specific and can be changed on-the-fly.=C2=A0 Most captive portals rely on the client mac address during the authentication process. = I am aware of networks using the IP address to associate the user at the AA= A server but from my understanding this is a rare network setup.=C2=A0 I th= ink a potential solution for the IPv6 RA would be to define an HTTP POST parameter in which the client can use l= ike =E2=80=98client-mac=E2=80=99 and let the client post it the URI https://captiveporta/. =C2=A0 Thoughts? Ideas?


--
Alexander Roscoe
484-7= 16-9048


_______________________________________________
Captive-portals mailing list
Captive-porta= ls@ietf.org
https://www.ietf.org/mailman/listinfo/capt= ive-portals





--
Alexander Roscoe
484-716-9048
--001a1143a438cf33c2053afdb1eb-- From nobody Fri Aug 26 11:47:24 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB77D12D126 for ; Fri, 26 Aug 2016 11:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJM2yg9RaAcm for ; Fri, 26 Aug 2016 11:47:20 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2CE012D7D7 for ; Fri, 26 Aug 2016 11:47:10 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id f189so122185884oig.3 for ; Fri, 26 Aug 2016 11:47:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EnxAKJEIYutI/leNDEj/T/DJ0w7ZInWDMfTwqByL1O0=; b=CqiGIYjSRpoKFJKmbEUcXi3i9uNGWfP99Xo8eosKm9nVSjCH/2b+Kuk0PMZycWUQIZ OhpYsR2huY+Qcor7nMW+NIWaI7Ov1+Govaed79XfyI1Q40tJ0hkrhwtlLapPXgoA7U/X ZiKopNPuRfvStdwpAoI32cKvkdWTJ/zvO54XPLnvtP2XsassUYbqTr4weIyX6L8LmoD2 wzwAmEpBBfCh/w8JTIhArIo4wEUQZa6sVabRpj3cM1rHvDauyyQOnc+gtVYkwSC0EuzH 5IM/OQ9La8PghYd3b5rUB9gxkm6KBlkePrmJOBOaa1mYHJZUf1Z7WJWjGIDrND5vJYt4 RQjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EnxAKJEIYutI/leNDEj/T/DJ0w7ZInWDMfTwqByL1O0=; b=W+RE4vVMe4R4HS3tVTFgQuK96ULzhavS1Yuq4Jh3WnEuvLKlO8yl/MNfUOPAEKhMEG C7KvUWmQBgnnGUHwI3cNKikvY0AOdOCWVYuDngMbZ/dBIpSWGCtwXmSukpsKYoS1dTm8 PVj9HeByO+lP9751q0/zMvZMyqQzd5DNa1OllPGe/V+eZgDIDh3FbLlkKeL0fMxtLylF +To7rT0LxbnTyW3Z89A611cNClXim41l0/0NjMjPJ6p+yx4fhjcDNwUJKTUJosc6mf2r DLxuP0DAVF9b+YRhokIKnLWPBB4PGHEx/b7Py8vapB/BQppPxEbX0PdFH7ZJeS/RGPEH 27xQ== X-Gm-Message-State: AE9vXwO/uC6GoTFJpLmkp7YDa9eZ5Z9YsQrjEiMdnYvFbzdtaL/CJaEmZKdUxTbAbet8gvOuT4TVv7I9Nc4U59wK X-Received: by 10.202.85.14 with SMTP id j14mr3585642oib.18.1472237229979; Fri, 26 Aug 2016 11:47:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.175.19 with HTTP; Fri, 26 Aug 2016 11:47:09 -0700 (PDT) In-Reply-To: References: From: David Bird Date: Fri, 26 Aug 2016 11:47:09 -0700 Message-ID: To: Alexander Roscoe Content-Type: multipart/alternative; boundary=001a113d35aa1e83ee053afdf120 Archived-At: Cc: "captive-portals@ietf.org" , Dave Dolson Subject: Re: [Captive-portals] IPv6 RA URI option X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 26 Aug 2016 18:47:23 -0000 --001a113d35aa1e83ee053afdf120 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The DHCP option, once set, remains constant. The client learns the URL from DHCP Offer/ACK. For an example: Client sends DHCP Discover/Request NAS returns DHCP Offer/ACK containing: Assigned IP: 10.0.0.100 Gateway IP: 10.0.0.1 CAPPORT URI: http://10.0.0.1:3990/prelogin [Chilli is the daemon responding to DHCP and is listening on 10.0.0.1:3990] The client can issue a HTTP request to http://10.0.0.1:3990/prelogin and the NAS returns with a HTTP 302 redirect to something like https://my.domain/wifi?mac=3D... -- with session/station specific values. On Fri, Aug 26, 2016 at 11:29 AM, Alexander Roscoe < alexander.roscoe@gmail.com> wrote: > Hi David, > > I am not too familiar with CoovaChili internals, does the hijacking > routine add the string params(station/session) to the DHCP option or is i= t > scripted to use the option82 data and add the parameters after the user > goes to http://:/prelogin? > > On Fri, Aug 26, 2016 at 2:00 PM, David Bird wrote: > >> RFC 7710 says, ".. provides the URI to access an authentication page." >> Obviously, this will need further clarification should it point to an AP= I >> end-point. As it is written, I think it is clear that the URI should be = the >> same (or will redirect you to the same) URL as a HTTP hijack takes you t= o >> (minus any "original URL"). >> >> In CoovaChilli, at least, there is already an internal/local URL that is >> suitable for RFC7710. In that the URL http://:/prelogin in >> chilli hooks into the hijacking routine to redirect the user to the capt= ive >> portal URL specific to them (e.g. the hijacking routine adds the query >> string params specific to station/session). >> >> https://github.com/coova/coova-chilli/pull/274/commits/1e95a >> 2cf97e981f2f53826e38cd12372555a809c >> >> >> On Fri, Aug 26, 2016 at 10:08 AM, Dave Dolson >> wrote: >> >>> Alexander, >>> >>> Suppose instead of providing a URL for the landing page, the RA provide= d >>> the URI for a standardized REST interface; the client could post its >>> details (MAC address, device type?) to this interface, which would retu= rn >>> the URL for the browser landing page, and possibly any number of other >>> details and mechanisms, e.g., in a JSON response. >>> >>> >>> >>> This adds a level of indirection that simplifies what needs to go in th= e >>> RA. >>> >>> >>> >>> I think there is also flexibility in letting the client know details >>> about the capport situation in the API. E.g., how often will the page n= eed >>> to be visited? >>> >>> >>> >>> RA-->client: =E2=80=9CThis is the URI for getting capport info: >>> http://capport.example.com/api=E2=80=9D >>> >>> Client-->capport/api: =E2=80=9CMy MAC address is 01:02:03:04:05:06 and = my IP >>> address is =E2=80=A6=E2=80=9D >>> >>> Capport/api-->client: =E2=80=9CYour landing page is >>> https://capport.example.com/landing/mac=3D01:02:03:04:05:06 ; refresh >>> every 60min=E2=80=9D >>> >>> >>> >>> >>> >>> >>> >>> -Dave >>> >>> >>> >>> >>> >>> *From:* Captive-portals [mailto:captive-portals-bounces@ietf.org] *On >>> Behalf Of *Alexander Roscoe >>> *Sent:* Friday, August 26, 2016 11:15 AM >>> *To:* captive-portals@ietf.org >>> *Subject:* [Captive-portals] IPv6 RA URI option >>> >>> >>> >>> I am looking over RFC 7710 >>> concerning how the URI is communicated to the end user. I really like = the >>> IPv4 DHCP solution, I think this could easily be implemented in a DHCP >>> server. I think it could be easily implemented in the RA for IPv6 as w= ell >>> however I do see a challenge when each connected client needs a unique = URI >>> such as it containing the parameter for the client mac. For example, a = url >>> like https://captiveportal/?client-mac=3D11:22:33:44:55:66. The RA is >>> sent to everyone and cannot be tailored to each client while DHCP is ve= ry >>> client specific and can be changed on-the-fly. Most captive portals re= ly >>> on the client mac address during the authentication process. I am aware= of >>> networks using the IP address to associate the user at the AAA server b= ut >>> from my understanding this is a rare network setup. I think a potentia= l >>> solution for the IPv6 RA would be to define an HTTP POST parameter in w= hich >>> the client can use like =E2=80=98client-mac=E2=80=99 and let the client= post it the URI >>> https://captiveporta/. Thoughts? Ideas? >>> >>> >>> -- >>> Alexander Roscoe >>> 484-716-9048 >>> >>> _______________________________________________ >>> Captive-portals mailing list >>> Captive-portals@ietf.org >>> https://www.ietf.org/mailman/listinfo/captive-portals >>> >>> >> > > > -- > Alexander Roscoe > 484-716-9048 > --001a113d35aa1e83ee053afdf120 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The DHCP option, once set, remains constant. The client le= arns the URL from DHCP Offer/ACK.=C2=A0

For an example:<= /div>

Client sends DHCP Discover/Request
NAS r= eturns DHCP Offer/ACK containing:
=C2=A0 =C2=A0Assigned IP: 10.0.= 0.100
=C2=A0 Gateway IP: 10.0.0.1
=C2=A0 CAPPORT URI: <= a href=3D"http://10.0.0.1:3990/prelogin">http://10.0.0.1:3990/prelogin<= /div>

[Chilli is the daemon responding to DHCP and is li= stening on 10.0.0.1:3990]
The client can issue a HTTP request to http://10.0.0.1:3990/prelogin and the NAS returns wi= th a HTTP 302 redirect to something like https://my.domain/wifi?mac=3D... -- with session/station speci= fic values.


On Fri, Aug 26, 2016 at 11:29 AM, Alexander Roscoe <alexander.roscoe@gmail.com> wrote:
Hi David,

I am not too = familiar with CoovaChili internals, =C2=A0does the hijacking routine add th= e string params(station/session) to the DHCP option or is it scripted to us= e the option82 data and add the parameters after the user goes to=C2=A0http://<nas-ip>:<= port>/prelogin?

On Fri, Aug 26, 2016 at 2:00 PM, David Bir= d <dbird@google.com> wrote:
RFC 7710 says, "..=C2=A0provides the URI to access an=C2=A0authentication page." Obv= iously, this will need further clarification should it point to an API end-= point. As it is written, I think it is clear that the URI should be the sam= e (or will redirect you to the same) URL as a HTTP hijack takes you to (min= us any "original URL").

In CoovaChilli, at least, there is already an intern= al/local URL that is suitable for RFC7710. In that the URL http://<nas-i= p>:<port>/prelogin in chilli hooks into the hijacking routine= to redirect the user to the captive portal URL specific to them (e.g. the = hijacking routine adds the query string params specific to station/session)= .


On Fri, Aug 26, 2016 at 10:08 AM, Dave Dolson <ddol= son@sandvine.com> wrote:

Alexander,<= /span>

Suppose instead of provid= ing a URL for the landing page, the RA provided the URI for a standardized = REST interface; the client could post its details (MAC address, device type?) to this interface, which would return the URL for the browse= r landing page, and possibly any number of other details and mechanisms, e.= g., in a JSON response.

=C2=A0

This adds a level of indi= rection that simplifies what needs to go in the RA.

=C2=A0

I think there is also fle= xibility in letting the client know details about the capport situation in = the API. E.g., how often will the page need to be visited?

=C2=A0

RA-->client:=C2=A0 =E2= =80=9CThis is the URI for getting capport info: http://capport.example.com/api= =E2=80=9D

Client-->capport/api: = =E2=80=9CMy MAC address is 01:02:03:04:05:06 and my IP address is =E2=80=A6= =E2=80=9D

Capport/api-->client: = =E2=80=9CYour landing page is https://capport.example.com/la= nding/mac=3D01:02:03:04:05:06 ; refresh every 60min=E2=80=9D

=C2=A0

=C2=A0

=C2=A0

-Dave

=C2=A0

=C2=A0

From: Captive-= portals [mailto:captive-portals-bounces@ietf.org] On Behalf Of Alexander Roscoe
Sent: Friday, August 26, 2016 11:15 AM
To: ca= ptive-portals@ietf.org
Subject: [Captive-portals] IPv6 RA URI option

=C2=A0

I am looking over RFC 7710 concerning how the URI is communicated to the end user.=C2=A0 = I really like the IPv4 DHCP solution, =C2=A0I think this could easily be im= plemented in a DHCP server.=C2=A0 I think it could be easily implemented in= the RA for IPv6 as well however I do see a challenge when each connected client needs a unique URI such as it containing the pa= rameter for the client mac. For example, a url like https://captiveportal/?client-mac=3D11:22:33:44:55:66. Th= e RA is sent to everyone and cannot be tailored to each client while DHCP i= s very client specific and can be changed on-the-fly.=C2=A0 Most captive portals rely on the client mac address during the authentication process. = I am aware of networks using the IP address to associate the user at the AA= A server but from my understanding this is a rare network setup.=C2=A0 I th= ink a potential solution for the IPv6 RA would be to define an HTTP POST parameter in which the client can use l= ike =E2=80=98client-mac=E2=80=99 and let the client post it the URI https://captiveporta/. =C2=A0 Thoughts? Ideas?


--
Alexander Roscoe
484-7= 16-9048


_______________________________________________
Captive-portals mailing list
Captive-porta= ls@ietf.org
https://www.ietf.org/mailman/listinfo/capt= ive-portals





--
Alexander Rosco= e

--001a113d35aa1e83ee053afdf120-- From nobody Fri Aug 26 12:16:48 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60AA612D181 for ; Fri, 26 Aug 2016 12:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmpdPLx63ETD for ; Fri, 26 Aug 2016 12:16:44 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD61B12D187 for ; Fri, 26 Aug 2016 12:16:43 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id k90so154040536uak.1 for ; Fri, 26 Aug 2016 12:16:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9OP4Gq/MEctC/cyEeTTRliFyDqTTFC8cRGa3NhAeQTw=; b=QW/1eQYJ3hwgpZj2ahQhRikgelFvzVeH7X1G2+Bh9YZS137iAOk0KKZRblU+jHwcx0 L310OthwqGUFh6jH6jKLPh/Yi8mRUUqGOcPjQnm0a0npQNe+l/EgXIpQwAjOogZ5yEDo WHHYLtrjVzXpQ1YhdtAMtSGhox0yQLZOhcVSoUaBWY5Dk0Wv7lBk+rV2GhwHsvbzWF1f rQrmt+ynnjDvysRIQw8s2rv+lX6Tt2HavBZcdf8x8F/Q5lq2+PM6WGWdwHLSgq5LyMVz kvDPTImxVYgnWJFt+axtUDvxrxZyS1nLTwr/uOKXX/CHOWSypJ0LPEGSNUs0zQcWLHx4 HIsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9OP4Gq/MEctC/cyEeTTRliFyDqTTFC8cRGa3NhAeQTw=; b=YRwpPg6C9yTyTw8z7iVF8nHpbJEAWrFJkZkxycqqTabSlOXgpY4j+ic62huxMICsJH 4/T+GnBl1lSlEuuGY2KTz5/D7xahLJEhsHQ5QVAsdmNIGElq9FRHmWYT1QXWl+Q2XZos TJr9IUBwOD6cWbCgOfVTgITY85miW8JOUzwsrW7uuN1zlptp36D9cXvU9ZBfvs8/YxaV TNnja7bymjHNJcuuEG0wHF3EP4efQl2uIp3f9HLh4vgRihZUL6crkBi6nBBxTsXOZ++M rf3RL98dPjsf3DYToT5V2RtM6Qqiyvuz9jCPZpzgrEYSxk7cccTiMzSURtcfXGQgqR2X gBgw== X-Gm-Message-State: AE9vXwN8Rb94Sbk+omyrC2w+NLmTiJ9goG6B4jwXZxCbuG+e4C4yQc+Y7aE1KJTPXPDg3ESbqnPvjrRDKIWcTQ== X-Received: by 10.31.129.11 with SMTP id c11mr3069018vkd.25.1472239002940; Fri, 26 Aug 2016 12:16:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.85.212 with HTTP; Fri, 26 Aug 2016 12:16:22 -0700 (PDT) In-Reply-To: References: From: Alexander Roscoe Date: Fri, 26 Aug 2016 15:16:22 -0400 Message-ID: To: David Bird Content-Type: multipart/alternative; boundary=001a11458bbecb8280053afe5a43 Archived-At: Cc: "captive-portals@ietf.org" , Dave Dolson Subject: Re: [Captive-portals] IPv6 RA URI option X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 26 Aug 2016 19:16:46 -0000 --001a11458bbecb8280053afe5a43 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thats a clever way of doing it, that would solve the IPv6 issue as well. On Fri, Aug 26, 2016 at 2:47 PM, David Bird wrote: > The DHCP option, once set, remains constant. The client learns the URL > from DHCP Offer/ACK. > > For an example: > > Client sends DHCP Discover/Request > NAS returns DHCP Offer/ACK containing: > Assigned IP: 10.0.0.100 > Gateway IP: 10.0.0.1 > CAPPORT URI: http://10.0.0.1:3990/prelogin > > [Chilli is the daemon responding to DHCP and is listening on 10.0.0.1:399= 0 > ] > > The client can issue a HTTP request to http://10.0.0.1:3990/prelogin and > the NAS returns with a HTTP 302 redirect to something like > https://my.domain/wifi?mac=3D... -- with session/station specific values. > > > On Fri, Aug 26, 2016 at 11:29 AM, Alexander Roscoe < > alexander.roscoe@gmail.com> wrote: > >> Hi David, >> >> I am not too familiar with CoovaChili internals, does the hijacking >> routine add the string params(station/session) to the DHCP option or is = it >> scripted to use the option82 data and add the parameters after the user >> goes to http://:/prelogin? >> >> On Fri, Aug 26, 2016 at 2:00 PM, David Bird wrote: >> >>> RFC 7710 says, ".. provides the URI to access an authentication page." >>> Obviously, this will need further clarification should it point to an A= PI >>> end-point. As it is written, I think it is clear that the URI should be= the >>> same (or will redirect you to the same) URL as a HTTP hijack takes you = to >>> (minus any "original URL"). >>> >>> In CoovaChilli, at least, there is already an internal/local URL that i= s >>> suitable for RFC7710. In that the URL http://:/prelogin >>> in chilli hooks into the hijacking routine to redirect the user to the >>> captive portal URL specific to them (e.g. the hijacking routine adds th= e >>> query string params specific to station/session). >>> >>> https://github.com/coova/coova-chilli/pull/274/commits/1e95a >>> 2cf97e981f2f53826e38cd12372555a809c >>> >>> >>> On Fri, Aug 26, 2016 at 10:08 AM, Dave Dolson >>> wrote: >>> >>>> Alexander, >>>> >>>> Suppose instead of providing a URL for the landing page, the RA >>>> provided the URI for a standardized REST interface; the client could p= ost >>>> its details (MAC address, device type?) to this interface, which would >>>> return the URL for the browser landing page, and possibly any number o= f >>>> other details and mechanisms, e.g., in a JSON response. >>>> >>>> >>>> >>>> This adds a level of indirection that simplifies what needs to go in >>>> the RA. >>>> >>>> >>>> >>>> I think there is also flexibility in letting the client know details >>>> about the capport situation in the API. E.g., how often will the page = need >>>> to be visited? >>>> >>>> >>>> >>>> RA-->client: =E2=80=9CThis is the URI for getting capport info: >>>> http://capport.example.com/api=E2=80=9D >>>> >>>> Client-->capport/api: =E2=80=9CMy MAC address is 01:02:03:04:05:06 and= my IP >>>> address is =E2=80=A6=E2=80=9D >>>> >>>> Capport/api-->client: =E2=80=9CYour landing page is >>>> https://capport.example.com/landing/mac=3D01:02:03:04:05:06 ; refresh >>>> every 60min=E2=80=9D >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -Dave >>>> >>>> >>>> >>>> >>>> >>>> *From:* Captive-portals [mailto:captive-portals-bounces@ietf.org] *On >>>> Behalf Of *Alexander Roscoe >>>> *Sent:* Friday, August 26, 2016 11:15 AM >>>> *To:* captive-portals@ietf.org >>>> *Subject:* [Captive-portals] IPv6 RA URI option >>>> >>>> >>>> >>>> I am looking over RFC 7710 >>>> concerning how the URI is communicated to the end user. I really like= the >>>> IPv4 DHCP solution, I think this could easily be implemented in a DHC= P >>>> server. I think it could be easily implemented in the RA for IPv6 as = well >>>> however I do see a challenge when each connected client needs a unique= URI >>>> such as it containing the parameter for the client mac. For example, a= url >>>> like https://captiveportal/?client-mac=3D11:22:33:44:55:66. The RA is >>>> sent to everyone and cannot be tailored to each client while DHCP is v= ery >>>> client specific and can be changed on-the-fly. Most captive portals r= ely >>>> on the client mac address during the authentication process. I am awar= e of >>>> networks using the IP address to associate the user at the AAA server = but >>>> from my understanding this is a rare network setup. I think a potenti= al >>>> solution for the IPv6 RA would be to define an HTTP POST parameter in = which >>>> the client can use like =E2=80=98client-mac=E2=80=99 and let the clien= t post it the URI >>>> https://captiveporta/. Thoughts? Ideas? >>>> >>>> >>>> -- >>>> Alexander Roscoe >>>> 484-716-9048 >>>> >>>> _______________________________________________ >>>> Captive-portals mailing list >>>> Captive-portals@ietf.org >>>> https://www.ietf.org/mailman/listinfo/captive-portals >>>> >>>> >>> >> >> >> -- >> Alexander Roscoe >> 484-716-9048 >> > > --=20 Alexander Roscoe 484-716-9048 --001a11458bbecb8280053afe5a43 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thats a clever way of doing it, that would solve the IPv6 = issue as well. =C2=A0

On Fri, Aug 26, 2016 at 2:47 PM, David Bird <= ;dbird@google.com= > wrote:
The D= HCP option, once set, remains constant. The client learns the URL from DHCP= Offer/ACK.=C2=A0

For an example:

Client sends DHCP Discover/Request
NAS returns DHCP Offer/ACK = containing:
=C2=A0 =C2=A0Assigned IP: 10.0.0.100
=C2=A0= Gateway IP: 10.0.0.1
=C2=A0 CAPPORT URI: http://10.0.0.1:3990/prelogin

[Chilli is the daemon responding to DHCP and is listen= ing on 10.0.0.1:3990= ]

The client can issue a HTTP request to http://10.0.0.1:3990/p= relogin and the NAS returns with a HTTP 302 redirect to something like = https://my.dom= ain/wifi?mac=3D... -- with session/station specific values.
<= br>

On Fri, Aug 26, 2016 at 11:29 AM, Ale= xander Roscoe <alexander.roscoe@gmail.com> wrote:
Hi David,

<= div>I am not too familiar with CoovaChili internals, =C2=A0does the hijacki= ng routine add the string params(station/session) to the DHCP option or is = it scripted to use the option82 data and add the parameters after the user = goes to=C2=A0http://&l= t;nas-ip>:<port>/prelogin?

On Fri, Aug 26, 2016 at 2:00 PM, David= Bird <dbird@google.com> wrote:
RFC 7710 says, "..=C2=A0provides the URI to access an=C2=A0authentication page."= Obviously, this will need further clarification should it point to an API = end-point. As it is written, I think it is clear that the URI should be the= same (or will redirect you to the same) URL as a HTTP hijack takes you to = (minus any "original URL").

In CoovaChilli, at least, there is already an in= ternal/local URL that is suitable for RFC7710. In that the URL http://<n= as-ip>:<port>/prelogin in chilli hooks into the hijacking rou= tine to redirect the user to the captive portal URL specific to them (e.g. = the hijacking routine adds the query string params specific to station/sess= ion).



On Fri, Aug 26,= 2016 at 10:08 AM, Dave Dolson <ddolson@sandvine.com> wro= te:

Alexander,<= /span>

Suppose instead of provid= ing a URL for the landing page, the RA provided the URI for a standardized = REST interface; the client could post its details (MAC address, device type?) to this interface, which would return the URL for the browse= r landing page, and possibly any number of other details and mechanisms, e.= g., in a JSON response.

=C2=A0

This adds a level of indi= rection that simplifies what needs to go in the RA.

=C2=A0

I think there is also fle= xibility in letting the client know details about the capport situation in = the API. E.g., how often will the page need to be visited?

=C2=A0

RA-->client:=C2=A0 =E2= =80=9CThis is the URI for getting capport info: http://capport.example.com/api= =E2=80=9D

Client-->capport/api: = =E2=80=9CMy MAC address is 01:02:03:04:05:06 and my IP address is =E2=80=A6= =E2=80=9D

Capport/api-->client: = =E2=80=9CYour landing page is https://capport.example.com/la= nding/mac=3D01:02:03:04:05:06 ; refresh every 60min=E2=80=9D

=C2=A0

=C2=A0

=C2=A0

-Dave

=C2=A0

=C2=A0

From: Captive-= portals [mailto:captive-portals-bounces@ietf.org] On Behalf Of Alexander Roscoe
Sent: Friday, August 26, 2016 11:15 AM
To: ca= ptive-portals@ietf.org
Subject: [Captive-portals] IPv6 RA URI option

=C2=A0

I am looking over RFC 7710 concerning how the URI is communicated to the end user.=C2=A0 = I really like the IPv4 DHCP solution, =C2=A0I think this could easily be im= plemented in a DHCP server.=C2=A0 I think it could be easily implemented in= the RA for IPv6 as well however I do see a challenge when each connected client needs a unique URI such as it containing the pa= rameter for the client mac. For example, a url like https://captiveportal/?client-mac=3D11:22:33:44:55:66. Th= e RA is sent to everyone and cannot be tailored to each client while DHCP i= s very client specific and can be changed on-the-fly.=C2=A0 Most captive portals rely on the client mac address during the authentication process. = I am aware of networks using the IP address to associate the user at the AA= A server but from my understanding this is a rare network setup.=C2=A0 I th= ink a potential solution for the IPv6 RA would be to define an HTTP POST parameter in which the client can use l= ike =E2=80=98client-mac=E2=80=99 and let the client post it the URI https://captiveporta/. =C2=A0 Thoughts? Ideas?


--
Alexander Roscoe
484-7= 16-9048


_______________________________________________
Captive-portals mailing list
Captive-porta= ls@ietf.org
https://www.ietf.org/mailman/listinfo/capt= ive-portals





<= font color=3D"#888888">--
Alexa= nder Roscoe




--
=
Alexander= Roscoe
484-716-9048
--001a11458bbecb8280053afe5a43-- From nobody Tue Aug 30 14:50:11 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D50812D80F for ; Tue, 30 Aug 2016 14:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K_T0yjRj1VdX for ; Tue, 30 Aug 2016 14:50:07 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00F9812D81D for ; Tue, 30 Aug 2016 14:50:06 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id l94so57041908ual.0 for ; Tue, 30 Aug 2016 14:50:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=VXfUCh8RByjBX5j3ZXpwKGF4I6oH8oI3641Vld1peO0=; b=pc41BVkXymRezhYRdIOxJb9CQrtcrPzwzs4KOLJhLI++Ce2TiphMv+L2Eq0JC9KgGr YAQth1UxIMq62EgUypmp79J25bkTACnZ78J7WS3uuATps7xubWv4mHnGD6OWZQUGsciO yLAC7HjHY+N0fMfWii/lFwBHCFh5f/8tSVJqey9qD9b9pbtq9AGzzByusCJV4XGykl2P JuQNsSCdJx0Td8HT6x/tasC2quoN83i9ZjhCmO5bPJTMyWRwP82YsZvcdiaxUkJSGb6J Yvr2eCkvC+okaUCroIGvH+YvEOKkt2o70EMx6M+2UKGlqablOK7M92/GantL17awE2uI zdwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=VXfUCh8RByjBX5j3ZXpwKGF4I6oH8oI3641Vld1peO0=; b=PTAijlFNV102N80lYXgT4g3iJGGS1itSjb7+vXoHWEwxLM74lKuPfV2XAsSkGqg4cH 4e2AhGditKuSe3mME9ttOMHvT8MhJNAs+UjaZmbEllmBHbeIFxN18k4GnGaU35+rNTvx 6HLtK9+PMlQF8MGWcardE72rmYBAyZpDdTZ68J48cU7SQvEGUI5g3JKrNzl1zdZbNDIN 7wYf4Z7LoRcRJtQFOuaikIK62s7ga8mBAi9J4iOzksLZ8FMiLBYePWjgqXEuL7BNEw4O zM8Un1ZaNr/vN+McLWX1Q+zkqQG6BQrLaacGHFEEuPZF/mh4pyG9it6HNBclX9QYgT7w B+BQ== X-Gm-Message-State: AE9vXwPbCYRFxBj/nq4/IxEEizM8007u1pznQejP64zvDycjofjtRGjX35iX+UOo1NLwZeiYGngHuQcoHA6jKQ== X-Received: by 10.31.7.73 with SMTP id 70mr3573226vkh.157.1472593804736; Tue, 30 Aug 2016 14:50:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.129.85 with HTTP; Tue, 30 Aug 2016 14:49:44 -0700 (PDT) From: Alexander Roscoe Date: Tue, 30 Aug 2016 17:49:44 -0400 Message-ID: To: captive-portals@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Captive-portals] API / ICMP for status and remaining time X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 30 Aug 2016 21:50:10 -0000 I am looking at the mechanisms to communicate captive portal states to users. I think a RESTful API would be viable candidate for communicating this information. The same URL from RFC7710 or the URL given by the 302 redirect could be used to as the endpoint for this service as well. Clients could reach out to this endpoint to get status such as "Time Remaining" or "TX/RX transferred". RESTful interfaces can be easily setup and can be easily extended to add new features. Along side REST, I was looking at the ICMP as a conduit to transmit this information as well. Information could be pushed to the clients' device and then digested rather than pulled like a RESTful protocol. I think an implementation of this setup could work well on a deployment where the AAA server resides on the same system as the gateway because the information in the ICMP is easily accessible. When the AAA server exists on another system it may pose a problem. For example, many networks that use captive portals block external ICMP messages and/or NAT devices to client, therefore the gateway would need to proxy these packets. This adds more complexity to the network design. Also, ICMP message would be very rigid and not as extendable as a RESTful service. Maybe rigid might be a good thing? Thoughts? Did I miss another type of conduit to transfer status... excluding SOAP :) -- Alexander Roscoe 484-716-9048 From nobody Tue Aug 30 16:52:00 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6822C12D835 for ; Tue, 30 Aug 2016 16:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-di8pk_ghLo for ; Tue, 30 Aug 2016 16:51:57 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6048812D84A for ; Tue, 30 Aug 2016 16:51:57 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id w2so9080124wmd.0 for ; Tue, 30 Aug 2016 16:51:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WghoqtzjyYq30KjnxNi31W7Izo+5DSVAPBcqbRhXpyc=; b=Lppzk35eJKDvki+kBAc8bkyvuxhG4YG2zNOMIQf0r4XjdERii946nfRS33dC8X872x KrHzsncHisVo5AHy7fJpSVC52TlZzWMWOO8Y3nWkSNYIYK8ZFjGHYgQyc4tDXPzcl0gp sMrAFSHiSv9AsEipxYPg7cLuk+9prX8Zl1DEofBtHFTJZcXuXRRufPrOWzCc/xdkW9a6 xMS7oHxbRhRb6UOgg8T6kA1l8ZIPQ7BYQ6XKPN8GEOow+bY4QJmoo4gNzDfUuuqfIE53 WP0HnQYTbpwucEjhCi9UPLpsmEiLw9kRvgtl0w8GbxFDASyz0pHLncS+3CKQ8xrO7bYs x6qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WghoqtzjyYq30KjnxNi31W7Izo+5DSVAPBcqbRhXpyc=; b=kzNL278E2ZxdGeHIlxikusKHNjsWC09MZjGyYp8itgZiRMEx4dhJcQWTTs8zSKX4Cw TaH5O+LekLu8QHK/tPqdJFrN9K96hxOx16KVjHsQwdP5wGb14YGBzkeH0Y3+UepfDzdo R5gIfQA3Y5YbaUDV/bWvRI3zHCy7xiTG6UFeeYLbLyDxK1bUNFEWqVwiD67XVhQ3077i SbqDk68kEfPKFki3hO+wfdbmJ9Ab76AWpAaTODtwJSNkdjNgwi3hss/9GCgEfyCKKPCa lHlazEEdTYam8QXm6C5w+u1p0yqCVGI0OvfCi6KeX5qHHJUJ/SpVi+45m0ps6k5usivx pSqA== X-Gm-Message-State: AE9vXwOpHz1fBZB6YhF8tqyS0de0IV8Jpv0jY9YjqIo2hQeETtjGqsJfwz3jGMW/TJwvozAhmJGWK4lkaZqdh0+A X-Received: by 10.194.61.164 with SMTP id q4mr874054wjr.89.1472601115739; Tue, 30 Aug 2016 16:51:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.157.2 with HTTP; Tue, 30 Aug 2016 16:51:35 -0700 (PDT) In-Reply-To: References: From: Erik Kline Date: Wed, 31 Aug 2016 08:51:35 +0900 Message-ID: To: Alexander Roscoe Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: captive-portals@ietf.org Subject: Re: [Captive-portals] API / ICMP for status and remaining time X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 30 Aug 2016 23:51:59 -0000 I would say please don't hack stuff into ICMP. It will be easier for client platforms (mobile devices, laptop OSes, ...) to whip up a simple REST app than update ICMP handling. Yes the latter is certainly doable, but a REST API will be so much more capable and future-proof, IMHO. If this working group worked to spec v1 of the API that would make sense to me. :) On 31 August 2016 at 06:49, Alexander Roscoe wrote: > I am looking at the mechanisms to communicate captive portal states to > users. I think a RESTful API would be viable candidate for > communicating this information. The same URL from RFC7710 or the URL > given by the 302 redirect could be used to as the endpoint for this > service as well. Clients could reach out to this endpoint to get > status such as "Time Remaining" or "TX/RX transferred". RESTful > interfaces can be easily setup and can be easily extended to add new > features. > > Along side REST, I was looking at the ICMP as a conduit to transmit > this information as well. Information could be pushed to the clients' > device and then digested rather than pulled like a RESTful protocol. > I think an implementation of this setup could work well on a > deployment where the AAA server resides on the same system as the > gateway because the information in the ICMP is easily accessible. > When the AAA server exists on another system it may pose a problem. > For example, many networks that use captive portals block external > ICMP messages and/or NAT devices to client, therefore the gateway > would need to proxy these packets. This adds more complexity to the > network design. Also, ICMP message would be very rigid and not as > extendable as a RESTful service. Maybe rigid might be a good thing? > > Thoughts? Did I miss another type of conduit to transfer status... > excluding SOAP :) > > -- > Alexander Roscoe > 484-716-9048 > > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals From nobody Tue Aug 30 18:07:37 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5288112D83E for ; Tue, 30 Aug 2016 18:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKHrsXEfKRUz for ; Tue, 30 Aug 2016 18:07:34 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B42812D81A for ; Tue, 30 Aug 2016 18:07:34 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id l203so50566834oib.1 for ; Tue, 30 Aug 2016 18:07:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F5kVcSu646OnKwkyf4o86m04WTl4PX9nioU8Rxf5+GU=; b=UJakpvs/rNTWFqW+96ynJJ2ZFSzpwpR/eKq9XtsDOvX/4Jic0lP87hQV+xH/79XNSV /dfzz/XQXJePBQIco+/L6wnz8bQnc/sGMujY+bahJb3m8+oLfGoIcAqWRFFrh5vxM1Yc 7uDb1ngSiJSHcGvIka/xBk+deFWskM9JCwEiFGXihk1jwch7CQXMGlQcKFOjvF70SoZ6 vN/bVC/TuRRqI3AC5A/QDmOCdpMv/ngbzX48oJYAbE2YOEjxlmU+7zDdq7RUyDQrM15K 5LEGCmGQaaxA+S12Dm6aOAAhcgDaOulNrts0BoveA+yDZcePAFv16fD45D2Bn0H/FWqA DqPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=F5kVcSu646OnKwkyf4o86m04WTl4PX9nioU8Rxf5+GU=; b=Fxz80rrrg5AUDyHHprLvkFm5k6cF+rxpLlrdJoYt0/eggVW5u2uttfv7a6rfp6rrLX XUjHsznw9oVMWxQ8m1AyjFrUOEDPkskPH7JPpt1u3cO8dyDsDrerREYE6KNNdxi7wWhL 4Zr+wbiNtCTObAHrHOCg85ui/395FKDQewhqm1PTijSIS0EU0ZArw03eCFYw0iafM8+H ipm3lmWkPuubdEpKuYKDuwJaNajWfmhZpOtOFsPBMUIlGBXLPp1FEu/J8jnGYoNmwgQ8 h/yLa6CIXHF2mUO7sMldPyL27J/2nUS3Zrh6GkD+BPXHF8jO17o1fe2vRmyqwd4tXIdP 6l/Q== X-Gm-Message-State: AE9vXwNW4dX/jlBKL0uF6sALwOUuZsWBOS6p2WDM7gIVaaB8ZUvyMbXPCWkGzpbt49xqKeuydrCiot/PD42FdbS+ X-Received: by 10.202.73.197 with SMTP id w188mr7390674oia.67.1472605653318; Tue, 30 Aug 2016 18:07:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.175.19 with HTTP; Tue, 30 Aug 2016 18:07:32 -0700 (PDT) In-Reply-To: References: From: David Bird Date: Tue, 30 Aug 2016 18:07:32 -0700 Message-ID: To: Alexander Roscoe Content-Type: multipart/alternative; boundary=001a1134fb1adc82ed053b53b86e Archived-At: Cc: captive-portals@ietf.org Subject: Re: [Captive-portals] API / ICMP for status and remaining time X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 31 Aug 2016 01:07:36 -0000 --001a1134fb1adc82ed053b53b86e Content-Type: text/plain; charset=UTF-8 I believe ICMP is useful for realtime, 5-tuple flow specific (as well as general), notifications, but it should not be used to carry any session parameters or meaningful data. A REST API would be better for that. On Tue, Aug 30, 2016 at 2:49 PM, Alexander Roscoe < alexander.roscoe@gmail.com> wrote: > I am looking at the mechanisms to communicate captive portal states to > users. I think a RESTful API would be viable candidate for > communicating this information. The same URL from RFC7710 or the URL > given by the 302 redirect could be used to as the endpoint for this > service as well. Clients could reach out to this endpoint to get > status such as "Time Remaining" or "TX/RX transferred". RESTful > interfaces can be easily setup and can be easily extended to add new > features. > > Along side REST, I was looking at the ICMP as a conduit to transmit > this information as well. Information could be pushed to the clients' > device and then digested rather than pulled like a RESTful protocol. > I think an implementation of this setup could work well on a > deployment where the AAA server resides on the same system as the > gateway because the information in the ICMP is easily accessible. > When the AAA server exists on another system it may pose a problem. > For example, many networks that use captive portals block external > ICMP messages and/or NAT devices to client, therefore the gateway > would need to proxy these packets. This adds more complexity to the > network design. Also, ICMP message would be very rigid and not as > extendable as a RESTful service. Maybe rigid might be a good thing? > > Thoughts? Did I miss another type of conduit to transfer status... > excluding SOAP :) > > -- > Alexander Roscoe > 484-716-9048 > > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals > --001a1134fb1adc82ed053b53b86e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I believe ICMP is useful for realtime, 5-tuple flow specif= ic (as well as general), notifications, but it should not be used to carry = any session parameters or meaningful data. A REST API would be better for t= hat.=C2=A0

O= n Tue, Aug 30, 2016 at 2:49 PM, Alexander Roscoe <alexander.rosco= e@gmail.com> wrote:
I am lo= oking at the mechanisms to communicate captive portal states to
users. I think a RESTful API would be viable candidate for
communicating this information.=C2=A0 The same URL from RFC7710 or the URL<= br> given by the 302 redirect could be used to as the endpoint for this
service as well.=C2=A0 Clients could reach out to this endpoint to get
status such as "Time Remaining" or "TX/RX transferred".= =C2=A0 RESTful
interfaces can be easily setup and can be easily extended to add new
features.

Along side REST, I was looking at the ICMP as a conduit to transmit
this information as well.=C2=A0 Information could be pushed to the clients&= #39;
device and then digested rather than pulled like a RESTful protocol.
I think an implementation of this setup could work well on a
deployment where the AAA server resides on the same system as the
gateway because the information in the ICMP is easily accessible.
When the AAA server exists on another system it may pose a problem.
For example, many networks that use captive portals block external
ICMP messages and/or NAT devices to client, therefore the gateway
would need to proxy these packets.=C2=A0 This adds more complexity to the network design. Also, ICMP message would be very rigid and not as
extendable as a RESTful service. Maybe rigid might be a good thing?

Thoughts?=C2=A0 Did I miss another type of conduit to transfer status... excluding SOAP :)

--
Alexander Roscoe
484-716-9048

_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/capt= ive-portals

--001a1134fb1adc82ed053b53b86e-- From nobody Wed Aug 31 05:55:46 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 325CB12DB52 for ; Wed, 31 Aug 2016 05:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxq8NQ_He9Z7 for ; Wed, 31 Aug 2016 05:55:43 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C7CA12D176 for ; Wed, 31 Aug 2016 05:55:43 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([::1]) with mapi id 14.03.0294.000; Wed, 31 Aug 2016 08:55:42 -0400 From: Dave Dolson To: David Bird , Alexander Roscoe Thread-Topic: [Captive-portals] API / ICMP for status and remaining time Thread-Index: AQHSAwh80JFnINrJI021334AKK3XqqBihRcAgACCzR4= Date: Wed, 31 Aug 2016 12:55:41 +0000 Message-ID: <20160831125540.5697620.5566.105417@sandvine.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_2016083112554056976205566105417sandvinecom_" MIME-Version: 1.0 Archived-At: Cc: "captive-portals@ietf.org" Subject: Re: [Captive-portals] API / ICMP for status and remaining time X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 31 Aug 2016 12:55:45 -0000 --_000_2016083112554056976205566105417sandvinecom_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable An ICMP extension could notify a sender that a 5-tuple connection is walled= off=FD. It works for all IP protocols (TCP, UDP, GRE, even ICMP-echo). =FDThis will be more real-time than relying on the sender to periodically p= robe well-known servers on port 80. Such a message should indicate a reason, which could be a URL to a JSON/RES= T interface. Or, it could simply be an event that means "go probe port 80 to get redirec= ted" From: David Bird Sent: Tuesday, August 30, 2016 9:07 PM To: Alexander Roscoe Cc: captive-portals@ietf.org Subject: Re: [Captive-portals] API / ICMP for status and remaining time I believe ICMP is useful for realtime, 5-tuple flow specific (as well as ge= neral), notifications, but it should not be used to carry any session param= eters or meaningful data. A REST API would be better for that. On Tue, Aug 30, 2016 at 2:49 PM, Alexander Roscoe > wrote: I am looking at the mechanisms to communicate captive portal states to users. I think a RESTful API would be viable candidate for communicating this information. The same URL from RFC7710 or the URL given by the 302 redirect could be used to as the endpoint for this service as well. Clients could reach out to this endpoint to get status such as "Time Remaining" or "TX/RX transferred". RESTful interfaces can be easily setup and can be easily extended to add new features. Along side REST, I was looking at the ICMP as a conduit to transmit this information as well. Information could be pushed to the clients' device and then digested rather than pulled like a RESTful protocol. I think an implementation of this setup could work well on a deployment where the AAA server resides on the same system as the gateway because the information in the ICMP is easily accessible. When the AAA server exists on another system it may pose a problem. For example, many networks that use captive portals block external ICMP messages and/or NAT devices to client, therefore the gateway would need to proxy these packets. This adds more complexity to the network design. Also, ICMP message would be very rigid and not as extendable as a RESTful service. Maybe rigid might be a good thing? Thoughts? Did I miss another type of conduit to transfer status... excluding SOAP :) -- Alexander Roscoe 484-716-9048 _______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals --_000_2016083112554056976205566105417sandvinecom_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
From: David Bird
Sent: Tuesday, August 30, 2016 9:07 PM
To: Alexander Roscoe
Cc: captive-portals@ietf.org
Subject: Re: [Captive-portals] API / ICMP for status and remain= ing time

I believe ICMP is useful for realtime, 5-tuple flow specif= ic (as well as general), notifications, but it should not be used to carry = any session parameters or meaningful data. A REST API would be better for t= hat. 

On Tue, Aug 30, 2016 at 2:49 PM, Alexander Rosco= e <alexand= er.roscoe@gmail.com> wrote:
I am looking at the mechanisms to communicate captive portal states to
users. I think a RESTful API would be viable candidate for
communicating this information.  The same URL from RFC7710 or the URL<= br> given by the 302 redirect could be used to as the endpoint for this
service as well.  Clients could reach out to this endpoint to get
status such as "Time Remaining" or "TX/RX transferred".=   RESTful
interfaces can be easily setup and can be easily extended to add new
features.

Along side REST, I was looking at the ICMP as a conduit to transmit
this information as well.  Information could be pushed to the clients'=
device and then digested rather than pulled like a RESTful protocol.
I think an implementation of this setup could work well on a
deployment where the AAA server resides on the same system as the
gateway because the information in the ICMP is easily accessible.
When the AAA server exists on another system it may pose a problem.
For example, many networks that use captive portals block external
ICMP messages and/or NAT devices to client, therefore the gateway
would need to proxy these packets.  This adds more complexity to the network design. Also, ICMP message would be very rigid and not as
extendable as a RESTful service. Maybe rigid might be a good thing?

Thoughts?  Did I miss another type of conduit to transfer status... excluding SOAP :)

--
Alexander Roscoe
484-716-9048
_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/capt= ive-portals

--_000_2016083112554056976205566105417sandvinecom_-- From nobody Wed Aug 31 06:30:21 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD69412DBD6 for ; Wed, 31 Aug 2016 06:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbTO6hANl9lK for ; Wed, 31 Aug 2016 06:30:15 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 940E612DB8A for ; Wed, 31 Aug 2016 06:28:42 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id p186so34926588oia.2 for ; Wed, 31 Aug 2016 06:28:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ll1kNLUOdGx5N/4S3X0KqCKvQYv9gCy+hG+gGlqVZg4=; b=j2B/o38QtxeLwHD1P6167yJS5rJ6E329eJZsnxoTfVMdfWJe1sRLQ3LBdQeDaSqAsX dCwgxHHT9Sh0PfQVtc3LlEHxvz3bUenAKNvDmAVeTIfg9+8I6pRXyfL5MCNTcNckdWms rT8QRWVu2HVDupL3KVDbdO0mWzzWynUm4EDuMi3S+8bLP2XgrEM/CyonSry/td4Sw+Hk m2q1qjWhSHZX7gja0qr8eWP8GXYD10t9AuWT5xTjo7ky6/AL+SmkU8QaRlGT9ZDK/3xI hsRWzz8pjezzis/6p8d5tM5jVT6xIIaWbzti2Q61oWQaJXqknpvnG/jvd9fv6sHOM1La bhuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ll1kNLUOdGx5N/4S3X0KqCKvQYv9gCy+hG+gGlqVZg4=; b=BpiWvzawDFR0RGMiulxkf+EAtxRLLJKwGIEmZqAuugbq/YJ5CRo7+roidXZ7/+N/8p 6ZwABdmYVos3/q0Q2jpbdPPY2xRqycT08Ln1hQ57B2GExk/zR5WsNAIguaQTGXSqS6uj XXIkk2ZmIqo8DVs2/HEmZMxfRrCrLQa1vsX/2K4+rHylGITOfBNQ+zFT6l2vPkW7xsoq 6gZuQJNP6Jp+MsA1vVJOHPO6Z8lpDPtP7tIjzzHxR/sxYSLqQjsN1sFppwoHkVf6CJkA 3fDcecrWyhV3cqfbnN0vTwnxpGOM7YEoXdZC50vz9r+4cT8KcQs+noN/K73fsbhsptfz 78mg== X-Gm-Message-State: AE9vXwMOQSBs9y1z6zgkJ5p/6/8f+50Bs/dgXihUj7GljictCHzoGb+iYaEzVaFAv3AXmjwi+m09rbM60wW3oXl6 X-Received: by 10.202.104.69 with SMTP id d66mr9228155oic.83.1472650121771; Wed, 31 Aug 2016 06:28:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.175.19 with HTTP; Wed, 31 Aug 2016 06:28:40 -0700 (PDT) Received: by 10.202.175.19 with HTTP; Wed, 31 Aug 2016 06:28:40 -0700 (PDT) In-Reply-To: References: <20160831125540.5697620.5566.105417@sandvine.com> From: David Bird Date: Wed, 31 Aug 2016 06:28:40 -0700 Message-ID: To: Dave Dolson Content-Type: multipart/alternative; boundary=001a1140fa8c636a53053b5e13dd Archived-At: Cc: captive-portals@ietf.org, Alexander Roscoe Subject: Re: [Captive-portals] API / ICMP for status and remaining time X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 31 Aug 2016 13:30:19 -0000 --001a1140fa8c636a53053b5e13dd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am working updating https://tools.ietf.org/html/draft-wkumari-capport-icmp-unreach-01. I plan to add a 'policy class' uint32 to the ICMP message that can be used as a site specific 'hint' to the captive portal. This uint32 is site specific and -can- be unique per visitor and should only be used by portal as a hint/reason (capport URL gotten from DHCP rfc 7710) . On Aug 31, 2016 5:55 AM, "Dave Dolson" wrote: An ICMP extension could notify a sender that a 5-tuple connection is walled off=E2=80=8E. It works for all IP protocols (TCP, UDP, GRE, even ICMP-echo)= . =E2=80=8EThis will be more real-time than relying on the sender to periodic= ally probe well-known servers on port 80. Such a message should indicate a reason, which could be a URL to a JSON/REST interface. Or, it could simply be an event that means "go probe port 80 to get redirected" *From: *David Bird *Sent: *Tuesday, August 30, 2016 9:07 PM *To: *Alexander Roscoe *Cc: *captive-portals@ietf.org *Subject: *Re: [Captive-portals] API / ICMP for status and remaining time I believe ICMP is useful for realtime, 5-tuple flow specific (as well as general), notifications, but it should not be used to carry any session parameters or meaningful data. A REST API would be better for that. On Tue, Aug 30, 2016 at 2:49 PM, Alexander Roscoe < alexander.roscoe@gmail.com> wrote: > I am looking at the mechanisms to communicate captive portal states to > users. I think a RESTful API would be viable candidate for > communicating this information. The same URL from RFC7710 or the URL > given by the 302 redirect could be used to as the endpoint for this > service as well. Clients could reach out to this endpoint to get > status such as "Time Remaining" or "TX/RX transferred". RESTful > interfaces can be easily setup and can be easily extended to add new > features. > > Along side REST, I was looking at the ICMP as a conduit to transmit > this information as well. Information could be pushed to the clients' > device and then digested rather than pulled like a RESTful protocol. > I think an implementation of this setup could work well on a > deployment where the AAA server resides on the same system as the > gateway because the information in the ICMP is easily accessible. > When the AAA server exists on another system it may pose a problem. > For example, many networks that use captive portals block external > ICMP messages and/or NAT devices to client, therefore the gateway > would need to proxy these packets. This adds more complexity to the > network design. Also, ICMP message would be very rigid and not as > extendable as a RESTful service. Maybe rigid might be a good thing? > > Thoughts? Did I miss another type of conduit to transfer status... > excluding SOAP :) > > -- > Alexander Roscoe > 484-716-9048 > > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals > --001a1140fa8c636a53053b5e13dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I am working updating https://tools.ietf.org/html/draft-w= kumari-capport-icmp-unreach-01. I plan to add a 'policy class' = uint32 to the ICMP message that can be used as a site specific 'hint= 9; to the captive portal. This uint32 is site specific and -can- be unique = per visitor and should only be used by portal as a hint/reason (capport URL= gotten from DHCP rfc 7710) .


On Aug 31, 2016 5= :55 AM, "Dave Dolson" <ddolson@sandvine.com> wrote:
An ICMP extension could notify a sender that a 5-tuple connection is walled= off=E2=80=8E. It works for all IP protocols (TCP, UDP, GRE, even ICMP-echo= ).
=E2=80=8EThis will be more real-time than relying on the sender to periodic= ally probe well-known servers on port 80.

Such a message should indicate a reason, which could be a URL to a JSON/RES= T interface.

Or, it could simply be an event that means "go probe port 80 to get re= directed"



From: David Bird
Sent: Tuesday, August 30, 2016 9:07 PM
To: Alexander Roscoe
Subject: Re: [Captive-portals] API / ICMP for status and remain= ing time

I believe ICMP is useful for realtime, 5-tuple flow specif= ic (as well as general), notifications, but it should not be used to carry = any session parameters or meaningful data. A REST API would be better for t= hat.=C2=A0

On Tue, Aug 30, 2016 at 2:49 PM, Alexander Rosco= e <alexand= er.roscoe@gmail.com> wrote:
I am looking at the mechanisms to communicate captive portal states to
users. I think a RESTful API would be viable candidate for
communicating this information.=C2=A0 The same URL from RFC7710 or the URL<= br> given by the 302 redirect could be used to as the endpoint for this
service as well.=C2=A0 Clients could reach out to this endpoint to get
status such as "Time Remaining" or "TX/RX transferred".= =C2=A0 RESTful
interfaces can be easily setup and can be easily extended to add new
features.

Along side REST, I was looking at the ICMP as a conduit to transmit
this information as well.=C2=A0 Information could be pushed to the clients&= #39;
device and then digested rather than pulled like a RESTful protocol.
I think an implementation of this setup could work well on a
deployment where the AAA server resides on the same system as the
gateway because the information in the ICMP is easily accessible.
When the AAA server exists on another system it may pose a problem.
For example, many networks that use captive portals block external
ICMP messages and/or NAT devices to client, therefore the gateway
would need to proxy these packets.=C2=A0 This adds more complexity to the network design. Also, ICMP message would be very rigid and not as
extendable as a RESTful service. Maybe rigid might be a good thing?

Thoughts?=C2=A0 Did I miss another type of conduit to transfer status... excluding SOAP :)

--
Alexander Roscoe
484-7= 16-9048

_______________________________________________
Captive-portals mailing list
Captive-porta= ls@ietf.org
https://www.ietf.org/mailman/listinfo/capt= ive-portals


--001a1140fa8c636a53053b5e13dd-- From nobody Wed Aug 31 06:58:05 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A63F212D558 for ; Wed, 31 Aug 2016 06:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIqI4TH5Rur1 for ; Wed, 31 Aug 2016 06:57:59 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A939B12DB44 for ; Wed, 31 Aug 2016 06:47:03 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id q42so30566878uaq.1 for ; Wed, 31 Aug 2016 06:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Uzu9ftGcAYJ5ik2ZEGmRZ8o7xFFyVzgWXH1WpSwliVg=; b=D4srITYFG49JTC4SlkmsaWbe5tYnvzxcQkeJ92tgsfEotPCIoqxm3PyM/zjNO1d3L5 6rk0MGi5s6A8TekxrK0nCfyW5k0aiO0oM8xbsaiCJMG/NT2CtCKOjGOTjAK4U46+h4mt cgExd/7mjXy2ozk/qxqlkcjihC0MvxOC6UOnBICIXbThFA+7VyMvI74aDi1kiLtSe2NC uW9JSNh32M95Cf8KWupdoijlksgu429FlRf0vK0CHRBd6hLf7EB7+Yiv+BNgLQGSAen8 X0gF9gVJrStcuGsOMaPDoWXJDl7GD+GwjWZErEsEQpy6pvkwAqKGC6IRjyeghriqigvp Sm4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Uzu9ftGcAYJ5ik2ZEGmRZ8o7xFFyVzgWXH1WpSwliVg=; b=NifieaI8bRv50IW+vEQyDupbWXQZtcyieADcie7frZeodczjYlok/TqebMSJBZ9gsJ pBJzlji7l9iPJQc92ELPT8PdhnRje2cHbE3/+ZclCl8j7NNYwVYiJ3j+j+AQ5fkRWTky 3JkMKqo1VSkeIagtnbJcK6ItbDtEdPzsdw56eDtEg99nXw2ICdWQI1d2nUybssxzNvTq oZ7AKfHEG8oHRjtyGv2tYYqoq+W3vjy10oZMjbwDYQdGBanx6BXzL6A+OpiknDpIsQvk R6WAPPI5DDpiHQ3M3KAVoeGzJTLaDkZdPILeBJlc0cnp/lSbiXQ4wiCyZNdb4tmHLcmz 36Hw== X-Gm-Message-State: AE9vXwMbV+a78V6o7qI8KHAJpijouV9ujiLCrK9brytx7x88Y4aEd3gObinEkkZLEBxMHxabR0VLV2F6x+dFXg== X-Received: by 10.159.37.225 with SMTP id 88mr4895620uaf.130.1472651222341; Wed, 31 Aug 2016 06:47:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.129.85 with HTTP; Wed, 31 Aug 2016 06:46:42 -0700 (PDT) In-Reply-To: References: <20160831125540.5697620.5566.105417@sandvine.com> From: Alexander Roscoe Date: Wed, 31 Aug 2016 09:46:42 -0400 Message-ID: To: David Bird Content-Type: multipart/alternative; boundary=001a113596c2fc63db053b5e5474 Archived-At: Cc: captive-portals@ietf.org, Dave Dolson Subject: Re: [Captive-portals] API / ICMP for status and remaining time X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 31 Aug 2016 13:58:04 -0000 --001a113596c2fc63db053b5e5474 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think a hybrid approach, ICMP/API, would be efficient . One scenario I see frequently is User connects to access point 1 and has internet User starts an internet session User moves closer to access point 2(different network w/ captive portal) automatically connects due to RSSIs User sends packets as if the device has internet Many devices won't even re-IP or send a DHCP discover even though are on a different network completely. The ICMP response for these packets could trigger the captive portal faster for a better user experience. For the DHCP option from RFC7710, is it correct to say a device should not assume the device is behind a captive portal based on that option being present in the DHCP offer? If the option stays after authentication, the device can still receive that URL if it were used as an API endpoint. Then ICMP could be the mechanism for state. On Wed, Aug 31, 2016 at 9:28 AM, David Bird wrote: > I am working updating https://tools.ietf.org/html/ > draft-wkumari-capport-icmp-unreach-01. I plan to add a 'policy class' > uint32 to the ICMP message that can be used as a site specific 'hint' to > the captive portal. This uint32 is site specific and -can- be unique per > visitor and should only be used by portal as a hint/reason (capport URL > gotten from DHCP rfc 7710) . > > On Aug 31, 2016 5:55 AM, "Dave Dolson" wrote: > > An ICMP extension could notify a sender that a 5-tuple connection is > walled off=E2=80=8E. It works for all IP protocols (TCP, UDP, GRE, even I= CMP-echo). > =E2=80=8EThis will be more real-time than relying on the sender to period= ically > probe well-known servers on port 80. > > Such a message should indicate a reason, which could be a URL to a > JSON/REST interface. > > Or, it could simply be an event that means "go probe port 80 to get > redirected" > > > > *From: *David Bird > *Sent: *Tuesday, August 30, 2016 9:07 PM > *To: *Alexander Roscoe > *Cc: *captive-portals@ietf.org > *Subject: *Re: [Captive-portals] API / ICMP for status and remaining time > > I believe ICMP is useful for realtime, 5-tuple flow specific (as well as > general), notifications, but it should not be used to carry any session > parameters or meaningful data. A REST API would be better for that. > > On Tue, Aug 30, 2016 at 2:49 PM, Alexander Roscoe < > alexander.roscoe@gmail.com> wrote: > >> I am looking at the mechanisms to communicate captive portal states to >> users. I think a RESTful API would be viable candidate for >> communicating this information. The same URL from RFC7710 or the URL >> given by the 302 redirect could be used to as the endpoint for this >> service as well. Clients could reach out to this endpoint to get >> status such as "Time Remaining" or "TX/RX transferred". RESTful >> interfaces can be easily setup and can be easily extended to add new >> features. >> >> Along side REST, I was looking at the ICMP as a conduit to transmit >> this information as well. Information could be pushed to the clients' >> device and then digested rather than pulled like a RESTful protocol. >> I think an implementation of this setup could work well on a >> deployment where the AAA server resides on the same system as the >> gateway because the information in the ICMP is easily accessible. >> When the AAA server exists on another system it may pose a problem. >> For example, many networks that use captive portals block external >> ICMP messages and/or NAT devices to client, therefore the gateway >> would need to proxy these packets. This adds more complexity to the >> network design. Also, ICMP message would be very rigid and not as >> extendable as a RESTful service. Maybe rigid might be a good thing? >> >> Thoughts? Did I miss another type of conduit to transfer status... >> excluding SOAP :) >> >> -- >> Alexander Roscoe >> 484-716-9048 >> >> _______________________________________________ >> Captive-portals mailing list >> Captive-portals@ietf.org >> https://www.ietf.org/mailman/listinfo/captive-portals >> > > > --=20 Alexander Roscoe 484-716-9048 --001a113596c2fc63db053b5e5474 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think a hybrid approach,=C2=A0ICMP/API,=C2=A0would be ef= ficient .=C2=A0 One scenario I see frequently is

User co= nnects to access point 1 and has internet
User starts an internet= session
User moves closer to access point 2(different network w/= captive portal) automatically connects due to RSSIs
User sends p= ackets as if the device has internet

Many devices = won't even re-IP or send a DHCP discover even though are on a different= network completely. The ICMP response for these packets could trigger the = captive portal faster for a better user experience. =C2=A0

For the DHCP option from RFC7710, is it correct to say a device sh= ould not assume the device is behind a captive portal based on that option = being present in the DHCP offer?=C2=A0 If the option stays after authentica= tion, the device can still receive that URL if it were used as an API endpo= int.=C2=A0 Then ICMP could be the mechanism for state.

=


On Wed, Aug 31, 2016 at 9:28 AM, David Bird <dbird@google.com> wrote:

I am working = updating https://tools.ietf.org/html/draft-wkumar= i-capport-icmp-unreach-01. I plan to add a 'policy class' = uint32 to the ICMP message that can be used as a site specific 'hint= 9; to the captive portal. This uint32 is site specific and -can- be unique = per visitor and should only be used by portal as a hint/reason (capport URL= gotten from DHCP rfc 7710) .


On Aug 31, 2016 5= :55 AM, "Dave Dolson" <ddolson@sandvine.com> wrote:
An ICMP extension could notify a sender that a 5-tuple connection is walled= off=E2=80=8E. It works for all IP protocols (TCP, UDP, GRE, even ICMP-echo= ).
=E2=80=8EThis will be more real-time than relying on the sender to periodic= ally probe well-known servers on port 80.

Such a message should indicate a reason, which could be a URL to a JSON/RES= T interface.

Or, it could simply be an event that means "go probe port 80 to get re= directed"



From: David Bird
Sent: Tuesday, August 30, 2016 9:07 PM
To: Alexander Roscoe
Subject: Re: [Captive-portals] API / ICMP for status and remain= ing time

I believe ICMP is useful for realtime, 5-tuple flow specif= ic (as well as general), notifications, but it should not be used to carry = any session parameters or meaningful data. A REST API would be better for t= hat.=C2=A0

On Tue, Aug 30, 2016 at 2:49 PM, Alexander Rosco= e <alexand= er.roscoe@gmail.com> wrote:
I am looking at the mechanisms to communicate captive portal states to
users. I think a RESTful API would be viable candidate for
communicating this information.=C2=A0 The same URL from RFC7710 or the URL<= br> given by the 302 redirect could be used to as the endpoint for this
service as well.=C2=A0 Clients could reach out to this endpoint to get
status such as "Time Remaining" or "TX/RX transferred".= =C2=A0 RESTful
interfaces can be easily setup and can be easily extended to add new
features.

Along side REST, I was looking at the ICMP as a conduit to transmit
this information as well.=C2=A0 Information could be pushed to the clients&= #39;
device and then digested rather than pulled like a RESTful protocol.
I think an implementation of this setup could work well on a
deployment where the AAA server resides on the same system as the
gateway because the information in the ICMP is easily accessible.
When the AAA server exists on another system it may pose a problem.
For example, many networks that use captive portals block external
ICMP messages and/or NAT devices to client, therefore the gateway
would need to proxy these packets.=C2=A0 This adds more complexity to the network design. Also, ICMP message would be very rigid and not as
extendable as a RESTful service. Maybe rigid might be a good thing?

Thoughts?=C2=A0 Did I miss another type of conduit to transfer status... excluding SOAP :)

--
Alexander Roscoe
484-7= 16-9048

_______________________________________________
Captive-portals mailing list
Captive-porta= ls@ietf.org
https://www.ietf.org/mailman/listinfo/capt= ive-portals





--
=
Alexander= Roscoe
484-716-9048
--001a113596c2fc63db053b5e5474-- From nobody Wed Aug 31 08:08:05 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A02A12DC94 for ; Wed, 31 Aug 2016 08:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0EPUMECgvj3 for ; Wed, 31 Aug 2016 08:08:01 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4177C12DDA1 for ; Wed, 31 Aug 2016 07:37:47 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id f189so72979938oig.3 for ; Wed, 31 Aug 2016 07:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LHBqhQfpwsoy02xYlgRoc6qYTV3uYKgrsDEfa54mm9g=; b=X8i7cWEJk48gdQ1pFDld03ZSLGXgT5pyHXLMrZM3R8SqeTF2WtOgpx000CLH0hMpur rF1eXbDqqwylQl3ksRpStYejuidqNWS/6t3EZAxftdg1rOBE4x05g4igEvF8V4rUsBki v5fsYyJFjpd6Rwdinf6LgX4HJ6VkMgRaH01VTHqQusVNWc5Tn9kllb4hp9ldxTFhM18s wGHscbV7IqaU5tFHaL9LGAMKarTl3m3AaW4bVFlRVwz7TZRTden98ZkjCHp6jVKCHVzf UnlsYIL6KdlMTMlnDhRcTNIEFn+FZrHq3u568HP7m8kF7iBQLDg7+Kov93morhgTYqxO 11Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LHBqhQfpwsoy02xYlgRoc6qYTV3uYKgrsDEfa54mm9g=; b=FQpX+tmImxMT6FK8jC3+CLzVIPCrVWb48gWjswVm5K0Fz9/+lJewMe1bvuIAGtZsdk ZMB/Z7FlwoRkG/C3kSVHCWLPnMlbtMj6bW4Wz9o8VynG9oUovtpoi2eRowpyfnfl66fz A3lvStBu2lTUXrFPZ9k0iZcD2nU/4XoXFEwk0FAuqctqfkZX4Q8R3w6D2+CHwcJ0T3LV ZHEdZmo8iJ5Yejv4MIY8TNlS8BFt5Ct77P/SKEuGZHhxpgUodoX3La+JVNgTPD7UP7Yd arMkKaKeRcVBLDmlDBMsCU1DcBDxeUlw8bfiJhfwkZtc+1mHBQ/mxIrUId9hYZibgFe7 zw+g== X-Gm-Message-State: AE9vXwN/m5Jugr8cLt6ZPGNESIU7jTqsIgScIpGMglUq3Bv1CoQo2gqYDDzwm+xx00TMf2poef9bvre85Hm7IHvX X-Received: by 10.157.3.235 with SMTP id f98mr9456617otf.188.1472654266466; Wed, 31 Aug 2016 07:37:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.175.19 with HTTP; Wed, 31 Aug 2016 07:37:45 -0700 (PDT) Received: by 10.202.175.19 with HTTP; Wed, 31 Aug 2016 07:37:45 -0700 (PDT) In-Reply-To: References: <20160831125540.5697620.5566.105417@sandvine.com> From: David Bird Date: Wed, 31 Aug 2016 07:37:45 -0700 Message-ID: To: Alexander Roscoe Content-Type: multipart/alternative; boundary=94eb2c03ceac6e724d053b5f0a8b Archived-At: Cc: captive-portals@ietf.org, Dave Dolson Subject: Re: [Captive-portals] API / ICMP for status and remaining time X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 31 Aug 2016 15:08:04 -0000 --94eb2c03ceac6e724d053b5f0a8b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Regarding DHCP, I think we have to assume the rfc 7710 attribute remains in the responses always. Not all capport implementations use an integrated DHCP server, and I don't think DHCP should be queried by clients for capport state. On Aug 31, 2016 6:47 AM, "Alexander Roscoe" wrote: > I think a hybrid approach, ICMP/API, would be efficient . One scenario I > see frequently is > > User connects to access point 1 and has internet > User starts an internet session > User moves closer to access point 2(different network w/ captive portal) > automatically connects due to RSSIs > User sends packets as if the device has internet > > Many devices won't even re-IP or send a DHCP discover even though are on = a > different network completely. The ICMP response for these packets could > trigger the captive portal faster for a better user experience. > > For the DHCP option from RFC7710, is it correct to say a device should no= t > assume the device is behind a captive portal based on that option being > present in the DHCP offer? If the option stays after authentication, the > device can still receive that URL if it were used as an API endpoint. Th= en > ICMP could be the mechanism for state. > > > > On Wed, Aug 31, 2016 at 9:28 AM, David Bird wrote: > >> I am working updating https://tools.ietf.org/html/dr >> aft-wkumari-capport-icmp-unreach-01. I plan to add a 'policy class' >> uint32 to the ICMP message that can be used as a site specific 'hint' to >> the captive portal. This uint32 is site specific and -can- be unique per >> visitor and should only be used by portal as a hint/reason (capport URL >> gotten from DHCP rfc 7710) . >> >> On Aug 31, 2016 5:55 AM, "Dave Dolson" wrote: >> >> An ICMP extension could notify a sender that a 5-tuple connection is >> walled off=E2=80=8E. It works for all IP protocols (TCP, UDP, GRE, even = ICMP-echo). >> =E2=80=8EThis will be more real-time than relying on the sender to perio= dically >> probe well-known servers on port 80. >> >> Such a message should indicate a reason, which could be a URL to a >> JSON/REST interface. >> >> Or, it could simply be an event that means "go probe port 80 to get >> redirected" >> >> >> >> *From: *David Bird >> *Sent: *Tuesday, August 30, 2016 9:07 PM >> *To: *Alexander Roscoe >> *Cc: *captive-portals@ietf.org >> *Subject: *Re: [Captive-portals] API / ICMP for status and remaining tim= e >> >> I believe ICMP is useful for realtime, 5-tuple flow specific (as well as >> general), notifications, but it should not be used to carry any session >> parameters or meaningful data. A REST API would be better for that. >> >> On Tue, Aug 30, 2016 at 2:49 PM, Alexander Roscoe < >> alexander.roscoe@gmail.com> wrote: >> >>> I am looking at the mechanisms to communicate captive portal states to >>> users. I think a RESTful API would be viable candidate for >>> communicating this information. The same URL from RFC7710 or the URL >>> given by the 302 redirect could be used to as the endpoint for this >>> service as well. Clients could reach out to this endpoint to get >>> status such as "Time Remaining" or "TX/RX transferred". RESTful >>> interfaces can be easily setup and can be easily extended to add new >>> features. >>> >>> Along side REST, I was looking at the ICMP as a conduit to transmit >>> this information as well. Information could be pushed to the clients' >>> device and then digested rather than pulled like a RESTful protocol. >>> I think an implementation of this setup could work well on a >>> deployment where the AAA server resides on the same system as the >>> gateway because the information in the ICMP is easily accessible. >>> When the AAA server exists on another system it may pose a problem. >>> For example, many networks that use captive portals block external >>> ICMP messages and/or NAT devices to client, therefore the gateway >>> would need to proxy these packets. This adds more complexity to the >>> network design. Also, ICMP message would be very rigid and not as >>> extendable as a RESTful service. Maybe rigid might be a good thing? >>> >>> Thoughts? Did I miss another type of conduit to transfer status... >>> excluding SOAP :) >>> >>> -- >>> Alexander Roscoe >>> 484-716-9048 >>> >>> _______________________________________________ >>> Captive-portals mailing list >>> Captive-portals@ietf.org >>> https://www.ietf.org/mailman/listinfo/captive-portals >>> >> >> >> > > > -- > Alexander Roscoe > 484-716-9048 > --94eb2c03ceac6e724d053b5f0a8b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Regarding DHCP, I think we have to assume the rfc 7710 attri= bute remains in the responses always. Not all capport implementations use a= n integrated DHCP server, and I don't think DHCP should be queried by c= lients for capport state.


On Aug 31, 2016 6= :47 AM, "Alexander Roscoe" <alexander.roscoe@gmail.com> wrote:
I think a hybrid approac= h,=C2=A0ICMP/API,=C2=A0would be efficient .=C2=A0 One scenario I see freque= ntly is

User connects to access point 1 and has internet=
User starts an internet session
User moves closer to a= ccess point 2(different network w/ captive portal) automatically connects d= ue to RSSIs
User sends packets as if the device has internet

Many devices won't even re-IP or send a DHCP disco= ver even though are on a different network completely. The ICMP response fo= r these packets could trigger the captive portal faster for a better user e= xperience. =C2=A0

For the DHCP option from RFC7710= , is it correct to say a device should not assume the device is behind a ca= ptive portal based on that option being present in the DHCP offer?=C2=A0 If= the option stays after authentication, the device can still receive that U= RL if it were used as an API endpoint.=C2=A0 Then ICMP could be the mechani= sm for state.



On Wed, Aug 31, 2016 at 9:28 AM, Davi= d Bird <dbird@google.com> wrote:

I am working updating https://too= ls.ietf.org/html/draft-wkumari-capport-icmp-unreach-01. I pla= n to add a 'policy class' uint32 to the ICMP message that can be us= ed as a site specific 'hint' to the captive portal. This uint32 is = site specific and -can- be unique per visitor and should only be used by po= rtal as a hint/reason (capport URL gotten from DHCP rfc 7710) .


On Aug 31, 2016 5= :55 AM, "Dave Dolson" <ddolson@sandvine.com> wrote:
An ICMP extension could notify a sender that a 5-tuple connection is walled= off=E2=80=8E. It works for all IP protocols (TCP, UDP, GRE, even ICMP-echo= ).
=E2=80=8EThis will be more real-time than relying on the sender to periodic= ally probe well-known servers on port 80.

Such a message should indicate a reason, which could be a URL to a JSON/RES= T interface.

Or, it could simply be an event that means "go probe port 80 to get re= directed"



From: David Bird
Sent: Tuesday, August 30, 2016 9:07 PM
To: Alexander Roscoe
Subject: Re: [Captive-portals] API / ICMP for status and remain= ing time

I believe ICMP is useful for realtime, 5-tuple flow specif= ic (as well as general), notifications, but it should not be used to carry = any session parameters or meaningful data. A REST API would be better for t= hat.=C2=A0

On Tue, Aug 30, 2016 at 2:49 PM, Alexander Rosco= e <alexand= er.roscoe@gmail.com> wrote:
I am looking at the mechanisms to communicate captive portal states to
users. I think a RESTful API would be viable candidate for
communicating this information.=C2=A0 The same URL from RFC7710 or the URL<= br> given by the 302 redirect could be used to as the endpoint for this
service as well.=C2=A0 Clients could reach out to this endpoint to get
status such as "Time Remaining" or "TX/RX transferred".= =C2=A0 RESTful
interfaces can be easily setup and can be easily extended to add new
features.

Along side REST, I was looking at the ICMP as a conduit to transmit
this information as well.=C2=A0 Information could be pushed to the clients&= #39;
device and then digested rather than pulled like a RESTful protocol.
I think an implementation of this setup could work well on a
deployment where the AAA server resides on the same system as the
gateway because the information in the ICMP is easily accessible.
When the AAA server exists on another system it may pose a problem.
For example, many networks that use captive portals block external
ICMP messages and/or NAT devices to client, therefore the gateway
would need to proxy these packets.=C2=A0 This adds more complexity to the network design. Also, ICMP message would be very rigid and not as
extendable as a RESTful service. Maybe rigid might be a good thing?

Thoughts?=C2=A0 Did I miss another type of conduit to transfer status... excluding SOAP :)

--
Alexander Roscoe
484-7= 16-9048

_______________________________________________
Captive-portals mailing list
Captive-porta= ls@ietf.org
https://www.ietf.org/mailman/listinfo/capt= ive-portals





--
=
Alexander Roscoe
--94eb2c03ceac6e724d053b5f0a8b-- From nobody Wed Aug 31 14:00:28 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB97B12D781 for ; Wed, 31 Aug 2016 14:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiVjHNgcdUYM for ; Wed, 31 Aug 2016 14:00:24 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95EA812D60D for ; Wed, 31 Aug 2016 14:00:24 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0294.000; Wed, 31 Aug 2016 17:00:22 -0400 From: Dave Dolson To: David Bird Thread-Topic: [Captive-portals] API / ICMP for status and remaining time Thread-Index: AQHSAwh80JFnINrJI021334AKK3XqqBihRcAgACCzR6AAAk8UoAABFUA Date: Wed, 31 Aug 2016 21:00:22 +0000 Message-ID: References: <20160831125540.5697620.5566.105417@sandvine.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E983109ADBBwtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Cc: "captive-portals@ietf.org" , Alexander Roscoe Subject: Re: [Captive-portals] API / ICMP for status and remaining time X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 31 Aug 2016 21:00:27 -0000 --_000_E8355113905631478EFF04F5AA706E983109ADBBwtlexchp2sandvi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGF2aWQsDQpZZXMsIEkgd291bGQgbGlrZSB0byBzZWUgdGhhdCBkcmFmdCB1cGRhdGVkLCB0aGFu a3MuDQoNCldvdWxkIHRoaXMgbmV3IGhpbnQgc3VwcG9ydCBkaWZmZXJlbnQgcmVhc29ucz8gRS5n LiwgYmFkIHdlYXRoZXIgd2FybmluZyB2cy4gcGF5bWVudCByZXF1aXJlZD8NCg0KLURhdmUNCg0K DQpGcm9tOiBEYXZpZCBCaXJkIFttYWlsdG86ZGJpcmRAZ29vZ2xlLmNvbV0NClNlbnQ6IFdlZG5l c2RheSwgQXVndXN0IDMxLCAyMDE2IDk6MjkgQU0NClRvOiBEYXZlIERvbHNvbg0KQ2M6IGNhcHRp dmUtcG9ydGFsc0BpZXRmLm9yZzsgQWxleGFuZGVyIFJvc2NvZQ0KU3ViamVjdDogUmU6IFtDYXB0 aXZlLXBvcnRhbHNdIEFQSSAvIElDTVAgZm9yIHN0YXR1cyBhbmQgcmVtYWluaW5nIHRpbWUNCg0K DQpJIGFtIHdvcmtpbmcgdXBkYXRpbmcgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXdrdW1hcmktY2FwcG9ydC1pY21wLXVucmVhY2gtMDEuIEkgcGxhbiB0byBhZGQgYSAncG9saWN5 IGNsYXNzJyB1aW50MzIgdG8gdGhlIElDTVAgbWVzc2FnZSB0aGF0IGNhbiBiZSB1c2VkIGFzIGEg c2l0ZSBzcGVjaWZpYyAnaGludCcgdG8gdGhlIGNhcHRpdmUgcG9ydGFsLiBUaGlzIHVpbnQzMiBp cyBzaXRlIHNwZWNpZmljIGFuZCAtY2FuLSBiZSB1bmlxdWUgcGVyIHZpc2l0b3IgYW5kIHNob3Vs ZCBvbmx5IGJlIHVzZWQgYnkgcG9ydGFsIGFzIGEgaGludC9yZWFzb24gKGNhcHBvcnQgVVJMIGdv dHRlbiBmcm9tIERIQ1AgcmZjIDc3MTApIC4NCg0KT24gQXVnIDMxLCAyMDE2IDU6NTUgQU0sICJE YXZlIERvbHNvbiIgPGRkb2xzb25Ac2FuZHZpbmUuY29tPG1haWx0bzpkZG9sc29uQHNhbmR2aW5l LmNvbT4+IHdyb3RlOg0KQW4gSUNNUCBleHRlbnNpb24gY291bGQgbm90aWZ5IGEgc2VuZGVyIHRo YXQgYSA1LXR1cGxlIGNvbm5lY3Rpb24gaXMgd2FsbGVkIG9mZuKAji4gSXQgd29ya3MgZm9yIGFs bCBJUCBwcm90b2NvbHMgKFRDUCwgVURQLCBHUkUsIGV2ZW4gSUNNUC1lY2hvKS4NCuKAjlRoaXMg d2lsbCBiZSBtb3JlIHJlYWwtdGltZSB0aGFuIHJlbHlpbmcgb24gdGhlIHNlbmRlciB0byBwZXJp b2RpY2FsbHkgcHJvYmUgd2VsbC1rbm93biBzZXJ2ZXJzIG9uIHBvcnQgODAuDQoNClN1Y2ggYSBt ZXNzYWdlIHNob3VsZCBpbmRpY2F0ZSBhIHJlYXNvbiwgd2hpY2ggY291bGQgYmUgYSBVUkwgdG8g YSBKU09OL1JFU1QgaW50ZXJmYWNlLg0KDQpPciwgaXQgY291bGQgc2ltcGx5IGJlIGFuIGV2ZW50 IHRoYXQgbWVhbnMgImdvIHByb2JlIHBvcnQgODAgdG8gZ2V0IHJlZGlyZWN0ZWQiDQoNCg0KDQpG cm9tOiBEYXZpZCBCaXJkDQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgMzAsIDIwMTYgOTowNyBQTQ0K VG86IEFsZXhhbmRlciBSb3Njb2UNCkNjOiBjYXB0aXZlLXBvcnRhbHNAaWV0Zi5vcmc8bWFpbHRv OmNhcHRpdmUtcG9ydGFsc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbQ2FwdGl2ZS1wb3J0YWxz XSBBUEkgLyBJQ01QIGZvciBzdGF0dXMgYW5kIHJlbWFpbmluZyB0aW1lDQoNCg0KSSBiZWxpZXZl IElDTVAgaXMgdXNlZnVsIGZvciByZWFsdGltZSwgNS10dXBsZSBmbG93IHNwZWNpZmljIChhcyB3 ZWxsIGFzIGdlbmVyYWwpLCBub3RpZmljYXRpb25zLCBidXQgaXQgc2hvdWxkIG5vdCBiZSB1c2Vk IHRvIGNhcnJ5IGFueSBzZXNzaW9uIHBhcmFtZXRlcnMgb3IgbWVhbmluZ2Z1bCBkYXRhLiBBIFJF U1QgQVBJIHdvdWxkIGJlIGJldHRlciBmb3IgdGhhdC4NCg0KT24gVHVlLCBBdWcgMzAsIDIwMTYg YXQgMjo0OSBQTSwgQWxleGFuZGVyIFJvc2NvZSA8YWxleGFuZGVyLnJvc2NvZUBnbWFpbC5jb208 bWFpbHRvOmFsZXhhbmRlci5yb3Njb2VAZ21haWwuY29tPj4gd3JvdGU6DQpJIGFtIGxvb2tpbmcg YXQgdGhlIG1lY2hhbmlzbXMgdG8gY29tbXVuaWNhdGUgY2FwdGl2ZSBwb3J0YWwgc3RhdGVzIHRv DQp1c2Vycy4gSSB0aGluayBhIFJFU1RmdWwgQVBJIHdvdWxkIGJlIHZpYWJsZSBjYW5kaWRhdGUg Zm9yDQpjb21tdW5pY2F0aW5nIHRoaXMgaW5mb3JtYXRpb24uICBUaGUgc2FtZSBVUkwgZnJvbSBS RkM3NzEwIG9yIHRoZSBVUkwNCmdpdmVuIGJ5IHRoZSAzMDIgcmVkaXJlY3QgY291bGQgYmUgdXNl ZCB0byBhcyB0aGUgZW5kcG9pbnQgZm9yIHRoaXMNCnNlcnZpY2UgYXMgd2VsbC4gIENsaWVudHMg Y291bGQgcmVhY2ggb3V0IHRvIHRoaXMgZW5kcG9pbnQgdG8gZ2V0DQpzdGF0dXMgc3VjaCBhcyAi VGltZSBSZW1haW5pbmciIG9yICJUWC9SWCB0cmFuc2ZlcnJlZCIuICBSRVNUZnVsDQppbnRlcmZh Y2VzIGNhbiBiZSBlYXNpbHkgc2V0dXAgYW5kIGNhbiBiZSBlYXNpbHkgZXh0ZW5kZWQgdG8gYWRk IG5ldw0KZmVhdHVyZXMuDQoNCkFsb25nIHNpZGUgUkVTVCwgSSB3YXMgbG9va2luZyBhdCB0aGUg SUNNUCBhcyBhIGNvbmR1aXQgdG8gdHJhbnNtaXQNCnRoaXMgaW5mb3JtYXRpb24gYXMgd2VsbC4g IEluZm9ybWF0aW9uIGNvdWxkIGJlIHB1c2hlZCB0byB0aGUgY2xpZW50cycNCmRldmljZSBhbmQg dGhlbiBkaWdlc3RlZCByYXRoZXIgdGhhbiBwdWxsZWQgbGlrZSBhIFJFU1RmdWwgcHJvdG9jb2wu DQpJIHRoaW5rIGFuIGltcGxlbWVudGF0aW9uIG9mIHRoaXMgc2V0dXAgY291bGQgd29yayB3ZWxs IG9uIGENCmRlcGxveW1lbnQgd2hlcmUgdGhlIEFBQSBzZXJ2ZXIgcmVzaWRlcyBvbiB0aGUgc2Ft ZSBzeXN0ZW0gYXMgdGhlDQpnYXRld2F5IGJlY2F1c2UgdGhlIGluZm9ybWF0aW9uIGluIHRoZSBJ Q01QIGlzIGVhc2lseSBhY2Nlc3NpYmxlLg0KV2hlbiB0aGUgQUFBIHNlcnZlciBleGlzdHMgb24g YW5vdGhlciBzeXN0ZW0gaXQgbWF5IHBvc2UgYSBwcm9ibGVtLg0KRm9yIGV4YW1wbGUsIG1hbnkg bmV0d29ya3MgdGhhdCB1c2UgY2FwdGl2ZSBwb3J0YWxzIGJsb2NrIGV4dGVybmFsDQpJQ01QIG1l c3NhZ2VzIGFuZC9vciBOQVQgZGV2aWNlcyB0byBjbGllbnQsIHRoZXJlZm9yZSB0aGUgZ2F0ZXdh eQ0Kd291bGQgbmVlZCB0byBwcm94eSB0aGVzZSBwYWNrZXRzLiAgVGhpcyBhZGRzIG1vcmUgY29t cGxleGl0eSB0byB0aGUNCm5ldHdvcmsgZGVzaWduLiBBbHNvLCBJQ01QIG1lc3NhZ2Ugd291bGQg YmUgdmVyeSByaWdpZCBhbmQgbm90IGFzDQpleHRlbmRhYmxlIGFzIGEgUkVTVGZ1bCBzZXJ2aWNl LiBNYXliZSByaWdpZCBtaWdodCBiZSBhIGdvb2QgdGhpbmc/DQoNClRob3VnaHRzPyAgRGlkIEkg bWlzcyBhbm90aGVyIHR5cGUgb2YgY29uZHVpdCB0byB0cmFuc2ZlciBzdGF0dXMuLi4NCmV4Y2x1 ZGluZyBTT0FQIDopDQoNCi0tDQpBbGV4YW5kZXIgUm9zY29lDQo0ODQtNzE2LTkwNDg8dGVsOjQ4 NC03MTYtOTA0OD4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCkNhcHRpdmUtcG9ydGFscyBtYWlsaW5nIGxpc3QNCkNhcHRpdmUtcG9ydGFsc0BpZXRm Lm9yZzxtYWlsdG86Q2FwdGl2ZS1wb3J0YWxzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9jYXB0aXZlLXBvcnRhbHMNCg0KDQo= --_000_E8355113905631478EFF04F5AA706E983109ADBBwtlexchp2sandvi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4ubS01 NTg1NTE5MjcwMzA3MjM3MzYxaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOm1fLTU1ODU1MTkyNzAz MDcyMzczNjFob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RGF2aWQsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlllcywgSSB3b3VsZCBsaWtlIHRvIHNlZSB0aGF0IGRyYWZ0IHVwZGF0ZWQsIHRoYW5r cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPldvdWxkIHRoaXMgbmV3IGhpbnQgc3VwcG9ydCBkaWZmZXJlbnQgcmVhc29u cz8gRS5nLiwgYmFkIHdlYXRoZXIgd2FybmluZyB2cy4gcGF5bWVudCByZXF1aXJlZD88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPi1EYXZlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gRGF2aWQgQmlyZCBbbWFpbHRvOmRiaXJk QGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBdWd1c3QgMzEsIDIw MTYgOToyOSBBTTxicj4NCjxiPlRvOjwvYj4gRGF2ZSBEb2xzb248YnI+DQo8Yj5DYzo8L2I+IGNh cHRpdmUtcG9ydGFsc0BpZXRmLm9yZzsgQWxleGFuZGVyIFJvc2NvZTxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW0NhcHRpdmUtcG9ydGFsc10gQVBJIC8gSUNNUCBmb3Igc3RhdHVzIGFuZCByZW1h aW5pbmcgdGltZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+SSBhbSB3b3JraW5nIHVwZGF0aW5nIDxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13a3VtYXJpLWNhcHBvcnQtaWNtcC11bnJl YWNoLTAxIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13a3VtYXJpLWNhcHBv cnQtaWNtcC11bnJlYWNoLTAxPC9hPi4gSSBwbGFuIHRvIGFkZCBhICdwb2xpY3kgY2xhc3MnIHVp bnQzMiB0byB0aGUgSUNNUCBtZXNzYWdlIHRoYXQgY2FuIGJlIHVzZWQgYXMgYSBzaXRlIHNwZWNp ZmljICdoaW50JyB0byB0aGUgY2FwdGl2ZSBwb3J0YWwuIFRoaXMgdWludDMyIGlzIHNpdGUgc3Bl Y2lmaWMgYW5kIC1jYW4tIGJlIHVuaXF1ZSBwZXIgdmlzaXRvciBhbmQNCiBzaG91bGQgb25seSBi ZSB1c2VkIGJ5IHBvcnRhbCBhcyBhIGhpbnQvcmVhc29uIChjYXBwb3J0IFVSTCBnb3R0ZW4gZnJv bSBESENQIHJmYyA3NzEwKSAuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gQXVnIDMxLCAyMDE2IDU6NTUgQU0sICZxdW90O0RhdmUgRG9sc29uJnF1b3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86ZGRvbHNvbkBzYW5kdmluZS5jb20iPmRkb2xzb25Ac2FuZHZpbmUuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkFuIElDTVAgZXh0ZW5zaW9uIGNvdWxkIG5vdGlmeSBhIHNlbmRlciB0aGF0IGEgNS10dXBsZSBj b25uZWN0aW9uIGlzIHdhbGxlZCBvZmbigI4uIEl0IHdvcmtzIGZvciBhbGwgSVAgcHJvdG9jb2xz IChUQ1AsIFVEUCwgR1JFLCBldmVuIElDTVAtZWNobykuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+4oCOVGhpcyB3aWxsIGJlIG1vcmUgcmVhbC10 aW1lIHRoYW4gcmVseWluZyBvbiB0aGUgc2VuZGVyIHRvIHBlcmlvZGljYWxseSBwcm9iZSB3ZWxs LWtub3duIHNlcnZlcnMgb24gcG9ydCA4MC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TdWNoIGEgbWVzc2FnZSBzaG91bGQgaW5kaWNhdGUg YSByZWFzb24sIHdoaWNoIGNvdWxkIGJlIGEgVVJMIHRvIGEgSlNPTi9SRVNUIGludGVyZmFjZS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5P ciwgaXQgY291bGQgc2ltcGx5IGJlIGFuIGV2ZW50IHRoYXQgbWVhbnMgJnF1b3Q7Z28gcHJvYmUg cG9ydCA4MCB0byBnZXQgcmVkaXJlY3RlZCZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBj ZWxscGFkZGluZz0iMCIgd2lkdGg9IjEwMCUiIHN0eWxlPSJ3aWR0aDoxMDAuMCU7YmFja2dyb3Vu ZDp3aGl0ZTtib3JkZXItc3BhY2luZzowcHgiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJw YWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0O2ZvbnQtc2l6ZTppbml0aWFsO3RleHQtYWxp Z246aW5pdGlhbCI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206DQo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EYXZpZCBCaXJkPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPlNlbnQ6DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5UdWVzZGF5LCBBdWd1c3QgMzAsIDIwMTYgOTowNyBQTTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5UbzoNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkFsZXhhbmRlciBSb3Njb2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q2M6 DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJtYWlsdG86 Y2FwdGl2ZS1wb3J0YWxzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Y2FwdGl2ZS1wb3J0YWxz QGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TdWJqZWN0Og0K PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UmU6IFtDYXB0aXZlLXBvcnRh bHNdIEFQSSAvIElDTVAgZm9yIHN0YXR1cyBhbmQgcmVtYWluaW5nIHRpbWU8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJs ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBiZWxpZXZlIElDTVAgaXMgdXNlZnVs IGZvciByZWFsdGltZSwgNS10dXBsZSBmbG93IHNwZWNpZmljIChhcyB3ZWxsIGFzIGdlbmVyYWwp LCBub3RpZmljYXRpb25zLCBidXQgaXQgc2hvdWxkIG5vdCBiZSB1c2VkIHRvIGNhcnJ5IGFueSBz ZXNzaW9uIHBhcmFtZXRlcnMgb3IgbWVhbmluZ2Z1bCBkYXRhLiBBIFJFU1QgQVBJIHdvdWxkIGJl IGJldHRlciBmb3IgdGhhdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIFR1ZSwgQXVnIDMwLCAyMDE2IGF0IDI6NDkgUE0sIEFsZXhhbmRlciBS b3Njb2UgJmx0OzxhIGhyZWY9Im1haWx0bzphbGV4YW5kZXIucm9zY29lQGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmFsZXhhbmRlci5yb3Njb2VAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIGxvb2tpbmcgYXQgdGhlIG1l Y2hhbmlzbXMgdG8gY29tbXVuaWNhdGUgY2FwdGl2ZSBwb3J0YWwgc3RhdGVzIHRvPGJyPg0KdXNl cnMuIEkgdGhpbmsgYSBSRVNUZnVsIEFQSSB3b3VsZCBiZSB2aWFibGUgY2FuZGlkYXRlIGZvcjxi cj4NCmNvbW11bmljYXRpbmcgdGhpcyBpbmZvcm1hdGlvbi4mbmJzcDsgVGhlIHNhbWUgVVJMIGZy b20gUkZDNzcxMCBvciB0aGUgVVJMPGJyPg0KZ2l2ZW4gYnkgdGhlIDMwMiByZWRpcmVjdCBjb3Vs ZCBiZSB1c2VkIHRvIGFzIHRoZSBlbmRwb2ludCBmb3IgdGhpczxicj4NCnNlcnZpY2UgYXMgd2Vs bC4mbmJzcDsgQ2xpZW50cyBjb3VsZCByZWFjaCBvdXQgdG8gdGhpcyBlbmRwb2ludCB0byBnZXQ8 YnI+DQpzdGF0dXMgc3VjaCBhcyAmcXVvdDtUaW1lIFJlbWFpbmluZyZxdW90OyBvciAmcXVvdDtU WC9SWCB0cmFuc2ZlcnJlZCZxdW90Oy4mbmJzcDsgUkVTVGZ1bDxicj4NCmludGVyZmFjZXMgY2Fu IGJlIGVhc2lseSBzZXR1cCBhbmQgY2FuIGJlIGVhc2lseSBleHRlbmRlZCB0byBhZGQgbmV3PGJy Pg0KZmVhdHVyZXMuPGJyPg0KPGJyPg0KQWxvbmcgc2lkZSBSRVNULCBJIHdhcyBsb29raW5nIGF0 IHRoZSBJQ01QIGFzIGEgY29uZHVpdCB0byB0cmFuc21pdDxicj4NCnRoaXMgaW5mb3JtYXRpb24g YXMgd2VsbC4mbmJzcDsgSW5mb3JtYXRpb24gY291bGQgYmUgcHVzaGVkIHRvIHRoZSBjbGllbnRz Jzxicj4NCmRldmljZSBhbmQgdGhlbiBkaWdlc3RlZCByYXRoZXIgdGhhbiBwdWxsZWQgbGlrZSBh IFJFU1RmdWwgcHJvdG9jb2wuPGJyPg0KSSB0aGluayBhbiBpbXBsZW1lbnRhdGlvbiBvZiB0aGlz IHNldHVwIGNvdWxkIHdvcmsgd2VsbCBvbiBhPGJyPg0KZGVwbG95bWVudCB3aGVyZSB0aGUgQUFB IHNlcnZlciByZXNpZGVzIG9uIHRoZSBzYW1lIHN5c3RlbSBhcyB0aGU8YnI+DQpnYXRld2F5IGJl Y2F1c2UgdGhlIGluZm9ybWF0aW9uIGluIHRoZSBJQ01QIGlzIGVhc2lseSBhY2Nlc3NpYmxlLjxi cj4NCldoZW4gdGhlIEFBQSBzZXJ2ZXIgZXhpc3RzIG9uIGFub3RoZXIgc3lzdGVtIGl0IG1heSBw b3NlIGEgcHJvYmxlbS48YnI+DQpGb3IgZXhhbXBsZSwgbWFueSBuZXR3b3JrcyB0aGF0IHVzZSBj YXB0aXZlIHBvcnRhbHMgYmxvY2sgZXh0ZXJuYWw8YnI+DQpJQ01QIG1lc3NhZ2VzIGFuZC9vciBO QVQgZGV2aWNlcyB0byBjbGllbnQsIHRoZXJlZm9yZSB0aGUgZ2F0ZXdheTxicj4NCndvdWxkIG5l ZWQgdG8gcHJveHkgdGhlc2UgcGFja2V0cy4mbmJzcDsgVGhpcyBhZGRzIG1vcmUgY29tcGxleGl0 eSB0byB0aGU8YnI+DQpuZXR3b3JrIGRlc2lnbi4gQWxzbywgSUNNUCBtZXNzYWdlIHdvdWxkIGJl IHZlcnkgcmlnaWQgYW5kIG5vdCBhczxicj4NCmV4dGVuZGFibGUgYXMgYSBSRVNUZnVsIHNlcnZp Y2UuIE1heWJlIHJpZ2lkIG1pZ2h0IGJlIGEgZ29vZCB0aGluZz88YnI+DQo8YnI+DQpUaG91Z2h0 cz8mbmJzcDsgRGlkIEkgbWlzcyBhbm90aGVyIHR5cGUgb2YgY29uZHVpdCB0byB0cmFuc2ZlciBz dGF0dXMuLi48YnI+DQpleGNsdWRpbmcgU09BUCA6KTxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjoj ODg4ODg4Ij48YnI+DQo8c3BhbiBjbGFzcz0ibS01NTg1NTE5MjcwMzA3MjM3MzYxaG9lbnpiIj4t LTwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0ibS01NTg1NTE5MjcwMzA3MjM3MzYxaG9lbnpiIj5B bGV4YW5kZXIgUm9zY29lPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJtLTU1ODU1MTkyNzAzMDcy MzczNjFob2VuemIiPjxhIGhyZWY9InRlbDo0ODQtNzE2LTkwNDgiIHRhcmdldD0iX2JsYW5rIj40 ODQtNzE2LTkwNDg8L2E+PC9zcGFuPjxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJtLTU1ODU1MTky NzAzMDcyMzczNjFob2VuemIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJtLTU1ODU1MTkyNzAzMDcyMzczNjFo b2VuemIiPkNhcHRpdmUtcG9ydGFscyBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPg0KPHNwYW4gY2xh c3M9Im0tNTU4NTUxOTI3MDMwNzIzNzM2MWhvZW56YiI+PGEgaHJlZj0ibWFpbHRvOkNhcHRpdmUt cG9ydGFsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPkNhcHRpdmUtcG9ydGFsc0BpZXRmLm9y ZzwvYT48L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9Im0tNTU4NTUxOTI3MDMwNzIzNzM2MWhvZW56 YiI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jYXB0aXZl LXBvcnRhbHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2NhcHRpdmUtcG9ydGFsczwvYT48L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E8355113905631478EFF04F5AA706E983109ADBBwtlexchp2sandvi_--