Subject: FW: [**EXTERNAL**] New Version Notification for draft-mudric-6man-lcs-00.txt

From: "Mudric, Dusan" <[email-masked]>
Date: Tue, 18 Aug 2020 13:56:15 +0000

Hi,

Please provide comments.

Thanks a lot,
Dusan.

On 2020-08-18, 9:31 AM, "[email-masked]" <[email-masked]> wrote:

    A new version of I-D, draft-mudric-6man-lcs-00.txt
    has been successfully submitted by Dusan Mudric and posted to the
    IETF repository.

    Name:		draft-mudric-6man-lcs
    Revision:	00
    Title:		Least-Common Scope Communications
    Document date:	2020-08-18
    Group:		Individual Submission
    Pages:		5
    URL:            https://urldefense.com/v3/__https://www.ietf.org/internet-drafts/draft-mudric-6man-lcs-00.txt__;!!OSsGDw!f7qBGY2iA8pCnxJAbIUGbxahnxInuh9WqA0MxmIe6D_mOhy38kXzuv1SQv-G$ 
    Status:         https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-mudric-6man-lcs/__;!!OSsGDw!f7qBGY2iA8pCnxJAbIUGbxahnxInuh9WqA0MxmIe6D_mOhy38kXzuq3WYxzi$ 
    Htmlized:       https://urldefense.com/v3/__https://tools.ietf.org/html/draft-mudric-6man-lcs-00__;!!OSsGDw!f7qBGY2iA8pCnxJAbIUGbxahnxInuh9WqA0MxmIe6D_mOhy38kXzuvX3ounT$ 
    Htmlized:       https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-mudric-6man-lcs__;!!OSsGDw!f7qBGY2iA8pCnxJAbIUGbxahnxInuh9WqA0MxmIe6D_mOhy38kXzuqfeyVD5$ 

    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, 18 Aug 2020 20:04:16 +0000

Hi Dusan, Hi Alexandere,
RFC 6724 does have big attention to choose addresses with smallest scope - section 3.1.
Then scope is at the second priority for section 5 "Source Address Selection".
I have not understood what else you need?
IMHO: it is better to clearly state what particular sentences in RFC 6724 you would like to change or amend.

I suspect that finally you would come to the problem how to find LLA for particular GUA? even for the case when proper GUA prefix is announced from local router with "L" bit set. Because GUA and LLA could have different interface ID.
GUA has been fetched from an Active Directory or DNS. Where to find LLA for the same host?!?
Is every host should register all their addresses on default router? to find correspondence.
What is the protocol to fetch this correspondence?
Nope. It would not fly... Not on this planet.

Correspondence between GUA and ULA is potentially possible to keep in Active Directory.
It looks like operational recommendation to corporate IT: use ULA and populate it into DNS and Active Directory with higher priority (if you need GUA at all for internal resources); use ULA and GUA for ordinary hosts.
I do not see why you need to change RFC 6724 for this - host should automatically choose ULA in this scenario.
The fact that ULA is more secure is not a big secret.

Eduard
-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Mudric, Dusan
Sent: 18 августа 2020 г. 16:56
To: [email-masked]
Cc: [email-masked]
Subject: FW: [**EXTERNAL**] New Version Notification for draft-mudric-6man-lcs-00.txt

Hi,

Please provide comments.

Thanks a lot,
Dusan.

    Abstract:

    The IETF Secretariat

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Mudric, Dusan" <[email-masked]>
Date: Thu, 20 Aug 2020 13:08:17 +0000

