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
> --------------------------------------------------------------------
>