IETF Logo Mail Archive

Re: [babel] Secdir last call review of draft-ietf-babel-rtt-extension-04

David Schinazi <dschinazi.ietf@gmail.com> Tue, 10 October 2023 20:37 UTC

Return-Path: <dschinazi.ietf@gmail.com>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0134EC1519A5; Tue, 10 Oct 2023 13:37:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUk5B5DicZ05; Tue, 10 Oct 2023 13:37:21 -0700 (PDT)
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57135C15171B; Tue, 10 Oct 2023 13:37:21 -0700 (PDT)
Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-9ae7383b7ecso51695266b.0; Tue, 10 Oct 2023 13:37:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696970239; x=1697575039; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=4tB4xUq2afKAq6GpUpLKCvgCrfvqwid3zrGDCNrkbiY=; b=YyIKPIKBRmiotmRYdGhmozYpQVeuBnqe4Gi5sRubnmxutf+y1u9HcFvxru22j/HKR0 tAGofKOV0uy2Zde+u12s2T9T/PE8rnNZrUFdIAH7F3fNIuhiXDA9v/0xvJX29OP6snPl ktBAZ1NAsYGXtGkYTHvA+aAFHmsXqLfygj3t/6qYXfKtf/dtfdCfJ4/wlzJ3e7o4AOLH F/WYN+b0vjZPhr0mqJWPgkadwp3pHYljEZyGFwLB5SR0bxjfhonbWm20xvyS9d3i6Y2h nvsGREaXDo1nPMdTcH9AS3q1+Edal/yult7pPf3cjMhrzHvYtuGUHrN2OyKnyiJLam5D fuUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696970239; x=1697575039; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=4tB4xUq2afKAq6GpUpLKCvgCrfvqwid3zrGDCNrkbiY=; b=r7Soxmaq4kM9XzwR5rEpnzVsH3j4Y+Msb8IOf/dEy0wlHV4eISM2tntt0jCJ0pe6ai 1EXEKQTJjoRUfOA5Stze70wBky4IxAOZEp1hSaAAXtVA1msMuboBxcZXomY2+4bzkD9l eEITaOhLl2ZyVNAYGiM30sveHzRszrPuwCalADXrx3CfFGn/srbNijw3ZYOCanValbQ0 r1q0AWBNTBIrhOSp/5blJXHwwoxsKE+K6TlF6z/xrgk228/9Ho7g6R51Dd1B6NF4Nsx4 eQ3nmas4drCgOkJDK3oXRewD9IPc/5hqc0UNnU+8dDmJmEOKX4iutkvPnZMj/hqw+CUc Q+ow==
X-Gm-Message-State: AOJu0YydLWNOtnFb3L1yEEJOpZV+49+15pC7SwAhopzh7gZLVqHgHQwr gV+hQVzQRnT4MvPunull5GtmfHDYhoDshmA13EaGluzL
X-Google-Smtp-Source: AGHT+IGSGwtf0UTNdvXBe72NLLu6ciUEYz8bnhRnpfF9sVChY2sDbG+8o5rc63OyD5ky4V34R/8qvi7lcJegL8b114Y=
X-Received: by 2002:a17:907:7291:b0:9ad:8641:e91b with SMTP id dt17-20020a170907729100b009ad8641e91bmr14506372ejc.11.1696970239208; Tue, 10 Oct 2023 13:37:19 -0700 (PDT)
MIME-Version: 1.0
References: <169690561656.636.8204474299201117349@ietfa.amsl.com> <87bkd6ztdk.wl-jch@irif.fr> <CAG3f7MjdVbd9F9n1tEfnxdiEg2TZG=rtDBojgaSZTQEcbsEPyw@mail.gmail.com>
In-Reply-To: <CAG3f7MjdVbd9F9n1tEfnxdiEg2TZG=rtDBojgaSZTQEcbsEPyw@mail.gmail.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Tue, 10 Oct 2023 13:37:07 -0700
Message-ID: <CAPDSy+6cRezEKKEuLhZekY8rmG0=aDm_JtGkooWaaExaefOPRg@mail.gmail.com>
To: Shivan Kaul Sahib <shivankaulsahib@gmail.com>
Cc: Juliusz Chroboczek <jch@irif.fr>, secdir@ietf.org, babel@ietf.org, draft-ietf-babel-rtt-extension.all@ietf.org, last-call@ietf.org
Content-Type: multipart/alternative; boundary="0000000000004d6f7b060762ac3e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/_dxXKCp_vhyKxt0Ha34Om1aTKdM>
Subject: Re: [babel] Secdir last call review of draft-ietf-babel-rtt-extension-04
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Oct 2023 20:37:26 -0000

Hi Shivan,

I'll also note that routing protocol nodes are often border routers that
have privacy properties more similar to a web server than to a web client.
In other words, the location of a server can be public information without
it being a privacy concern, whereas the location of a client can be
privacy-sensitive. A good solution here would be to add a note that
clarifies this and warns against deploying Babel RTT unencrypted on devices
whose network location is privacy-sensitive.

David

On Tue, Oct 10, 2023 at 9:57 AM Shivan Kaul Sahib <shivankaulsahib@gmail.com>
wrote:

> Hi Juliusz,
>
>
>
> On Tue, 10 Oct 2023 at 03:04, Juliusz Chroboczek <jch@irif.fr> wrote:
>
>> Thanks, Shivan.
>>
>> > From reading the Security Considerations of RFC 8966 (last para), it
>> > seems that geolocation privacy was a concern with the original Babel
>> > spec. Allowing extremely-fine-grained (1 microsecond) RTT measurements
>> > makes that infinitely worse, especially for users on mobile or behind
>> > VPNs, who typically have special privacy needs.
>>
>> I agree.  I'll add some wording to that effect to the Security
>> Considerations.
>>
>> > The IETF has thought a lot about privacy concerns with RTT measurement
>> and how
>> > to balance them with operational needs,
>>
>> I'll be grateful for a reference.
>>
>
> https://datatracker.ietf.org/doc/html/rfc9312#section-3.8.2 talks about
> how QUIC makes RTT measurement via spin bit optional, and to avoid outing
> those devices, "all endpoints randomly disable "spinning" for at least one
> eighth of connections, even if otherwise enabled by default".
>
>>
>> Thanks again,
>>
>> -- Juliusz
>>
> _______________________________________________
> babel mailing list
> babel@ietf.org
> https://www.ietf.org/mailman/listinfo/babel
>

v2.23.0 | Report a Bug | By Email