>      Hi Dusan, Hi Alexandere,

    [Alex] Thank you for the reply.  We carefully consider the comments.

    We identified a corner case of communicating on the same link.  In this 
    corner case the RFC6724 recommendation creates a security problem.

    Rather, we recommend to use the least possible scope that is 'common', 
    i.e. it allows to reach the other.  In other words, use a LL src even if 
    the dst is a GUA (GUA on the same link).

    (maybe the 'least common scope' is not the best.  Because by RFC 4291 
    "Addr Archi" the LL and GUA are not the same common scope, even though 
    one might imagine that link scope is included in a 'global' scope, and 
    thus the least common scope between LL and GUA is the LL scope; it is a 
    notion borrowed from set theory, an intersection; another difficulty 
    with 'least common scope' is that Global in GUA is not a 'scope' but a 
    characteristic of the uniqueness; and 'Global Unicast' is an address 
    'type', not a scope.  To make things worse, 'types' of addresses  could 
    be more than just LL ang GUA; other equally legitimate address types are 
    'unicast', 'multicast' and 'anycast', and also 'Unspecified', 
    'Loopback', 'Multicast'; and there are sub-types too.  So, maybe a more 
    precise recommendation would be to 'use an address type whose scope is 
    the least possible to reach a given destination', or 'least possibly 
    scoped address type', instead of 'least common scope'.)

    > RFC 6724 does have big attention to choose addresses with  smallest

    [Alex] That section 3.1 is about mapping multicast scopes to unicast 
    scope, in order to give reason to comparing the scopes of unicast. 
    However, a 1-to-1 mapping between these two scopes is hardly 
    understandable.  In particular, there still exists a site-local scope 
    for multicast but no longer for unicast.   And, there exist a unicast 
    ULA global scope that is not reachable (it's global in that it is 
    uniquely global, not because it is globally reachable - 'reachable' a 
    word not in dictionary anyways :-).   So it's hard to see its multicast 
    counterpart: either it's globally reachable or it's site-local (cant be 
    both).

    (In a multicast context it's not possible to use a multicast address in 
    the source of the packets; so in a multicast context one couldn't talk 
    about same-scope recommendations.  Moreover, there should not be 
    blockage to sending packets of ll scope to global mc scope.  _If_ we had 
    a src multicast possibility then yes, there could have been a good 
    recommendation of same-scope src-to-dst multicast-to-multicast packets. 
    But we are not concerned with that here.)

    Because of the impossibility of the mapping that I mention above, it's 
    impossible to come up with rules of same scope use in unicast context. 
    And thus the effort of mapping seems without success.

    > Then scope is at the second priority for section 5 "Source Address

    [Alex] Rule 2 might not lead to what we want.  The execution of that 
    rule using input parameters SA==GUA, SB==LL and D==GUA leads to select 
    SA (a GUA) as src; we dont want GUA in src when the destination is GUA 
    on the same link.

    [Dusan] It is rather DASA rule 8:
        Rule 8: Prefer smaller scope.
        If Scope(DA) < Scope(DB), then prefer DA.  Similarly, if Scope(DA) >
        Scope(DB), then prefer DB.

     I think the order of address selection should be:
     - DASA Rule 8 to select LL destination address, preferring the smaller scope, and
     - SASA Rule 6 will select SA-LL source address that has the same label as destination DA-LL address

    Section 10.2 example:
    "   Candidate Source Addresses: 2001:db8:1::2 or fe80::2
         Destination Address List: 2001:db8:1::1 or fe80::1
         Result: fe80::1 (src fe80::2) then 2001:db8:1::1 (src 2001:db8:1::2)
         (prefer smaller scope)"

     This means a host needs to autodiscover a destination LL address, before applying DASA Rule 8.
     The details of this mechanism will be provided.

    > I have not understood what else you need? IMHO: it is better to 
    > clearly state what particular sentences in RFC 6724 you would like
    > to change or amend.
    [Dusan] For ON-LINK D-GUA, SASA cannot be done until On-Link check and LL address 
    resolution are completed. A socket API in  RFC5014 would get a 
    destination GUA or ULA, and:
       - Need to do ON-LINK determination, and
       - Obtain LL address for ON-LINK destinations (LL address resolution).
    Otherwise:
       - Rule 8 can be updated to check if a destination (with its DA-GUA and DB-ULA 
    addresses) is ON-LINK, and obtain and use LL address for  ON-LINK 
    destinations.

    The second approach makes SASA dependent on asynchronous communication 
    with the ON-LINK destination and is not a preferred choice. If the first 
    approach is used, there is no need to update RFC 6724.

    > I suspect that finally you would come to the problem how to find LLA
    > for particular GUA?

    [Alex] Yes, probably that problem.  As a solution, it is not impossible 
    to find the LLA of a particular interface that is is present as a field 
    in an entry in a routing table whose first field covers the GUA 
    ('covers' - as identified by a longest-prefix match algorithm).

    > even for the case when proper GUA prefix is 
    > announced from local router with "L" bit set. Because GUA and LLA 
    > could have different interface ID.

    [Alex] Yes, could.

    > GUA has been fetched from an Active Directory or DNS.

    [Dusan] Or assigned by DHCPv6 (e.g. a destination host server address)

    >      Where to find LLA for the same host?!?

    [Dusan] No.

    >      What is the protocol to fetch this correspondence?

    [Dusan] Host already have defined on-link determination, RFC 4861. If 
    DA_GUA prefix:
    " - is covered by one of the link's prefixes (e.g.,
         as indicated by the on-link flag in the Prefix
         Information option)"
    "A node considers an address to be on-link".

    The same RFC4861 defines
    "     Address resolution: How nodes determine the link-layer address of
                     an on-link destination (e.g., a neighbor) given only the
                     destination's IP address."

    If the DA is ON-LINK, a host can resolve DA not only into the link-layer 
    address, but, with extensions, into DA_LL address.

    > Correspondence between GUA and ULA is potentially possible to keep
    > in Active Directory. It looks like operational recommendation to 
    > corporate IT: use ULA and populate it into DNS and Active Directory
    > with higher priority (if you need GUA at all for internal resources);
    > use ULA and GUA for ordinary hosts. >
    > I do not see why you need to change RFC 6724 for this - host should
    > automatically choose ULA in this scenario. The fact that ULA is more
    > secure is not a big secret. >
    >      Eduard

         >          URL: 
    https://urldefense.com/v3/__https://www.ietf.org/internet-drafts/draft-mudric-6man-lcs-00.txt__;!!OSsGDw!f7qBGY2iA8pCnxJAbIUGbxahnxInuh9WqA0MxmIe6D_mOhy38kXzuv1SQv-G$
         >          Status: 
    https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-mudric-6man-lcs/__;!!OSsGDw!f7qBGY2iA8pCnxJAbIUGbxahnxInuh9WqA0MxmIe6D_mOhy38kXzuq3WYxzi$
         >          Htmlized: 
    https://urldefense.com/v3/__https://tools.ietf.org/html/draft-mudric-6man-lcs-00__;!!OSsGDw!f7qBGY2iA8pCnxJAbIUGbxahnxInuh9WqA0MxmIe6D_mOhy38kXzuvX3ounT$
         >          Htmlized: 
    https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-mudric-6man-lcs__;!!OSsGDw!f7qBGY2iA8pCnxJAbIUGbxahnxInuh9WqA0MxmIe6D_mOhy38kXzuqfeyVD5$
         >      Administrative Requests: 
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!OSsGDw!fONP9f1G2DpYm4hiHyFwVVjqExwPBwSwmSlxAzxAgzOnTGru3lZoLcdvdYKG$

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 20 Aug 2020 17:57:28 +0000

