RE: [**EXTERNAL**] RE: New Version Notification for draft-mudric-6man-lcs-01.txt

[Vasilenko Eduard <[e-mail]>]

Hi Dusan,
It does not work the way you numbering events.
It could not start from NCE population, because ND needs traffic to become interested in new NCE.

Does your points 4-7 mean that on-link communication would be prohibited on GUA in principle,
Because all GUA requests would be automatically translated to LLA?
If not, how ND should know what should be translated into LLA and what should not?

Does it mean that traffic would be black-holed if server would not attach application to LLA?
How client would understand that server is listening on LLA for particular application?

Eduard
> -----Original Message-----
> From: Mudric, Dusan [mailto:[e-mail]]
> Sent: 22 октября 2020 г. 18:39
> To: Vasilenko Eduard <[e-mail]>; Alexandre Petrescu
> <[e-mail]>; [e-mail]; [e-mail];
> Mark Smith <[e-mail]>
> Subject: Re: [**EXTERNAL**] RE: New Version Notification for draft-mudric-
> 6man-lcs-01.txt
> 
> Hi Eduard,
> 
> Thanks a lot for helping with the solution and providing insightful analysis.
> Please check proposed details for address resolution algorithm below.
> 
> Please see inliend comments.
> 
> Regards,
> Dusan
> 
> >On 2020-10-20, 12:44 PM, "Vasilenko Eduard"
> <[e-mail]> wrote:
> >
> >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)
> 
> [Dusan] RFC 6724 section 7 should be updated based on RFC 8028 section 3.3.
> " Rule 5.5 of RFC 6724 states that the source address used to send to a
>    given destination address should, if possible, be chosen from a
>    prefix known to be advertised by the next-hop router for that
>    destination."
> 
> When the source address is selected, the host can use the address prefix to find
> which router advertised that prefix. Host then knows over which link the prefix
> advertisement was received. This means SASA Rule 5.5 is indirectly selecting the
> first hop router and the link connecting to that router.
> 
> With this in mind:
> 1st: Host should choose destination address, if multiple GUA and ULA are
> provided
> 2nd: Host should choose source address
> 3rd: Host should choose next hop, and outgoing interface, based on the source
> address prefix
> 4th: If a destination is on-link, the host should resolve destination GUA into
> destination LL
> 
> If a socket API is used to obtain SASA address, for a given GUA destination, LL
> address resolution might be used. A result might be LL destination address on
> the local link. Media applications can use that address for the further
> communication.
> 
> >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)
> [Dusan] Agree. That is the approach above. A next hop router preference is
> mapped to the prefix preference, which is mapped to the selected source
> address. One the source address is selected, the host knows which next hop
> router to use, based on the source router prefix. Another approach is to use a
> destination host GUA to select the source address and, based on the source
> address prefix, the first hop router and the outgoing interface. For LL address
> resolution, the outgoing interface selection is important, since the host needs to
> know on which link to send packets to on-link destinations.
> 
> >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".
> [Dusan] For efficiency reason, after LL address resolution, the sender should
> create a neighbor cache entry for LL destination.
> 1st: Sender creates a neighbor cache entry for GUA.
> 2nd: Sender sends NS with L bit set
> 3rd: Sender receives NA with link-layer and LL addresses
> 4th: Sender updates GUA cache entry with the link-layer address
> 5th: Sender creates a neighbor cache entry for destination LL address and sets
> the destination link-layer address of the destination host
> 6th: Sender closes the socket listening on GUA and opens a socket listening on
> LL
> 7th: Sender transmits a packet to link-layer address of the destination host,
> using destination host LL address as IPv6 packet destination address
> 8th: Application sending to GUA should obtain the SASA address (which is now LL
> address) for the further negotiations (e.g. SIP needs to negotiate media
> addresses). This also implies an application should be given an option to request
> LL vs. GUA communication, when opening a socket to GUA destination. Socket
> API should have this option and use it to initiate LL address resolution.
> 
> This process does not directly impact existing SASA address selection. It is an
> addition to further obtain (and select) LL address for SASA selected GUA.
> 
> >Where in this chain of events host should ask your "special NS" for GUA to LLA
> resolution? Why it should do it?
> [Dusan] It is not "special NS". It is well defined MAC address resolution that can
> also return LL address. LL address is needed to communicate on the local link
> without opening a socket port for GUA.
> 
> >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.
> [Dusan] Agree. What do you think about steps 1-4 and then 1-8 above?
> 
> >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).
> [Dusan] I think it does. See steps 1-4 above and other notes explaining how SASA
> is used to find the outgoing interface on which on-link destination is.
> 
> >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.
> [Dusan] I think it should work. Steps 1-4 find the outgoing interface. The order
> of standard address resolution is not changed. Step 5-7 are added to use
> destination LL.
> 
> >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.
> [Dusan] The sequence in IP stack does not change. Only steps 5-7 are added.
> 
> >Is anything possible to do on DNS/Active directory? I am not expert on DNS.
> [Dusan] It will be tricky.
> 1st: DNS has to learn LL addresses from hosts.
> 2nd: These LL addresses need to be mapped to GUA on the link.
> 3rd: When FQDN resolution is done, GUA with the link LL should be returned
> 
> >Would DNS accept LLA? Could DNS check that particular host is from proper
> subnet (this LLA is applicable for it)?
> [Dusan] LLs can be added to DNS but they would need to be learned as a pair
> {GUA, LL}, once GUA is created. Some hosts use only SLAAC addresses, which
> means they would need to register {SLAAC GUA, LL} for each address prefix.
> 
> >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:[e-mail]]
> > Sent: 20 октября 2020 г. 18:00
> > To: Alexandre Petrescu <[e-mail]>; [e-mail];
> > Vasilenko Eduard <[e-mail]>;
> > [e-mail]; Mark Smith <[e-mail]>
> > 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, "[e-mail]" <internet-
> > [e-mail]> 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
> >
> >
>