RE: New Version Notification for draft-mudric-6man-lcs-01.txt
Vasilenko Eduard <vasilenko.eduard@huawei.com> Tue, 20 October 2020 17:49 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 CABAE3A132A for <ipv6@ietfa.amsl.com>; Tue, 20 Oct 2020 10:49:57 -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 BFqLMtyKKVH0 for <ipv6@ietfa.amsl.com>; Tue, 20 Oct 2020 10:49:55 -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 7EB7B3A12F5 for <ipv6@ietf.org>; Tue, 20 Oct 2020 10:49:49 -0700 (PDT)
Received: from lhreml724-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id BD34BC5A4EADAD9E96D9; Tue, 20 Oct 2020 18:49:47 +0100 (IST)
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by lhreml724-chm.china.huawei.com (10.201.108.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 20 Oct 2020 18:49:47 +0100
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml703-chm.china.huawei.com (10.219.141.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 20 Oct 2020 20:49:46 +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; Tue, 20 Oct 2020 20:49:46 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: "Mudric, Dusan" <dmudric@ciena.com>, Alexandre Petrescu <alexandre.petrescu@cea.fr>, "ipv6@ietf.org" <ipv6@ietf.org>, "alexandre.petrescu@gmail.com" <alexandre.petrescu@gmail.com>, Mark Smith <markzzzsmith@gmail.com>
Subject: RE: New Version Notification for draft-mudric-6man-lcs-01.txt
Thread-Topic: New Version Notification for draft-mudric-6man-lcs-01.txt
Thread-Index: AQHWpvGjUfZmAYyURkWIbvUYaUne8Kmgm9qwgAAoFVA=
Date: Tue, 20 Oct 2020 17:49:46 +0000
Message-ID: <5f4d55b6c8114610939b2372d15e68ac@huawei.com>
References: <C96585F2-B73C-4A6C-A1AA-1588BB8250EB@ciena.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.206.45]
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/3eIxhZTHjQf0jddkdYAVj6IdaM0>
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: Tue, 20 Oct 2020 17:50:04 -0000
Hi Dusan, I believe that this WG would not permit you to hardcode into ND the mandatory resolution for GUA to LLA for local link (to fully prohibit local communicating by GUA). Hence, I have assumed 2 steps: one for address translation, second for transmission itself. I did think more and understood that there is the second option: to have separate API. One would work as it is now. Second API would mandatory translate GUA to LLA. I do not know which one option is worse: both needs application change. Eduard > -----Original Message----- > From: Vasilenko Eduard > Sent: 20 октября 2020 г. 19:46 > To: 'Mudric, Dusan' <dmudric@ciena.com>; Alexandre Petrescu > <alexandre.petrescu@cea.fr>; ipv6@ietf.org; alexandre.petrescu@gmail.com; > Mark Smith <markzzzsmith@gmail.com> > Subject: RE: New Version Notification for draft-mudric-6man-lcs-01.txt > > Hi Dusan, > You have the big progress. It easy to read now and you have the solution (before > you had just the problem). > Unfortunately, it does not work yet. > Let’s imagine that you have the capability to ask server GUA about server LLA. It > is not the solution by itself. Not yet. > You are proposing "special NS", but you are not talking when it should happen. > > Read carefully the beginning of section 7 RFC 6724. Sequence of mechanisms is > counter-intuitive (historical). It looks like you assume the reverse order. > 1st: host should choose next hop! - probably routing > 2nd: host should choose source address (using next hop from previous step, fed > into the SASA algorithm) 3rd (optional): host could choose destination address (if > DNS supply more than one) > > You could ask to break the default order of algorithms: section 7 RFC 6724 does > discuss such possibility (bypass next hop selection, choose source address first > with next hop not defined yet) After SASA host has no any other choice except to > activate next: "Conceptual Model of a Host" (section 5 RFC 4861), especially > "5.2. Conceptual Sending Algorithm". > Where in this chain of events host should ask your "special NS" for GUA to LLA > resolution? Why it should do it? > > You've proposed the mechanism that is deeply related to ND (NS message), - it > should be activated from ND too. ND messages are shielded from host by > "Conceptual Model of a Host" (section 5 RFC 4861). It is not a good idea to > invoke NS directly from host TCP/IP stack (or any library). > Hence, You need to propose the change for "Conceptual Model of a Host" to > expose the new "address translation capability". I see here analogy to the NAT > hidden inside ND. Well, not for data plane, just for control plane. > > There is additional big problem: host would know at the time of 1st ND contact > (Conceptual Model) only Destination GUA returned in DNS and could know > Source GUA returned from SASA (does not make sense to ask SASA for this > information at this stage - no any value). > The information about GUA-LLA relationships is deep inside ND. Hence, > application should ask ND twice: 1st time for address translation, 2nd time for > the real packet dispatch. SASA make sense between 1st and 2nd ND contact > (when we would know LLA). > > Defining this "special NS" message you have chosen a very difficult path. > Because this message is at the end of decision chain (and even below it), but you > need the information at the beginning ("destanation"). Preferably, even before > routing table would be consulted. > A lot of changes everywhere to activate your "special NS". > Because, in essence: whole IP stack should be processed twice for the 1st packet > of every session. 1st pass is for network address translation. > > Is anything possible to do on DNS/Active directory? I am not expert on DNS. > Would DNS accept LLA? Could DNS check that particular host is from proper > subnet (this LLA is applicable for it)? > Your solution is local for company anyway. Tweaking just DNS server looks much > easy for me. > SASA would choose LLA scope automatically (with current algorithm). > > Eduard > > -----Original Message----- > > From: Mudric, Dusan [mailto:dmudric@ciena.com] > > Sent: 20 октября 2020 г. 18:00 > > To: Alexandre Petrescu <alexandre.petrescu@cea.fr>; ipv6@ietf.org; > > Vasilenko Eduard <vasilenko.eduard@huawei.com>; > > alexandre.petrescu@gmail.com; Mark Smith <markzzzsmith@gmail.com> > > Subject: Re: New Version Notification for draft-mudric-6man-lcs-01.txt > > > > Hi Eduard and Mark, > > > > We updated the draft. Hopefully we addressed your comment. Please review. > > > > Regards, > > Dusan. > > > > On 2020-10-20, 10:39 AM, "internet-drafts@ietf.org" <internet- > > drafts@ietf.org> wrote: > > > > > > A new version of I-D, draft-mudric-6man-lcs-01.txt has been > > successfully submitted by Dusan Mudric and posted to the IETF repository. > > > > Name: draft-mudric-6man-lcs > > Revision: 01 > > Title: Least-Common Scope Communications > > Document date: 2020-10-20 > > Group: Individual Submission > > Pages: 9 > > URL: > https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft- > > mudric-6man-lcs- > > > 01.txt__;!!OSsGDw!b5LZ_6HLnYwjZvgdUgd8OraszRauBz0RcSPvcBkTxYdp6n2p1p > > Xa2GTMkE8N$ > > Status: > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-mud > > ric- > > 6man- > > > lcs/__;!!OSsGDw!b5LZ_6HLnYwjZvgdUgd8OraszRauBz0RcSPvcBkTxYdp6n2p1pXa > > 2C7pHDI3$ > > Htmlized: > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draf > > t- > > mudric-6man- > > > lcs__;!!OSsGDw!b5LZ_6HLnYwjZvgdUgd8OraszRauBz0RcSPvcBkTxYdp6n2p1pXa > > 2C6yRTdb$ > > Htmlized: https://urldefense.com/v3/__https://tools.ietf.org/html/draft- > > mudric-6man-lcs- > > > 01__;!!OSsGDw!b5LZ_6HLnYwjZvgdUgd8OraszRauBz0RcSPvcBkTxYdp6n2p1pXa > > 2Mv7XAZ2$ > > Diff: > > https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-mu > > dric- > > 6man-lcs- > > > 01__;!!OSsGDw!b5LZ_6HLnYwjZvgdUgd8OraszRauBz0RcSPvcBkTxYdp6n2p1pXa > > 2MTLGOH_$ > > > > 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 > > > >
- Re: New Version Notification for draft-mudric-6ma… Mudric, Dusan
- RE: New Version Notification for draft-mudric-6ma… Vasilenko Eduard
- RE: New Version Notification for draft-mudric-6ma… Vasilenko Eduard
- Re: [**EXTERNAL**] RE: New Version Notification f… Mudric, Dusan
- RE: [**EXTERNAL**] RE: New Version Notification f… Vasilenko Eduard
- Re: [**EXTERNAL**] RE: New Version Notification f… Mudric, Dusan
- RE: [**EXTERNAL**] RE: New Version Notification f… Vasilenko Eduard
- Re: [**EXTERNAL**] RE: New Version Notification f… Mudric, Dusan
- RE: [**EXTERNAL**] RE: New Version Notification f… Vasilenko Eduard
- Re: [**EXTERNAL**] RE: New Version Notification f… Mudric, Dusan