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

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

    On 2020-08-18, 4:04 PM, "Vasilenko Eduard" <[e-mail]> 
    wrote:
    >
    >      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
    > scope - section 3.1.

    [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
    > Selection".

    [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?!?
    >      Is every host should register all their addresses on default 
     >      router? to find correspondence.

    [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.

    > 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:[e-mail]] On Behalf Of 
    Mudric, Dusan
         >      Sent: 18 августа 2020 г. 16:56
         >      To: [e-mail]
         >      Cc: [e-mail]
         >      Subject: FW: [**EXTERNAL**] New Version Notification for 
    draft-mudric-6man-lcs-00.txt
         >
         >      Hi,
         >
         >      Please provide comments.
         >
         >      Thanks a lot,
         >      Dusan.
         >
         >      On 2020-08-18, 9:31 AM, "[e-mail]" 
    <[e-mail]> 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
         >
         >
         >
         > --------------------------------------------------------------------
         >      IETF IPv6 working group mailing list
         >      [e-mail]
         >      Administrative Requests: 
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!OSsGDw!fONP9f1G2DpYm4hiHyFwVVjqExwPBwSwmSlxAzxAgzOnTGru3lZoLcdvdYKG$
         > --------------------------------------------------------------------
         >