Re: [Captive-portals] Which portion of packet is used for capport enforcement?

Erik Kline <ek@google.com> Mon, 05 March 2018 09:56 UTC

Return-Path: <ek@google.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 93DDD126579 for <captive-portals@ietfa.amsl.com>; Mon, 5 Mar 2018 01:56:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level:
X-Spam-Status: No, score=-2.71 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=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 NfMjSrYfF36a for <captive-portals@ietfa.amsl.com>; Mon, 5 Mar 2018 01:56:00 -0800 (PST)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::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 CC3871241F5 for <captive-portals@ietf.org>; Mon, 5 Mar 2018 01:55:59 -0800 (PST)
Received: by mail-yw0-x22d.google.com with SMTP id m123so3216778ywd.1 for <captive-portals@ietf.org>; Mon, 05 Mar 2018 01:55:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hypMrTGRzc6wGXNiLGVXEgHkyQvkjOyX7sPpcS8ldy4=; b=RbAsTPCq7XKBfABjamS0CA3sLlMOohROXyoOdDo72JaGnCcdEc0WVqpXTAVkryTl8/ DtZJ3FlslU+KpmPEOv31kzoVqAxaDV6VSuaGsFjQ+zplUxOQvapmNLIkLW8tDzXXQ1Eq yA8HnwTztaxcpqWRhunnDHU1QwB8fvkQ2kgKYP86Vq8PDS577gIMARu5B1BVoz7+lSFU /F3EgGo+QFuV06iAqK+B8r0GRJWjc8Y0jnDAufKidjDHkl2+otuIKGeFFCzVvrlPs6tG QnL1UM34k/O+IoxY1ARobMQHkuFq2qoNwU84qo203+1IC6cNJiqLbNeG0/LdV9m2LKvO cdbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hypMrTGRzc6wGXNiLGVXEgHkyQvkjOyX7sPpcS8ldy4=; b=Q90Lt5TmfwldA6kKQxK2qFQL8n58HjnWhdBzIKUEr7dbuEfmNJJgIQbP1L52MZmqVg XDQ//SI09WzZno0i2agSzTJxDpId7YxvVbmIIFcv4TTIu6zaWK7Z+MLBrzP7/169NsG4 2bzT7C4YYdO5JE+hB4ELr0+FGjUpmhCumb2ZK1qijBoQMXACvunua3GQ4dUMxJLZqSS3 L82aNgmy+fAm4lUadrqqjwVIPU8SAhVPlRQutDXDFFR4hMi9Uuq5xw9HVcJ6ySVHwDJy rvGRMLgFytGDOkBXTEXOweEzklGjvG07GmmNWIC3BRNaV4ciIvJ+oRReYS/2aQfvX4LX TAxw==
X-Gm-Message-State: APf1xPDAEDteU04IbckZuvAS7IEheKantvQQpjexJ5QxUMmlN3LR7QCi QCGt9196CmoJMbiTk4K3yCtEemAXtrd22KdLrogorou20ek=
X-Google-Smtp-Source: AG47ELtlOl+xOkD2/zhcGJsW8hxADKU+/uq55DFDUUXtYz0m3T4JhWBM6aPkQiLCOWLMxEDgr/xqShgqG/KzgmePsMU=
X-Received: by 10.129.104.137 with SMTP id d131mr8758812ywc.137.1520243758537; Mon, 05 Mar 2018 01:55:58 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a25:ab51:0:0:0:0:0 with HTTP; Mon, 5 Mar 2018 01:55:37 -0800 (PST)
In-Reply-To: <92548449420341e8b9db51d96f392722@sandvine.com>
References: <92548449420341e8b9db51d96f392722@sandvine.com>
From: Erik Kline <ek@google.com>
Date: Mon, 05 Mar 2018 18:55:37 +0900
Message-ID: <CAAedzxpNCWdkJct5MVN=tXXMTFu_a94PdofNsFGCJAQ3Ot8b9w@mail.gmail.com>
To: Kyle Larose <klarose@sandvine.com>
Cc: "captive-portals@ietf.org" <captive-portals@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="001a1147ff843dc83b0566a75566"
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/3zcjVjGcERLiIiFiL3v0jyMjNk0>
Subject: Re: [Captive-portals] Which portion of packet is used for capport enforcement?
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: Mon, 05 Mar 2018 09:56:01 -0000

Thank you Kyle.

I'll cross-post here my hats-off comment from the related github issue.

"""
Enforcing by IP Prefix, where prefixOf(IPv4 address) == /32 and
prefixOf(IPv6 address) <= 64, seems likely to be simple for both
enforcement and API endpoints (where separate).

We can generally depend on return routability as part of connection
establishment to address spoofing. In the futuristic case of a
QUIC-enabled API endpoint it might well be possible to issue some
commands within a single packet sans return routability. At the moment
the API doesn't really let you do any damage, but this is stuff we
should have documented in the relevant security sections.

Lastly, my biggest remaining concern is that folks might erroneously
assume that "IPv6 == 128bit IPv4", which is just not true (as we know,
but some readers might not). If we were to see deployment of
enforcement points that didn't allow clients to form new IPv6
addresses on the same link and use them freely (i.e. without
re-authenticating) then that could be seen as violating the spirit of
RFC 7934 (and generally be bad for the IPv6 Internet). I can already
imagine the defensive code in Android to use a new IPv6 address for
every captive portal API call, just to be sure. :-/
"""

On 5 March 2018 at 01:51, Kyle Larose <klarose@sandvine.com> wrote:
> Issue number 5 (https://github.com/capport-wg/architecture/issues/5) against
> the captive portal architecture raises the question of which portion of the
> packet to use for capport enforcement. I have uploaded a change to the
> architecture repo to attempt to address this issue:
> https://github.com/capport-wg/architecture/pull/9.
>
> Feel free to read over the pull request and give feedback.
>
> Thanks!
>
> Kyle
>
> Disclaimer:
> This communication (including any attachments) is intended for the use of
> the intended recipient(s) only and may contain information that is
> considered confidential, proprietary, sensitive and/or otherwise legally
> protected. Any unauthorized use or dissemination of this communication is
> strictly prohibited. If you have received this communication in error,
> please immediately notify the sender by return e-mail message and delete all
> copies of the original communication. Thank you for your cooperation.
>
>
> _______________________________________________
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals
>