It is possible to look into "Prefix List" (RFC 4861 terminology),
If particular PIO was with "L"="Local" bit set,
Then it is possible to use GUA as destination, but LLA as source.
Should work.

It is radical departure from 6724:
" to prefer destination/source address pairs for  which the two addresses are of equal scope or type ..."

I am not sure that any other RFC would not block this approach. I do not see any blocking factor.
Let's others speak.

PS: I do not believe that it is possible to map Destination GUA to Destination LLA.

Eduard
-----Original Message-----
From: Mudric, Dusan [mailto:[email-masked]] 
Sent: 20 августа 2020 г. 16:08
To: Alexandre Petrescu <[email-masked]>; Vasilenko Eduard <[email-masked]>; [email-masked]
Cc: Dusan Mudric <[email-masked]>
Subject: Re: [**EXTERNAL**] New Version Notification for draft-mudric-6man-lcs-00.txt

    Section 10.2 example:

    [Alex] Yes, could.

    [Dusan] No.

    The same RFC4861 defines

---

From: Mark Smith <[email-masked]>
Date: Fri, 21 Aug 2020 09:02:08 +1000

> PS: I do not believe that it is possible to map Destination GUA to Destination LLA.

That's correct, and there isn't intended to be.

Both RFC7217 stable addresses and RFC4291bis temporary addresses have
different IIDs for the different prefixes a node might have addresses
from, specifically so an IID from one prefix can't be correlated to
the same IID in a different prefix.

