Re: I-D Action: draft-ietf-6man-rfc6874bis-01.txt
Ted Lemon <mellon@fugue.com> Thu, 30 June 2022 12:45 UTC
Return-Path: <mellon@fugue.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF74DC15C7C0 for <ipv6@ietfa.amsl.com>; Thu, 30 Jun 2022 05:45:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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_BLOCKED=0.001, 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=fugue-com.20210112.gappssmtp.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 SYPWFBu_Uq1O for <ipv6@ietfa.amsl.com>; Thu, 30 Jun 2022 05:45:02 -0700 (PDT)
Received: from mail-oa1-x2f.google.com (mail-oa1-x2f.google.com [IPv6:2001:4860:4864:20::2f]) (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 B488EC15A74D for <ipv6@ietf.org>; Thu, 30 Jun 2022 05:45:02 -0700 (PDT)
Received: by mail-oa1-x2f.google.com with SMTP id 586e51a60fabf-10bab338f70so932336fac.7 for <ipv6@ietf.org>; Thu, 30 Jun 2022 05:45:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WKvsKcMuieLivuTY9TBPE3m3el0WzmVuLYfMuIqTC0U=; b=05H/pMj07c+iN8t1Qz0xhJKAEP8QnbTLg7/CjemSyTbLoP0SPo+3bk2fSZtAKCY+lN I8n1NuO+S8gwVy9C38k03N8oe4+0u4UE/YV2udPf5PLeIf3z0Trx5786MijUb4nt7OFr 7DtES9SUZKTpQUkRKqyJ9V/5GwzECxujloYMV+VXsaO9vl+1SOnFW8x8eAjqGP2auI/G 8H12LYZqiK+iL/DSmpaKpeV3GwjaTRPF40L5CJ5nphsDXevv9cR95ZuggoZcMW/3WRhe VOYnC0uRGvLQc/yM0ZxzIiV+st9AxlEYl7xtwHb2sefQULdC3PTKvl3RLvf8S4kSKhJj omRg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WKvsKcMuieLivuTY9TBPE3m3el0WzmVuLYfMuIqTC0U=; b=whd0wkry3RBPJ8+40JLHDH6XSveRlYOCZ47kjAC9UyY43Kjkw6J2DcMDEL5fqcRQTD rZ1xfKugPjh2RwCssaCLkSnEiVBqSdw2AYSIo+aiKWlJyhtzyQefaASvrSSqEvwQDAKC dyeDJQk/rbuS1Ir5gUYMEuzwgimkjHd5CV3XCIpHf2wXwf4oa02hsyxOt6L9FTzZf9Xv aW9tyobb7oV4gL9KnNw89mPt45SuJVWjt34HsotWYGeWUfYOO1ymcBr44uNBO2C3sPnP Fm7RbcP1tvJHVSQMx/KJGcjl2VNQA5X+JKiNM8BjjJvoUGCks2hpzETK/yj97wTiAPF8 g03w==
X-Gm-Message-State: AJIora+VMvl56dBi5hwyXCCE4TSnSMx6xaBVRqv3vYdDw2sYsenQrSxE fjuWKGfwtwq5RqO4OJxCaZuYiRgUplvSBizITOp6kg==
X-Google-Smtp-Source: AGRyM1sF/COGgAGrzgyrJgHdIvcNrusLEfsRnun/46hYHOH9vSQBI2pnhWaOR9gVDOMBqAj7Pe2/Nb0cu+cHxFYZUxk=
X-Received: by 2002:a05:6870:f287:b0:109:d5fb:15be with SMTP id u7-20020a056870f28700b00109d5fb15bemr5095134oap.12.1656593101484; Thu, 30 Jun 2022 05:45:01 -0700 (PDT)
MIME-Version: 1.0
References: <164938402532.17740.11717866110301931501@ietfa.amsl.com> <b1780128-2069-b32e-7ca5-86977c119f0c@gmail.com> <11d4e419-11a9-8768-abf2-1335e5f1c3d8@gmail.com> <f650c051650b4e5891b80dafb2dfaaaa@huawei.com> <CANMZLAZPuA_Yey4tG0orU0m5Y3rmZhB84p8Pk_aXhu707mygNA@mail.gmail.com> <2de18ad0ef784ad19148d215221178a4@huawei.com>
In-Reply-To: <2de18ad0ef784ad19148d215221178a4@huawei.com>
From: Ted Lemon <mellon@fugue.com>
Date: Thu, 30 Jun 2022 05:44:50 -0700
Message-ID: <CAPt1N1nhzYCZB88GfMxh8Txf8qDTVjQPdkh8di22a+D2ipwZ0w@mail.gmail.com>
Subject: Re: I-D Action: draft-ietf-6man-rfc6874bis-01.txt
To: Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org>
Cc: 6man WG <ipv6@ietf.org>, Brian Carpenter <brian.e.carpenter@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000005a070a05e2a9a324"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/apuZclAeF-85D0n7AYA3xr-4auY>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jun 2022 12:45:03 -0000
With GUA/ULA you have to guess the prefix. LLAs all share the same prefix. So you have a lot fewer bits to guess with a LLA. Of course, you might be able to get the GUA prefix by connecting to some service, but this won’t work for ULA. On Thu, Jun 30, 2022 at 03:37 Vasilenko Eduard <vasilenko.eduard= 40huawei.com@dmarc.ietf.org> wrote: > I do not see the difference from the scan of the local GUA/ULA subnet (it > does not need a zone too). > > Why improve security only for LLA, leaving GUA/ULA with the same level of > security? > > IMHO: it does not make sense. The attacker would scan GUA/ULA if LLA is > more difficult. He would get his result anyway. > > > > Moreover, the interface name is a challenge only for the legitimate user. > > An attacker could easily find the type of the operating system and guess > it. > > It is weak protection against attacker. > > > > Moreover2, a daemon to listen for port 80 would have much more probability > to be connected to GUA/ULA, not LLA. > > The attacker would probably start scanning from GUA anyway. > > > > Hence, better to give the user more convenience because security is not > possible to improve in this way. > > Ed/ > > *From:* Brian Carpenter [mailto:brian.e.carpenter@gmail.com] > *Sent:* Thursday, June 30, 2022 1:03 PM > *To:* Vasilenko Eduard <vasilenko.eduard@huawei.com> > *Cc:* 6man WG <ipv6@ietf.org> > *Subject:* Re: I-D Action: draft-ietf-6man-rfc6874bis-01.txt > > > > There is an opposite argument: supporting a default zone makes an attack > easier because the zone does not need to to be guessed. > > Windows does exactly what you suggest, by the way; I could not run my > tests on Linux. > > Regards, > Brian Carpenter > (via tiny screen & keyboard) > > > > > On Thu, 30 Jun 2022, 21:22 Vasilenko Eduard, <vasilenko.eduard@huawei.com> > wrote: > > Hi Brian, > Just one small idea: does it make sense to request > "All applications claiming support for this document SHOULD choose one LLA > zone as the default. > If the user would omit the zone for the literal request to fe80:: then the > application SHOULD use the default zone". > It would greatly simplify life for many users because they have only one > interface on the host - they would never need to investigate the name of > the zone that is very OS-specific. > > I do not like the request in RFC 4007: > index value zero at each scope SHOULD be reserved to mean "use the default > zone" > IMHO: it is much better to omit the zone name completely to get access to > the default zone. > People may not know that zone 0 has a special meaning. > > Formally, what I have proposed does not contradict RFC 4007 > Because the default zone could be omitted and could be 0 at the same time > (both would lead to the same default zone). > > If you would say "No" to this request > Then please, repeat RFC 4007 that the default zone SHOULD be and SHOULD be > "0". > Please, remind people of this fact. > Eduard > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter > Sent: Thursday, May 19, 2022 3:53 AM > To: ipv6@ietf.org > Subject: Re: I-D Action: draft-ietf-6man-rfc6874bis-01.txt > > There's been no more discussion for several weeks. Can we move on to a WG > Last Call? > > Regards > Brian Carpenter > On 08-Apr-22 14:29, Brian E Carpenter wrote: > > Hi, > > > > This version reflects comments at the IETF and on the list. > > Change log: > > * Extended use cases (added Microsoft WSD) > > * Clarified relationship with RFC3986 language > > * Allow for legacy use of RFC6874 format > > * Augmented security considerations > > * Editorial and reference improvements > > > > Note that some of the text about RFC3986 that Shang Ye suggested to > > remove has been retained, but modified. Further comments about this, > > or any other aspect, are very welcome. > > > > Regards > > Brian + co-authors > > > > On 08-Apr-22 14:13, internet-drafts@ietf.org wrote: > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. > >> This draft is a work item of the IPv6 Maintenance WG of the IETF. > >> > >> Title : Representing IPv6 Zone Identifiers in > Address Literals and Uniform Resource Identifiers > >> Authors : Brian Carpenter > >> Stuart Cheshire > >> Robert M. Hinden > >> Filename : draft-ietf-6man-rfc6874bis-01.txt > >> Pages : 13 > >> Date : 2022-04-07 > >> > >> Abstract: > >> This document describes how the zone identifier of an IPv6 scoped > >> address, defined as <zone_id> in the IPv6 Scoped Address > Architecture > >> (RFC 4007), can be represented in a literal IPv6 address and in a > >> Uniform Resource Identifier that includes such a literal address. > It > >> updates the URI Generic Syntax and Internationalized Resource > >> Identifier specifications (RFC 3986, RFC 3987) accordingly, and > >> obsoletes RFC 6874. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/ > >> > >> There is also an HTML version available at: > >> https://www.ietf.org/archive/id/draft-ietf-6man-rfc6874bis-01.html > >> > >> A diff from the previous version is available at: > >> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc6874bis-01 > >> > >> > >> Internet-Drafts are also available by rsync at > >> rsync.ietf.org::internet-drafts > >> > >> > >> _______________________________________________ > >> I-D-Announce mailing list > >> I-D-Announce@ietf.org > >> https://www.ietf.org/mailman/listinfo/i-d-announce > >> Internet-Draft directories: http://www.ietf.org/shadow.html or > >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >
- I-D Action: draft-ietf-6man-rfc6874bis-01.txt internet-drafts
- Re: I-D Action: draft-ietf-6man-rfc6874bis-01.txt Brian E Carpenter
- Re: I-D Action: draft-ietf-6man-rfc6874bis-01.txt… tom petch
- Re: I-D Action: draft-ietf-6man-rfc6874bis-01.txt… Brian E Carpenter
- Re: I-D Action: draft-ietf-6man-rfc6874bis-01.txt… tom petch
- Re: I-D Action: draft-ietf-6man-rfc6874bis-01.txt Brian E Carpenter
- Next step for draft-ietf-6man-rfc6874bis Brian E Carpenter
- Re: Next step for draft-ietf-6man-rfc6874bis Philipp S. Tiesel
- Re: Next step for draft-ietf-6man-rfc6874bis Bob Hinden
- Re: Next step for draft-ietf-6man-rfc6874bis Brian E Carpenter
- Re: Next step for draft-ietf-6man-rfc6874bis Jen Linkova
- Re: Next step for draft-ietf-6man-rfc6874bis Brian E Carpenter
- Re: Next step for draft-ietf-6man-rfc6874bis Philipp S. Tiesel
- Re: Next step for draft-ietf-6man-rfc6874bis Brian E Carpenter
- Re: Next step for draft-ietf-6man-rfc6874bis Philipp S. Tiesel
- Re: Next step for draft-ietf-6man-rfc6874bis Brian E Carpenter
- Scripting attacks [was Next step for draft-ietf-6… Brian E Carpenter
- Re: Scripting attacks [was Next step for draft-ie… Carsten Bormann
- Re: Scripting attacks [was Next step for draft-ie… Brian E Carpenter
- Re: Scripting attacks [was Next step for draft-ie… Ted Lemon
- Re: Scripting attacks [was Next step for draft-ie… Carsten Bormann
- Re: Scripting attacks [was Next step for draft-ie… Ted Lemon
- Re: Scripting attacks [was Next step for draft-ie… Brian E Carpenter
- Re: Scripting attacks [was Next step for draft-ie… Carsten Bormann
- RE: I-D Action: draft-ietf-6man-rfc6874bis-01.txt Vasilenko Eduard
- Re: I-D Action: draft-ietf-6man-rfc6874bis-01.txt Brian Carpenter
- RE: I-D Action: draft-ietf-6man-rfc6874bis-01.txt Vasilenko Eduard
- Re: I-D Action: draft-ietf-6man-rfc6874bis-01.txt Ted Lemon
- RE: I-D Action: draft-ietf-6man-rfc6874bis-01.txt Vasilenko Eduard
- Re: Scripting attacks [was Next step for draft-ie… Kerry Lynn
- Re: I-D Action: draft-ietf-6man-rfc6874bis-01.txt Ted Lemon
- RE: Scripting attacks [was Next step for draft-ie… Vasilenko Eduard
- RE: I-D Action: draft-ietf-6man-rfc6874bis-01.txt Vasilenko Eduard
- Re: I-D Action: draft-ietf-6man-rfc6874bis-01.txt Ted Lemon
- Re: Scripting attacks [was Next step for draft-ie… Fernando Gont
- Re: Scripting attacks [was Next step for draft-ie… Fernando Gont
- Re: Scripting attacks [was Next step for draft-ie… Fernando Gont
- Re: I-D Action: draft-ietf-6man-rfc6874bis-01.txt Brian E Carpenter
- Re: Scripting attacks [was Next step for draft-ie… Brian E Carpenter
- Re: Scripting attacks [was Next step for draft-ie… Brian E Carpenter
- Re: I-D Action: draft-ietf-6man-rfc6874bis-01.txt Brian E Carpenter
- Re: Scripting attacks [was Next step for draft-ie… Brian E Carpenter
- Re: Scripting attacks [was Next step for draft-ie… Simon
- Re: Scripting attacks [was Next step for draft-ie… Brian E Carpenter
- Re: Scripting attacks [was Next step for draft-ie… Michael Richardson
- Re: Scripting attacks [was Next step for draft-ie… Ted Lemon
- Re: Scripting attacks [was Next step for draft-ie… Brian E Carpenter
- Re: Scripting attacks [was Next step for draft-ie… Michael Richardson
- Re: Scripting attacks [was Next step for draft-ie… Brian E Carpenter