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

From: "Mudric, Dusan" <[email-masked]>
Date: Thu, 22 Oct 2020 15:38:30 +0000

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" <[email-masked]> 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:[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,
> 
> We updated the draft. Hopefully we addressed your comment. Please review.
> 
> Regards,
> Dusan.
> 
> On 2020-10-20, 10:39 AM, "[email-masked]" <internet-
> [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_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
> 
>

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 22 Oct 2020 19:01:59 +0000

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
> Sent: 22 октября 2020 г. 18:39
> To: Vasilenko Eduard <[email-masked]>; Alexandre Petrescu
> <[email-masked]>; [email-masked]; [email-masked];
> 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.
> 
> >Let’s imagine that you have the capability to ask server GUA about server LLA.
> It is not the solution by itself. Not yet.
> >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)
> 
> 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:
> 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.
> 5th: Sender creates a neighbor cache entry for destination LL address and sets
> the destination link-layer address of the destination host
> 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.
> 
> [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.
> >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.
> 
> >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] 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.
> 
> > 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
> >
> >
>

---

From: "Mudric, Dusan" <[email-masked]>
Date: Fri, 23 Oct 2020 18:33:06 +0000

Hi Eduard,

An application can choose to use LL for on-link communication. That request can be passed via a socket API to ND.
ND would set NS 'L' bit to indicate the LL address resolution is required and use of LL for the on-link communication,
if a destination host returns it.

The process starts with an application requesting a socket to send to GUA destination. 
First step is a destination address selection and the sequence goes to the LL address resolution, step 4:

1st: Host should choose destination address, if multiple GUA and ULA are provided
2nd: Host should choose source address, for the selected destination 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 may want to resolve destination GUA into destination LL

Step 4 is further broken down into:
4.1st: Sender creates a neighbor cache entry for GUA.
4.2nd: Sender sends NS, with L bit set, to GUA.
4.3rd: Sender receives NA with link-layer and LL addresses
4.4th: Sender updates GUA cache entry with the link-layer address
4.5th: Sender creates a neighbor cache entry for destination LL address and sets
           the destination link-layer address of the destination host
4.6th: Sender closes the socket listening on GUA and opens a socket listening on LL
4.7th: Sender transmits a packet to link-layer address of the destination host,
           using destination host LL address as IPv6 packet destination address
4.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.

Good point about the server side. There might be a mix of clients on the local link, some that want to use LL and some that don't.
For that reason server APPs would need to listen on both GUA and LL, using APP port numbers. That can be achieved by opening
a listening socket on ANY address. It is very unlikely that the server will talk only to clients on the local link. In case it does 
happen, the server applications can listen on {LL, port}.

If a server is listening on GUA only for a particular application, and this algorithm is supported, a client might request LL 
conversation. However, the server application would be unreachable. What can be a solution for this? May be if a socket
API does not request LL connection, server ND should not return LL address (step 4.3).

Thanks,
Dusan.

>On 2020-10-22, 3:02 PM, "Vasilenko Eduard" <[email-masked]> wrote:
>
>Hi Dusan,

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 26 Oct 2020 08:00:30 +0000

Hi Dusan,
OK. It looks like the solution now.
IMHO: you would better update draft to insert the logic from your last message. It is the critical piece of information to understand what you propose.

You need 2 new API functions to call between applications and ND:
1. to say on the client "use LLA for this GUA, if possible", then client would send NS with flag L.
2. to say on the server " if NS has flag L in request for this GUA then respond with LLA too"

The second API call would give the way for smooth transition: when ND stack already support this extension, but application does not support it yet.

It is evident that you would have the black hole
if one application on the server would be attached to all addresses,
But other application would be attached only to GUA.
Because the 1st application would ask for GUA->LLA substitution.
Hence, should be the possibility to disable this ND functionality on Server.

You are asking too much: to change all hosts and to change all application to get full value.
Albeit, it would work as soon as 3 particular instances would become upgraded:
1. ND on particular client
2. ND on particular server
3. at least 1 application on this server
If Enterprise admin do care about security - he could easily make such progress.

I have the temptation to ask you: why client is in the same subnet with the server? They are typically in different subnet.
Do you have any best guess for how many servers (%) have clients on the same link?

