Re: [tsvwg] Secdir last call review of draft-ietf-tsvwg-le-phb-08
Kyle Rose <krose@krose.org> Fri, 15 February 2019 13:26 UTC
Return-Path: <krose@krose.org>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC77B1275F3 for <tsvwg@ietfa.amsl.com>; Fri, 15 Feb 2019 05:26:14 -0800 (PST)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
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 fOpyQPdK8Pbr for <tsvwg@ietfa.amsl.com>; Fri, 15 Feb 2019 05:26:11 -0800 (PST)
Received: from mail-yw1-xc32.google.com (mail-yw1-xc32.google.com [IPv6:2607:f8b0:4864:20::c32]) (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 A6630130FA3 for <tsvwg@ietf.org>; Fri, 15 Feb 2019 05:26:09 -0800 (PST)
Received: by mail-yw1-xc32.google.com with SMTP id u205so3694944ywe.1 for <tsvwg@ietf.org>; Fri, 15 Feb 2019 05:26:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2ypBK/W9ZfqBarDr/2JX3cZTo7Im+f+aGNN3ExIcIYU=; b=q1NWsSNDUGhJdTJsSz2XlcZ6289o5lNbbJ33zN7vffGhSoLnQ4wXy62fle0kJ37FQT +UTBFXYOu7HiWOQoJOvOqMuLBUp8tJh4Zk0OJaLQNGPgEl/JsnVrVpI4G6pPdTDv20JD V3bta29NwxW+jCN7hI13rOPBlV4vzvSRIGvkA=
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=2ypBK/W9ZfqBarDr/2JX3cZTo7Im+f+aGNN3ExIcIYU=; b=Rb/6C/I4y+R1tM5zUm1RfpNgnv2AkPeoPMcKiSkHjf1chlPXFDEeIfQ8Wjbcu8Uxet 5l8FieFVBXdoPtrMwpdkJziReElludRUWVlUBYoviMNhqdS0ffL8OoxMINX8p/CPWa11 JXPwh+Vka/IzXCdvChDr2nz+UiJ0rV587Vn/T/T2bGLaUJRdTIzTtXg1UWgfBHHCUOPJ R7d8dGrKFIaC2cjfqcMwt9zaa1lx2gJUFjVpIO0TNwu7RuCvOFwDri+6LRysQKPw3G7D qBVTx8quUIANAfqDznDl1loDNkX4AnHb7DBi5MTe4OQ3JvyI7ngTMn1APoYU+5Xak5M1 twFA==
X-Gm-Message-State: AHQUAuYhRXQSS8/FMcK4W6eYIgwrkrXNZVCfouoQSN+FKmkuYiALBxV3 MTMG7t2T8hr6/FN0RiyxJsN5beIvm/NB/fOcvaOp9w==
X-Google-Smtp-Source: AHgI3IYGP8IiAC5BYml4+1gZw7tQvjV/qj7ILAypZi2W4nBUMFHzsTVO21jLossn3RlHq6StK3O8XOYnLOV2+7mpYhQ=
X-Received: by 2002:a81:d008:: with SMTP id v8mr7782650ywi.464.1550237168567; Fri, 15 Feb 2019 05:26:08 -0800 (PST)
MIME-Version: 1.0
References: <154992443765.29641.355119587706336977@ietfa.amsl.com> <03bfb567-cc86-56fa-6db1-8a42040a6d97@kit.edu> <CAJU8_nVBMObpDys34Ld7qJPfD5VGZkkvEAssCmAJWEG-etLj9g@mail.gmail.com> <117af28e-cd29-fb47-a93f-37147b6df6b0@kit.edu>
In-Reply-To: <117af28e-cd29-fb47-a93f-37147b6df6b0@kit.edu>
From: Kyle Rose <krose@krose.org>
Date: Fri, 15 Feb 2019 08:25:57 -0500
Message-ID: <CAJU8_nXXCy+KcbgxAb=FQVQbmLOH-E0xVJiyN_k94-jV_tzBfA@mail.gmail.com>
To: "Bless, Roland (TM)" <roland.bless@kit.edu>
Cc: IETF SecDir <secdir@ietf.org>, IETF Discussion Mailing List <ietf@ietf.org>, tsvwg@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c02a020581eeb79e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/ezsfYzuOcc-tyeobcvJoq3JJbfo>
Subject: Re: [tsvwg] Secdir last call review of draft-ietf-tsvwg-le-phb-08
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Feb 2019 13:26:15 -0000
The wording in draft 9 looks great. Thanks! Kyle On Fri, Feb 15, 2019 at 3:43 AM Bless, Roland (TM) <roland.bless@kit.edu> wrote: > Hi Kyle, > > see inline, please. > > Am 14.02.19 um 21:22 schrieb Kyle Rose: > >> > and/or behavior. The reason the privacy impact is unremarkable is > > that it is > > > > > highly likely the case that such traffic is already classifiable > > as unimportant > > > via the sort of traffic analysis that troubles privacy advocates, > when > > > considering the endpoint, payload length, pacing, etc. > > > > The LE DSCP marking does not say that this traffic is "unimportant", > > it basically classifies the traffic as being of low priority/urgency. > > > > > > Right, "unimportant" is the wrong word. I meant "uninteresting" from the > > perspective of an observer interested in learning about the user behind > > some traffic (e.g., a state level actor). Software downloads, for > > instance, are less likely to be interesting for surveillance purposes > > than general web traffic, which is not going to be LE. The net effect of > > marking some packets LE is to reduce the chaff/noise from which > > wheat/signal can be extracted. > > Thank you for this explanation, now I got your point! > > > I think that the statement "However, this disclosed information is > only > > useful if some form of identification happened at the same time" is > > still correct, but probably needs a bit more explanation that this > > is often given due to the IP addresses in the packet. Compared to the > > plethora of traffic analysis possibilities and general privacy > threats > > (e.g., see RFC 6973) the impact of disclosed information by the LE > DSCP > > is likely negligible in most cases. So my suggestion is the following > > text: > > > > "However, this disclosed information is only useful if some form of > > identification happened at the same time, which is often given due to > > the presence of IP addresses in the packet. Compared to the numerous > > traffic analysis possibilities and general privacy threats (e.g., see > > [RFC 6973]) the impact of disclosed information by the LE DSCP is > likely > > negligible in most cases." > > > > > > I think the wording here is a bit awkward, and simultaneity isn't really > > the limiting factor. I might start with: > > > > "However, this disclosed information is useful only if correlation with > > metadata (such as the user's IP address) and/or other flows reveal user > > identity. ..." > > My apologies, but I'm not a native speaker, so some phrases may be > awkward indeed (I think that the RFC editor will catch the most > obvious ones). Thanks for the suggestion. I tried to rephrase > that paragraph based on the better understanding of your point > (will be in the next draft revision). > > > I agree that the multicast congestion-induced loss in LE is no worse > > than congestion problems with multicast in general, but there is a > > subtle difference. the multicast LE replication problem is covered in > > section 9. Depending on the implementation replication of LE > multicast > > packets inside a node may impact other traffic in an undesired way: > > the expectation is that LE packets only scavenge otherwise unused > > resources. I think that this is covered by the first sentence of the > > last paragraph in sec.9: > > While the resource contention problem caused by multicast packet > > replication is also true for other Diffserv PHBs, LE forwarding is > > special, because often it is assumed that LE packets get only > > forwarded in case of available resources at the output ports. > > > > So what is missing in your point of view for a better understanding? > > > > > > Nothing. I think I'm happy with this explanation. > > Ok, great. > > Regards, > Roland >
- [tsvwg] Secdir last call review of draft-ietf-tsv… Kyle Rose
- Re: [tsvwg] Secdir last call review of draft-ietf… Bless, Roland (TM)
- Re: [tsvwg] Secdir last call review of draft-ietf… Kyle Rose
- Re: [tsvwg] Secdir last call review of draft-ietf… Bless, Roland (TM)
- Re: [tsvwg] Secdir last call review of draft-ietf… Kyle Rose