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>om>; Alexandre Petrescu
> <alexandre.petrescu@cea.fr>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>fr>; ipv6@ietf.org;
> > Vasilenko Eduard <vasilenko.eduard@huawei.com>om>;
> > 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
> >
> >