Re: [Captive-portals] Review of draft-wkumari-capport-icmp-unreach-01
Dave Dolson <ddolson@sandvine.com> Sun, 02 April 2017 19:04 UTC
Return-Path: <ddolson@sandvine.com>
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 D3BFD126BF6; Sun, 2 Apr 2017 12:04:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 fX5oXXwp5_QZ; Sun, 2 Apr 2017 12:04:51 -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 BD468129512; Sun, 2 Apr 2017 12:04:50 -0700 (PDT)
Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by wtl-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Sun, 2 Apr 2017 15:04:48 -0400
From: Dave Dolson <ddolson@sandvine.com>
To: David Bird <dbird@google.com>, Martin Thomson <martin.thomson@gmail.com>
CC: "draft-wkumari-capport-icmp-unreach@ietf.org" <draft-wkumari-capport-icmp-unreach@ietf.org>, "captive-portals@ietf.org" <captive-portals@ietf.org>
Thread-Topic: [Captive-portals] Review of draft-wkumari-capport-icmp-unreach-01
Thread-Index: AQHSqyleEwF1MXKPrUeu4OD48IzTzKGxeh2AgAD3j/U=
Date: Sun, 02 Apr 2017 19:04:48 +0000
Message-ID: <20170402190447.7209037.92389.5290@sandvine.com>
References: <CABkgnnXkDSnn2C3cFtdcsX+chDMqnbZO9t5pp4dVMaVLQPXAig@mail.gmail.com>, <CADo9JyXScL4sDtx13pPAanfAoBj0mE4f9D-pGRXDcmKqPz4K+Q@mail.gmail.com>
In-Reply-To: <CADo9JyXScL4sDtx13pPAanfAoBj0mE4f9D-pGRXDcmKqPz4K+Q@mail.gmail.com>
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_201704021904477209037923895290sandvinecom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/umHOdGL6_uW8LoejugX8U7Db2Xo>
Subject: Re: [Captive-portals] Review of draft-wkumari-capport-icmp-unreach-01
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of issues related to captive portals <captive-portals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/captive-portals/>
List-Post: <mailto:captive-portals@ietf.org>
List-Help: <mailto:captive-portals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 02 Apr 2017 19:04:53 -0000
David, Thanks. I see you have added more information to the ICMP packet. This of course makes validating the ICMP message more important, whereas if the ICMP packet were only a trigger to visit the API, it would be the API that implements the security. My opinion has been that the ICMP message should only say "unreachable because captive portal", which makes the ICMP risk only a DoS concern -- no different than ICMP today -- which if a real concern should be addressed for the ICMP protocol in general. David Dolson Sandvine From: David Bird Sent: Saturday, April 1, 2017 8:18 PM To: Martin Thomson Cc: draft-wkumari-capport-icmp-unreach@ietf.org; captive-portals@ietf.org Subject: Re: [Captive-portals] Review of draft-wkumari-capport-icmp-unreach-01 I've updated the draft to -02 - sorry for not doing so sooner. Contributors (and co-authors) welcome! On Sat, Apr 1, 2017 at 1:40 PM, Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>> wrote: (As a contributor only.) David, Warren, Looking at this draft, I think that there are a few fairly major changes that this could benefit from. # Extension payload The presence of the extension is sufficient signaling for this channel. If we accept that there will be a protocol for asking the portal for basic information about connectivity, the UE/device/etc can query that interface for expiration time. The warning bit seems dangerous in this context given that it establishes a non-backwards-compatible behaviour. To an entity that doesn't understand this extension, ICMP Unreachable means that the packet was not forwarded. I don't think that an extension can safely change this. The one obvious caveat for this comment is if we determine that RFC 7710 is insufficient for advertisement of the captive portal URL. In that case, we might consider adding the URL to the ICMP message. I don't see any evidence that this is necessary yet, and that would compound the next issue, but it's something to consider. # Security considerations There is a fairly direct path between this message and a user visiting the site identified. Now, it is well-accepted that it is easy to cause a user to visit any site, but nonetheless this needs to be discussed. We can also offer some suggestions for reducing the use of this message by arbitrary endpoints. For example, a device that receives this message might not act immediately, but instead trigger portal detection routines before opening a browser. Those routines might involve sending more packets and looking for more ICMP unreachable packets. For this reason, I think that we should mandate the use of RFC 4884 and a minimum size for the echo of the dropped packet.
- [Captive-portals] Review of draft-wkumari-capport… Martin Thomson
- Re: [Captive-portals] Review of draft-wkumari-cap… David Bird
- Re: [Captive-portals] Review of draft-wkumari-cap… Dave Dolson
- Re: [Captive-portals] Review of draft-wkumari-cap… David Bird
- Re: [Captive-portals] Review of draft-wkumari-cap… Dave Dolson
- Re: [Captive-portals] Review of draft-wkumari-cap… David Bird