RE: I-D Action: draft-ietf-6man-rfc6874bis-01.txt

Vasilenko Eduard <vasilenko.eduard@huawei.com> Thu, 30 June 2022 10:37 UTC

Return-Path: <vasilenko.eduard@huawei.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 CCBF4C15A72B for <ipv6@ietfa.amsl.com>; Thu, 30 Jun 2022 03:37:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Level:
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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
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 XZqM74_40K8y for <ipv6@ietfa.amsl.com>; Thu, 30 Jun 2022 03:37:36 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1093C157B43 for <ipv6@ietf.org>; Thu, 30 Jun 2022 03:37:35 -0700 (PDT)
Received: from fraeml709-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4LYZRr6YzCz687S8; Thu, 30 Jun 2022 18:33:28 +0800 (CST)
Received: from mscpeml100001.china.huawei.com (7.188.26.227) by fraeml709-chm.china.huawei.com (10.206.15.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Thu, 30 Jun 2022 12:37:32 +0200
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by mscpeml100001.china.huawei.com (7.188.26.227) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Thu, 30 Jun 2022 13:37:32 +0300
Received: from mscpeml500001.china.huawei.com ([7.188.26.142]) by mscpeml500001.china.huawei.com ([7.188.26.142]) with mapi id 15.01.2375.024; Thu, 30 Jun 2022 13:37:32 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Brian Carpenter <brian.e.carpenter@gmail.com>
CC: 6man WG <ipv6@ietf.org>
Subject: RE: I-D Action: draft-ietf-6man-rfc6874bis-01.txt
Thread-Topic: I-D Action: draft-ietf-6man-rfc6874bis-01.txt
Thread-Index: AQHYSu523qwOM60wqEqke88lJqADaazlGMyAgEBUkwCAQr4wcP//3YiAgAA5WaA=
Date: Thu, 30 Jun 2022 10:37:32 +0000
Message-ID: <2de18ad0ef784ad19148d215221178a4@huawei.com>
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>
In-Reply-To: <CANMZLAZPuA_Yey4tG0orU0m5Y3rmZhB84p8Pk_aXhu707mygNA@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.81.197.212]
Content-Type: multipart/alternative; boundary="_000_2de18ad0ef784ad19148d215221178a4huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/2ejeeAY_UIx5bXnavQQc1a3_edE>
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 10:37:37 -0000

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<mailto: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<mailto:ipv6-bounces@ietf.org>] On Behalf Of Brian E Carpenter
Sent: Thursday, May 19, 2022 3:53 AM
To: ipv6@ietf.org<mailto: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<mailto: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<mailto: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<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------