RE: [**EXTERNAL**] New Version Notification for draft-mudric-6man-lcs-00.txt
Vasilenko Eduard <vasilenko.eduard@huawei.com> Thu, 20 August 2020 17:57 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 317853A0F7C for <ipv6@ietfa.amsl.com>; Thu, 20 Aug 2020 10:57:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 XqwOR96WSHvX for <ipv6@ietfa.amsl.com>; Thu, 20 Aug 2020 10:57:32 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 642593A0F7B for <ipv6@ietf.org>; Thu, 20 Aug 2020 10:57:32 -0700 (PDT)
Received: from lhreml717-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id E94F95AB750C08EDD2C3; Thu, 20 Aug 2020 18:57:29 +0100 (IST)
Received: from msceml706-chm.china.huawei.com (10.219.141.145) by lhreml717-chm.china.huawei.com (10.201.108.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 20 Aug 2020 18:57:29 +0100
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml706-chm.china.huawei.com (10.219.141.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 20 Aug 2020 20:57:29 +0300
Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Thu, 20 Aug 2020 20:57:29 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: "Mudric, Dusan" <dmudric@ciena.com>, Alexandre Petrescu <alexandre.petrescu@gmail.com>, "ipv6@ietf.org" <ipv6@ietf.org>
CC: Dusan Mudric <dusan.mudric@gmail.com>
Subject: RE: [**EXTERNAL**] New Version Notification for draft-mudric-6man-lcs-00.txt
Thread-Topic: [**EXTERNAL**] New Version Notification for draft-mudric-6man-lcs-00.txt
Thread-Index: AQHWdWPoZayyQIxAd0yebuTNaxT/2qk+GGeAgAEY1YCAAAGnAIABiXIA///7VgCAAI8E0A==
Date: Thu, 20 Aug 2020 17:57:28 +0000
Message-ID: <d96f5454d6ec4491967268bd4c36fb8e@huawei.com>
References: <159775749187.6074.7781417320413333605@ietfa.amsl.com> <1F96ECCE-F0EF-4421-AB3E-71E1A3CE5458@ciena.com> <eb68c67487aa4f178756e9452d197774@huawei.com> <9B24B9D1-28D5-468C-88F9-7F124EC288F7@ciena.com> <961413da-36f7-bee1-3b17-7d2013ca1d5d@gmail.com> <EAA6961D-4836-4C40-972C-70BB0B65EB4C@ciena.com> <00493252-56d1-965d-0c85-47ffe6775704@gmail.com> <9FCEF658-F83D-45E2-B8DF-05DB0E356733@ciena.com>
In-Reply-To: <9FCEF658-F83D-45E2-B8DF-05DB0E356733@ciena.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.197.171]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/2QWlDJvss3zRwp0ve8QYz3ZZUQg>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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, 20 Aug 2020 17:57:35 -0000
It is possible to look into "Prefix List" (RFC 4861 terminology), If particular PIO was with "L"="Local" bit set, Then it is possible to use GUA as destination, but LLA as source. Should work. It is radical departure from 6724: " to prefer destination/source address pairs for which the two addresses are of equal scope or type ..." I am not sure that any other RFC would not block this approach. I do not see any blocking factor. Let's others speak. PS: I do not believe that it is possible to map Destination GUA to Destination LLA. Eduard -----Original Message----- From: Mudric, Dusan [mailto:dmudric@ciena.com] Sent: 20 августа 2020 г. 16:08 To: Alexandre Petrescu <alexandre.petrescu@gmail.com>; Vasilenko Eduard <vasilenko.eduard@huawei.com>; ipv6@ietf.org Cc: Dusan Mudric <dusan.mudric@gmail.com> Subject: Re: [**EXTERNAL**] New Version Notification for draft-mudric-6man-lcs-00.txt On 2020-08-18, 4:04 PM, "Vasilenko Eduard" <vasilenko.eduard@huawei.com> wrote: > > Hi Dusan, Hi Alexandere, [Alex] Thank you for the reply. We carefully consider the comments. We identified a corner case of communicating on the same link. In this corner case the RFC6724 recommendation creates a security problem. Rather, we recommend to use the least possible scope that is 'common', i.e. it allows to reach the other. In other words, use a LL src even if the dst is a GUA (GUA on the same link). (maybe the 'least common scope' is not the best. Because by RFC 4291 "Addr Archi" the LL and GUA are not the same common scope, even though one might imagine that link scope is included in a 'global' scope, and thus the least common scope between LL and GUA is the LL scope; it is a notion borrowed from set theory, an intersection; another difficulty with 'least common scope' is that Global in GUA is not a 'scope' but a characteristic of the uniqueness; and 'Global Unicast' is an address 'type', not a scope. To make things worse, 'types' of addresses could be more than just LL ang GUA; other equally legitimate address types are 'unicast', 'multicast' and 'anycast', and also 'Unspecified', 'Loopback', 'Multicast'; and there are sub-types too. So, maybe a more precise recommendation would be to 'use an address type whose scope is the least possible to reach a given destination', or 'least possibly scoped address type', instead of 'least common scope'.) > RFC 6724 does have big attention to choose addresses with smallest > scope - section 3.1. [Alex] That section 3.1 is about mapping multicast scopes to unicast scope, in order to give reason to comparing the scopes of unicast. However, a 1-to-1 mapping between these two scopes is hardly understandable. In particular, there still exists a site-local scope for multicast but no longer for unicast. And, there exist a unicast ULA global scope that is not reachable (it's global in that it is uniquely global, not because it is globally reachable - 'reachable' a word not in dictionary anyways :-). So it's hard to see its multicast counterpart: either it's globally reachable or it's site-local (cant be both). (In a multicast context it's not possible to use a multicast address in the source of the packets; so in a multicast context one couldn't talk about same-scope recommendations. Moreover, there should not be blockage to sending packets of ll scope to global mc scope. _If_ we had a src multicast possibility then yes, there could have been a good recommendation of same-scope src-to-dst multicast-to-multicast packets. But we are not concerned with that here.) Because of the impossibility of the mapping that I mention above, it's impossible to come up with rules of same scope use in unicast context. And thus the effort of mapping seems without success. > Then scope is at the second priority for section 5 "Source Address > Selection". [Alex] Rule 2 might not lead to what we want. The execution of that rule using input parameters SA==GUA, SB==LL and D==GUA leads to select SA (a GUA) as src; we dont want GUA in src when the destination is GUA on the same link. [Dusan] It is rather DASA rule 8: Rule 8: Prefer smaller scope. If Scope(DA) < Scope(DB), then prefer DA. Similarly, if Scope(DA) > Scope(DB), then prefer DB. I think the order of address selection should be: - DASA Rule 8 to select LL destination address, preferring the smaller scope, and - SASA Rule 6 will select SA-LL source address that has the same label as destination DA-LL address Section 10.2 example: " Candidate Source Addresses: 2001:db8:1::2 or fe80::2 Destination Address List: 2001:db8:1::1 or fe80::1 Result: fe80::1 (src fe80::2) then 2001:db8:1::1 (src 2001:db8:1::2) (prefer smaller scope)" This means a host needs to autodiscover a destination LL address, before applying DASA Rule 8. The details of this mechanism will be provided. > I have not understood what else you need? IMHO: it is better to > clearly state what particular sentences in RFC 6724 you would like > to change or amend. [Dusan] For ON-LINK D-GUA, SASA cannot be done until On-Link check and LL address resolution are completed. A socket API in RFC5014 would get a destination GUA or ULA, and: - Need to do ON-LINK determination, and - Obtain LL address for ON-LINK destinations (LL address resolution). Otherwise: - Rule 8 can be updated to check if a destination (with its DA-GUA and DB-ULA addresses) is ON-LINK, and obtain and use LL address for ON-LINK destinations. The second approach makes SASA dependent on asynchronous communication with the ON-LINK destination and is not a preferred choice. If the first approach is used, there is no need to update RFC 6724. > I suspect that finally you would come to the problem how to find LLA > for particular GUA? [Alex] Yes, probably that problem. As a solution, it is not impossible to find the LLA of a particular interface that is is present as a field in an entry in a routing table whose first field covers the GUA ('covers' - as identified by a longest-prefix match algorithm). > even for the case when proper GUA prefix is > announced from local router with "L" bit set. Because GUA and LLA > could have different interface ID. [Alex] Yes, could. > GUA has been fetched from an Active Directory or DNS. [Dusan] Or assigned by DHCPv6 (e.g. a destination host server address) > Where to find LLA for the same host?!? > Is every host should register all their addresses on default > router? to find correspondence. [Dusan] No. > What is the protocol to fetch this correspondence? [Dusan] Host already have defined on-link determination, RFC 4861. If DA_GUA prefix: " - is covered by one of the link's prefixes (e.g., as indicated by the on-link flag in the Prefix Information option)" "A node considers an address to be on-link". The same RFC4861 defines " Address resolution: How nodes determine the link-layer address of an on-link destination (e.g., a neighbor) given only the destination's IP address." If the DA is ON-LINK, a host can resolve DA not only into the link-layer address, but, with extensions, into DA_LL address. > Nope. It would not fly... Not on this planet. > > Correspondence between GUA and ULA is potentially possible to keep > in Active Directory. It looks like operational recommendation to > corporate IT: use ULA and populate it into DNS and Active Directory > with higher priority (if you need GUA at all for internal resources); > use ULA and GUA for ordinary hosts. > > I do not see why you need to change RFC 6724 for this - host should > automatically choose ULA in this scenario. The fact that ULA is more > secure is not a big secret. > > Eduard > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Mudric, Dusan > Sent: 18 августа 2020 г. 16:56 > To: ipv6@ietf.org > Cc: alexandre.petrescu@gmail.com > Subject: FW: [**EXTERNAL**] New Version Notification for draft-mudric-6man-lcs-00.txt > > Hi, > > Please provide comments. > > Thanks a lot, > Dusan. > > On 2020-08-18, 9:31 AM, "internet-drafts@ietf.org" <internet-drafts@ietf.org> wrote: > > > A new version of I-D, draft-mudric-6man-lcs-00.txt > has been successfully submitted by Dusan Mudric and posted to the > IETF repository. > > Name: draft-mudric-6man-lcs > Revision: 00 > Title: Least-Common Scope Communications > Document date: 2020-08-18 > Group: Individual Submission > Pages: 5 > URL: https://urldefense.com/v3/__https://www.ietf.org/internet-drafts/draft-mudric-6man-lcs-00.txt__;!!OSsGDw!f7qBGY2iA8pCnxJAbIUGbxahnxInuh9WqA0MxmIe6D_mOhy38kXzuv1SQv-G$ > Status: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-mudric-6man-lcs/__;!!OSsGDw!f7qBGY2iA8pCnxJAbIUGbxahnxInuh9WqA0MxmIe6D_mOhy38kXzuq3WYxzi$ > Htmlized: https://urldefense.com/v3/__https://tools.ietf.org/html/draft-mudric-6man-lcs-00__;!!OSsGDw!f7qBGY2iA8pCnxJAbIUGbxahnxInuh9WqA0MxmIe6D_mOhy38kXzuvX3ounT$ > Htmlized: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-mudric-6man-lcs__;!!OSsGDw!f7qBGY2iA8pCnxJAbIUGbxahnxInuh9WqA0MxmIe6D_mOhy38kXzuqfeyVD5$ > > > Abstract: > This draft formulates a security problem statement. The problem > arises when a Host uses its Global Unicast Address (GUA) to > communicate with another Host situated on the same link. > > To address this problem, we suggest to select and use addresses of a > least scope that are common. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!OSsGDw!fONP9f1G2DpYm4hiHyFwVVjqExwPBwSwmSlxAzxAgzOnTGru3lZoLcdvdYKG$ > -------------------------------------------------------------------- >
- FW: [**EXTERNAL**] New Version Notification for d… Mudric, Dusan
- RE: [**EXTERNAL**] New Version Notification for d… Vasilenko Eduard
- Re: [**EXTERNAL**] New Version Notification for d… Mudric, Dusan
- RE: [**EXTERNAL**] New Version Notification for d… Vasilenko Eduard
- Re: [**EXTERNAL**] New Version Notification for d… Mark Smith
- Re: [**EXTERNAL**] New Version Notification for d… Mudric, Dusan
- RE: [**EXTERNAL**] New Version Notification for d… Vasilenko Eduard
- Re: [**EXTERNAL**] New Version Notification for d… Alexandre Petrescu
- Re: [**EXTERNAL**] New Version Notification for d… Alexandre Petrescu