I've had a brief look at this draft, it doesn't seem to be saying
anything about how switching from GUAs to on-link locals is to be
achieved, it seems to just be saying it should.

Multicast DNS would be the current way for on-link peers to announce
that they're reachable via the Link-Local Address, in addition to
their GUA and ULA addresses i.e. an mDNS announcement containing all
of the node's interfaces addresses of all types. RFC6724 would then
take care of picking the LLA DA over GUA and ULA, and then would take
care of picking the LLA as a SA to reach the chosen LLA DA.

Regards,
Mark.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 24 Aug 2020 17:58:22 +0200

Hi, Mark,

Please allow us some comments in this interaction.

Le 21/08/2020 à 01:02, Mark Smith a écrit :
>> If particular PIO was with "L"="Local" bit set, Then it is
>> possible to use GUA as destination, but LLA as source. Should
>> work.
>> 
>> It is radical departure from 6724: " to prefer destination/source 
>> address pairs for  which the two addresses are of equal scope or 
>> type ..."
>> 
>> I am not sure that any other RFC would not block this approach. I 
>> do not see any blocking factor. Let's others speak.
>> 

I am not sure we look for a switch mechanism during an ongoing session.
  Rather, sometimes I'd like a decision of using the LLA initially, so
the GUA socket does not open at all.

If such a switching mechanism appears necessary, then also a tool
similar to Mobile IP might be a starting point.

But, we are just now socializing the idea of this necessity of LLA
instead of GUA for security reasons.  If it becomes apparent that a
switch might be necessary, then an NS/NA extension might also be
appropriate.  In the next days we could add a description of such a
mechanism.

>  of the node's interfaces addresses of all types.

Yes, this mDNS might be appropriate as well.

If LLA is advertised to DNS server, along with GUA, a name to address
resolution would get D-GUA and D-LLA.  If D-GUA is ON-LINK, use D-LLA.
That would be a key decision.

An assumption is that if D-LLA is advertised to DNS server, the host
prefers talking over LLAs.

This DNS approach does not require NS/NA changes. But DNS approach
cannot address all use cases. That is why the original proposal (NS/NA)
is important.

If appropriate, we are open to further such significant contributions in
the document.

> RFC6724 would then take care of picking the LLA DA over GUA and ULA,
>  and then would take care of picking the LLA as a SA to reach the 
> chosen LLA DA.

This I am not sure.  I am not sure which rule in RFC6724 you think that
will take care of picking the LLA DA instead of the GUA DA.  I do agree
that if the DA is an LLA then that RFC might select the right src as an LLA.

Alex