Eduard
> Sent: 23 октября 2020 г. 21:33
> ND would set NS 'L' bit to indicate the LL address resolution is required and use
> of LL for the on-link communication, if a destination host returns it.
> 
> addresses).
> Good point about the server side. There might be a mix of clients on the local
> link, some that want to use LL and some that don't.
> For that reason server APPs would need to listen on both GUA and LL, using APP
> port numbers. That can be achieved by opening a listening socket on ANY
> address. It is very unlikely that the server will talk only to clients on the local link.
> In case it does happen, the server applications can listen on {LL, port}.
> 
> If a server is listening on GUA only for a particular application, and this algorithm
> is supported, a client might request LL conversation. However, the server
> application would be unreachable. What can be a solution for this? May be if a
> socket API does not request LL connection, server ND should not return LL
> address (step 4.3).
> 
> Thanks,
> Dusan.
> 
> >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?

---

From: "Mudric, Dusan" <[email-masked]>
Date: Mon, 26 Oct 2020 16:51:05 +0000

Hi Eduard,

I agree with your proposed steps 1 & 2 for the application API. The first one is mentioned in the step 4.8. 

We will make draft updates to make the whole process clear. Other comments are inlined.

Thanks for good questions and suggestions,
Dusan.

>The second API call would give the way for smooth transition: when ND stack already support this extension, but application does not support it yet.
[Dusan] Agree about the need of the second API for the smooth transition. 
              I think the ND stack should disable the return of LL till application/socket API is ready to support LL sockets or all sockets are using ANY address.

>Hence, should be the possibility to disable this ND functionality on Server.
[Dusan] The solution can be to disable LL resolution on the server side till all sockets request the LL usage, or they bind to ANY address. 
               As long as there is one socket bound only to GUA, LL address resolution should be disabled. 
               Otherwise there will be a connectivity issue with that socket.

>You are asking too much: to change all hosts and to change all application to get full value.
[Dusan] I expect not too much. It is rather very common for applications to bind to ANY address.

>If Enterprise admin do care about security - he could easily make such progress.
[Dusan] If clients open sockets on ANY address, only ND upgrade is required on the client and server sides.

>I have the temptation to ask you: why client is in the same subnet with the server? They are typically in different subnet.
[Dusan] In IP telephony, for example, there is a server on SiteA and number of phones on that site. But server is used by
              other phones on SiteB as well. Server is not isolated on one site, without phones on the same site.

Do you have any best guess for how many servers (%) have clients on the same link?
[Dusan] In IP telephony 100%. There is no site without phones.

Eduard

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 26 Oct 2020 17:42:34 +0000

Hi Dusan,

When I said "too long and difficult" (mission is close to impossible)
I mean: to get all applications recompiled (for new API support) and all hosts updated with your draft for ND.
i.e. I mean: binary code change.
I do not see any problem too with binding application to many IP addresses.

I have seen some number of IP telephony designs. Well, it was many years ago. Call Manager was on the separate subnet from IP phones. Call Manager was somewhere on the "server farm".
Hence, my question is still valid: how many servers are in separate server subnets (%) and how many servers are in the same subnet with clients (%)?

Ed/
> Sent: 26 октября 2020 г. 19:51
> Thanks for good questions and suggestions, Dusan.
> 
> >IMHO: you would better update draft to insert the logic from your last
> message. It is the critical piece of information to understand what you propose.
> 
> >The second API call would give the way for smooth transition: when ND stack
> already support this extension, but application does not support it yet.
>               I think the ND stack should disable the return of LL till application/socket
> API is ready to support LL sockets or all sockets are using ANY address.
> 
> >It is evident that you would have the black hole if one application on
> >the server would be attached to all addresses, But other application
> >would be attached only to GUA.
> [Dusan] The solution can be to disable LL resolution on the server side till all
> sockets request the LL usage, or they bind to ANY address.
> >3. at least 1 application on this server If Enterprise admin do care
> >about security - he could easily make such progress.
> >I have the temptation to ask you: why client is in the same subnet with the
> server? They are typically in different subnet.
> [Dusan] In IP telephony, for example, there is a server on SiteA and number of
> phones on that site. But server is used by

---

From: "Mudric, Dusan" <[email-masked]>
Date: Tue, 27 Oct 2020 17:17:17 +0000

Hi Eduard,

There is no SIP protocol restriction to keep clients on a different subnet. I suppose it is up to a network operator to decide on a topology. What is more important is that clients on the same subnet and local link can negotiate media over a server on a different subnet, using GUA, and media on the local link can use LL addresses.

Regards,
Dusan.

Ed/