Subject: Re: New Version Notification for draft-mudric-6man-lcs-01.txt

From: "Mudric, Dusan" <[email-masked]>
Date: Tue, 20 Oct 2020 14:59:42 +0000

Hi Eduard and Mark,

We updated the draft. Hopefully we addressed your comment. Please review.

Regards,
Dusan.

On 2020-10-20, 10:39 AM, "[email-masked]" <[email-masked]> 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_6HLnYwjZvgdUgd8OraszRauBz0RcSPvcBkTxYdp6n2p1pXa2GTMkE8N$ 
Status:         https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-mudric-6man-lcs/__;!!OSsGDw!b5LZ_6HLnYwjZvgdUgd8OraszRauBz0RcSPvcBkTxYdp6n2p1pXa2C7pHDI3$ 
Htmlized:       https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-mudric-6man-lcs__;!!OSsGDw!b5LZ_6HLnYwjZvgdUgd8OraszRauBz0RcSPvcBkTxYdp6n2p1pXa2C6yRTdb$ 
Htmlized:       https://urldefense.com/v3/__https://tools.ietf.org/html/draft-mudric-6man-lcs-01__;!!OSsGDw!b5LZ_6HLnYwjZvgdUgd8OraszRauBz0RcSPvcBkTxYdp6n2p1pXa2Mv7XAZ2$ 
Diff:           https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-mudric-6man-lcs-01__;!!OSsGDw!b5LZ_6HLnYwjZvgdUgd8OraszRauBz0RcSPvcBkTxYdp6n2p1pXa2MTLGOH_$ 

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

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 20 Oct 2020 16:44:25 +0000

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:[email-masked]]
> Sent: 20 октября 2020 г. 18:00
> To: Alexandre Petrescu <[email-masked]>; [email-masked]; Vasilenko
> Eduard <[email-masked]>; [email-masked];
> Mark Smith <[email-masked]>
> Subject: Re: New Version Notification for draft-mudric-6man-lcs-01.txt
> 
> Hi Eduard and Mark,
> 
> 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.
> 
> 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-mudric-
> 6man-
> lcs/__;!!OSsGDw!b5LZ_6HLnYwjZvgdUgd8OraszRauBz0RcSPvcBkTxYdp6n2p1pXa
> 2C7pHDI3$
> Htmlized:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-
> 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-mudric-
> 6man-lcs-
> 01__;!!OSsGDw!b5LZ_6HLnYwjZvgdUgd8OraszRauBz0RcSPvcBkTxYdp6n2p1pXa
> 2MTLGOH_$
> 
> Abstract:

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 20 Oct 2020 17:49:46 +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
> From: Vasilenko Eduard
> Sent: 20 октября 2020 г. 19:46
> To: 'Mudric, Dusan' <[email-masked]>; Alexandre Petrescu
> <[email-masked]>; [email-masked]; [email-masked];
> Subject: RE: New Version Notification for draft-mudric-6man-lcs-01.txt
> 
> Hi Dusan,
> Read carefully the beginning of section 7 RFC 6724. Sequence of mechanisms is
> counter-intuitive (historical). It looks like you assume the reverse order.
> 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".
> 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.
> Because, in essence: whole IP stack should be processed twice for the 1st packet
> of every session. 1st pass is for network address translation.
> 
> > To: Alexandre Petrescu <[email-masked]>; [email-masked];
> > Vasilenko Eduard <[email-masked]>;
> > [email-masked]; Mark Smith <[email-masked]>
> > 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.
> >
> > URL:
> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-
> > mudric-6man-lcs-
> >
> > 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
> >
> >