> 
> Regards, Mark.
> 
> 
>> Eduard -----Original Message----- From: Mudric, Dusan 
>> [mailto:[email-masked]] Sent: 20 августа 2020 г. 16:08 To: 
>> Alexandre Petrescu <[email-masked]>; Vasilenko
>> Eduard <[email-masked]>; [email-masked] Cc: Dusan
>> Mudric <[email-masked]> Subject: Re: [**EXTERNAL**] New
>> Version Notification for draft-mudric-6man-lcs-00.txt
>> 
>> 
>> On 2020-08-18, 4:04 PM, "Vasilenko Eduard" 
>> We identified a corner case of communicating on the same link.  In 
>> this corner case the RFC6724 recommendation creates a security 
>> problem.
>> 
>> Rather, we recommend to use the least possible scope that is 
>> 'common', i.e. it allows to reach the other.  In other words, use
>> a LL src even if the dst is a GUA (GUA on the same link).
>> 
>> (maybe the 'least common scope' is not the best.  Because by RFC 
>> 4291 "Addr Archi" the LL and GUA are not the same common scope, 
>> even though one might imagine that link scope is included in a 
>> 'global' scope, and thus the least common scope between LL and GUA 
>> is the LL scope; it is a notion borrowed from set theory, an 
>> intersection; another difficulty with 'least common scope' is that 
>> Global in GUA is not a 'scope' but a characteristic of the 
>> uniqueness; and 'Global Unicast' is an address 'type', not a
>> scope. To make things worse, 'types' of addresses  could be more
>> than just LL ang GUA; other equally legitimate address types are
>> 'Loopback', 'Multicast'; and there are sub-types too.  So, maybe a
>> more precise recommendation would be to 'use an address type whose
>> scope is the least possible to reach a given destination', or
>> 'least possibly scoped address type', instead of 'least common
>> scope'.)
>> 
>> [Alex] That section 3.1 is about mapping multicast scopes to 
>> unicast scope, in order to give reason to comparing the scopes of 
>> unicast. However, a 1-to-1 mapping between these two scopes is 
>> hardly understandable.  In particular, there still exists a 
>> site-local scope for multicast but no longer for unicast.   And, 
>> there exist a unicast ULA global scope that is not reachable (it's 
>> global in that it is uniquely global, not because it is globally 
>> reachable - 'reachable' a word not in dictionary anyways :-).   So 
>> it's hard to see its multicast counterpart: either it's globally 
>> reachable or it's site-local (cant be both).
>> 
>> (In a multicast context it's not possible to use a multicast 
>> address in the source of the packets; so in a multicast context
>> one couldn't talk about same-scope recommendations.  Moreover,
>> there should not be blockage to sending packets of ll scope to
>> global mc scope.  _If_ we had a src multicast possibility then yes,
>> there could have been a good recommendation of same-scope
>> src-to-dst multicast-to-multicast packets. But we are not concerned
>> with that here.)
>> 
>> Because of the impossibility of the mapping that I mention above, 
>> it's impossible to come up with rules of same scope use in unicast 
>> context. And thus the effort of mapping seems without success.
>> 
>> [Alex] Rule 2 might not lead to what we want.  The execution of 
>> that rule using input parameters SA==GUA, SB==LL and D==GUA leads 
>> to select SA (a GUA) as src; we dont want GUA in src when the 
>> destination is GUA on the same link.
>> 
>> [Dusan] It is rather DASA rule 8: Rule 8: Prefer smaller scope. If 
>> Scope(DA) < Scope(DB), then prefer DA.  Similarly, if Scope(DA) > 
>> I think the order of address selection should be: - DASA Rule 8 to 
>> select LL destination address, preferring the smaller scope, and - 
>> SASA Rule 6 will select SA-LL source address that has the same 
>> label as destination DA-LL address
>> 
>> Section 10.2 example: "   Candidate Source Addresses:
>> 2001:db8:1::2 or fe80::2 Destination Address List: 2001:db8:1::1 or
>> fe80::1 Result: fe80::1 (src fe80::2) then 2001:db8:1::1 (src 
>> 2001:db8:1::2) (prefer smaller scope)"
>> 
>> This means a host needs to autodiscover a destination LL address, 
>> before applying DASA Rule 8. The details of this mechanism will be 
>> provided.
>> 
>>> clearly state what particular sentences in RFC 6724 you would 
>>> like to change or amend.
>> [Dusan] For ON-LINK D-GUA, SASA cannot be done until On-Link check 
>> and LL address resolution are completed. A socket API in  RFC5014 
>> would get a destination GUA or ULA, and: - Need to do ON-LINK 
>> determination, and - Obtain LL address for ON-LINK destinations
>> (LL address resolution). Otherwise: - Rule 8 can be updated to
>> check if a destination (with its DA-GUA and DB-ULA addresses) is
>> ON-LINK, and obtain and use LL address for  ON-LINK destinations.
>> 
>> The second approach makes SASA dependent on asynchronous 
>> communication with the ON-LINK destination and is not a preferred 
>> choice. If the first approach is used, there is no need to update 
>> RFC 6724.
>> 
>>> I suspect that finally you would come to the problem how to find 
>>> LLA for particular GUA?
>> 
>> [Alex] Yes, probably that problem.  As a solution, it is not 
>> impossible to find the LLA of a particular interface that is is 
>> present as a field in an entry in a routing table whose first
>> field covers the GUA ('covers' - as identified by a longest-prefix
>> match algorithm).
>> 
>>> even for the case when proper GUA prefix is announced from local 
>>> router with "L" bit set. Because GUA and LLA could have different
>>> interface ID.
>> 
>> [Alex] Yes, could.
>> 
>>> Where to find LLA for the same host?!? Is every host should 
>>> register all their addresses on default router? to find 
>>> correspondence.
>> 
>> [Dusan] No.
>> 
>> [Dusan] Host already have defined on-link determination, RFC 4861. 
>> If DA_GUA prefix: " - is covered by one of the link's prefixes 
>> (e.g., as indicated by the on-link flag in the Prefix Information 
>> option)" "A node considers an address to be on-link".
>> 
>> The same RFC4861 defines "     Address resolution: How nodes 
>> determine the link-layer address of an on-link destination (e.g.,
>> a neighbor) given only the destination's IP address."
>> 
>> If the DA is ON-LINK, a host can resolve DA not only into the 
>> link-layer address, but, with extensions, into DA_LL address.
>> 
>>> Correspondence between GUA and ULA is potentially possible to 
>>> keep in Active Directory. It looks like operational 
>>> recommendation to corporate IT: use ULA and populate it into DNS 
>>> and Active Directory with higher priority (if you need GUA at all
>>> for internal resources); use ULA and GUA for ordinary hosts.
>>>> I do not see why you need to change RFC 6724 for this - host
>>> should automatically choose ULA in this scenario. The fact that 
>>> ULA is more secure is not a big secret. > Eduard
>> 
>> 
>>> -----Original Message----- From: ipv6 
>>> [mailto:[email-masked]] On Behalf Of
>> Mudric, Dusan
>>> Sent: 18 августа 2020 г. 16:56 To: [email-masked] Cc: 
>>> [email-masked] Subject: FW: [**EXTERNAL**] New 
>>> Version Notification for
>> draft-mudric-6man-lcs-00.txt
>>> 
>>> Hi,
>>> 
>>> Please provide comments.
>>> 
>>> Thanks a lot, Dusan.
>>> 
>>> A new version of I-D, draft-mudric-6man-lcs-00.txt has been 
>>> successfully submitted by Dusan Mudric and
>> posted to the
>>> IETF repository.
>>> 
>>> Name:               draft-mudric-6man-lcs Revision:   00 Title: 
>>> Least-Common Scope Communications Document date:      2020-08-18
>>>  Group:              Individual Submission Pages:              5
>>>  URL:
>>> Abstract: This draft formulates a security problem statement.
>> The problem
>>> [email-masked] Administrative Requests:
>> [email-masked] Administrative Requests: 
>> https://www.ietf.org/mailman/listinfo/ipv6