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

["Mudric, Dusan" <[e-mail]>]

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-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:
>    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
> 
>