Re: [CDNi] Erik Kline's Discuss on draft-ietf-cdni-uri-signing-21: (with DISCUSS)

Erik Kline <ek.ietf@gmail.com> Sun, 18 July 2021 22:42 UTC

Return-Path: <ek.ietf@gmail.com>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B163A1274; Sun, 18 Jul 2021 15:42:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 oVF5djJ2CTmf; Sun, 18 Jul 2021 15:42:17 -0700 (PDT)
Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 7718A3A126E; Sun, 18 Jul 2021 15:42:11 -0700 (PDT)
Received: by mail-ot1-x335.google.com with SMTP id s2-20020a0568301e02b02904ce2c1a843eso5795914otr.13; Sun, 18 Jul 2021 15:42:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=p3FomqXlXg16mnatDGFuwRD1VBWkt7kwHVjIm6HdEA0=; b=kQCqOoCgO+fC5e/Uxu/UIBMj1otX28l/AhF6/rvC6lE5w1baZj9hLTF3PP95jXVeUG GBTAn/yvDvMbKsBlWMwSGqZLHkFMzJPKaZ2ChAK28JrZQXgZ12++1sbv0Ule5NUZr0Wv ou6tdSp4AcSfKY7nbPeOQJAuVr49ipfX3PC2kz7ryttuTWr7xTSW04RbEnbO9+xhp/UZ QapHqdaSGCDrGBFHVw/5pEoudV026Wg6QBJpSkVF/nADvFbGtIEQZICKeChPVzrsddxS QqElKRS6TuVe+kutWpJ8qt3/BLmoR3yR0d6etv6iqZTUWoKkEu4dixwyY0WQSxKgco6m kxEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=p3FomqXlXg16mnatDGFuwRD1VBWkt7kwHVjIm6HdEA0=; b=SgfBl0Na6d0M0inw9Lw4aBjQ1TP9WwFFKFEvme6enWxhnAdu8RNteF1sWpvtoglJAw AOg17Gxk65v357qa37yro2Z/GHCAYnktzUKCqMRK9a4AZZzvc+1YtqmPVVuvhzDGt0sE NwjJzHyoCoLukSE1qaWX3hJkEi/n/hv1JWZgUgJJmUmWbxNK2eBlgjeAnj/Cky+O1u3u ofTXcEfpCz706o8ELORZWOYJ5osEHCwb27Ak83eFGEUXs9mb03torcuO3h4xR9zsguDA f0YHC3FAPT2qh66TK+6OdWxPpkC7fj9sgjz51ROJ5sAIJ2xNogrl031Ov+cmzu96BUb7 F0Cw==
X-Gm-Message-State: AOAM530YxDcS/Q+DyKDJh80vhzmsNrhqSgRLZmOziGoJIzCS5eRtWSgl CE8LGNyUwstinheb7bCJi0v7/s4LBOe3F1pOpFM=
X-Google-Smtp-Source: ABdhPJwMokLnTd5+9PBgPNFHwj5k9DcOiFAbfdT7R3/fPKuzc58ZxEvMNRN5SDGvYgP1HNWqOLsO6Ab6cLKKfP1Y/tE=
X-Received: by 2002:a9d:600a:: with SMTP id h10mr16435903otj.144.1626648129932; Sun, 18 Jul 2021 15:42:09 -0700 (PDT)
MIME-Version: 1.0
References: <161421761865.9253.4878110004580140276@ietfa.amsl.com> <CABF6JR3DnMkCP9OUG0bOb63VcKNXMCKtQ_uxYHL+k+ztjQZeNg@mail.gmail.com>
In-Reply-To: <CABF6JR3DnMkCP9OUG0bOb63VcKNXMCKtQ_uxYHL+k+ztjQZeNg@mail.gmail.com>
From: Erik Kline <ek.ietf@gmail.com>
Date: Sun, 18 Jul 2021 15:41:59 -0700
Message-ID: <CAMGpriV7gDk2jy6o8g=e=Yp-vwhDN_JxPLbXLfMvXaxZ4AMVtQ@mail.gmail.com>
To: Phil Sorber <sorber@apache.org>
Cc: The IESG <iesg@ietf.org>, draft-ietf-cdni-uri-signing@ietf.org, cdni-chairs@ietf.org, "<cdni@ietf.org>" <cdni@ietf.org>, Kevin Ma J <kevin.j.ma@ericsson.com>
Content-Type: multipart/alternative; boundary="000000000000f5912705c76d874e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cdni/X_sc_NJc1ZK_P1iP9lKiYVFsbec>
Subject: Re: [CDNi] Erik Kline's Discuss on draft-ietf-cdni-uri-signing-21: (with DISCUSS)
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" <cdni.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cdni>, <mailto:cdni-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cdni/>
List-Post: <mailto:cdni@ietf.org>
List-Help: <mailto:cdni-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cdni>, <mailto:cdni-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Jul 2021 22:42:20 -0000

Phil,

Thanks for your reply.

I think, if CDNs really want a foot-gun, that perhaps it would suffice to
add some guidance to the operator(s) that they MUST keep the IP address
family support uniform among all the services the UA might attempt to
contact.

For example, if the CSP is dual-stacked then the cdniip might be an IPv6
address and in order to be reasonably effective all xCDNs that might
process the claim MUST also be dual-stacked.

If there were text to this effect that might be as good as we can expect,
although I note that it severely raises the level of effort required to
deploy IPv6 -- which is regrettable (and should perhaps also be noted).

Thanks,
-ek

On Wed, Feb 24, 2021 at 10:06 PM Phil Sorber <sorber@apache.org> wrote:

> Thank you for this thorough review. I have added my responses below.
>
> On Wed, Feb 24, 2021 at 6:47 PM Erik Kline via Datatracker <
> noreply@ietf.org> wrote:
>
>> Erik Kline has entered the following ballot position for
>> draft-ietf-cdni-uri-signing-21: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-cdni-uri-signing/
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> Apologies for piling on, but I want to second Eric Vyncke's Discuss.  The
>> use of Client IP addresses is more problematic than one might suspect from
>> a reading of this document.
>>
>> RFC 8305 Happy Eyeballs means for a dualstack client and a dualstack CSP
>> or
>> CDN there are no guarantees that the address family will be the same.
>>
>> Furthermore, a client using RFC 8981 (4941bis) IPv6 temporary addresses
>> might
>> change source address (even with every request) so an exact match would
>> not be
>> recommended.
>>
>> To make matters even more complicated, a mobile client might make the CSP
>> request on Wi-Fi, walk out of range, and complete a subsequent CDN request
>> via its mobile provider network (or vice versa).  So, even using a fairly
>> short CIDR length for truncation may not work since the origin network
>> can be
>> completely different between requests.
>>
>> The latter behaviour can also be trigger by connection migration
>> transports,
>> like MPTCP and (soon) QUIC.
>>
>
> Yes, there are definitely caveats to using the Client IP for validation.
> This is really just something that some CSPs want now, but hopefully they
> will use something like this in a limited fashion. Perhaps there can be
> value in using this with signed token renewal where the Client IP is only
> validated on the first round trip. When combined with jti and a short JWT
> lifetime, you can be reasonably assured that the chain would only be able
> to continue for the correct user. If the IP had already changed by that
> point, the client visible failure would be at the very beginning instead of
> interrupting some long playing media.
>
>
>>
>> I think one solution might include relaxing all the MUSTs in section
>> 2.1.10.
>> Instead, perhaps some text that clarifies the presence of reliability
>> issues
>> with Client IPs and recommends that CDNs be develop a more sophisticated
>> policy (or avoid using this altogether and prefer to use other claims).
>> Including the Client IP for logging purposes might be helpful, but being
>> too
>> strict about verifying it can lead to client-visible failures.
>>
>
> I think additional guidance could be useful, but I don't think we can
> relax the validation. Content owners really want to know how it will be
> validated if they are including it in the first place. And as this is
> duplication of a legacy feature, it really makes sense to have it behave as
> similarly as possible. Principle of least surprise.
>
>
>>
>> Alternatively, UAs need to be augmented to know that when a cdniip is part
>> of the claim that it must try to keep the source IP address the same for
>> subsequent requests, recognizing, as section 7 does, that NAT can make
>> this
>> impossible.  I'm not sure this is a workable option, though.
>>
>
> We wanted to make this essentially invisible to the UA by leveraging
> existing behavior. I suspect that if we could relax that requirement, we'd
> go a completely different route than anything discussed in this document.
>