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

[Mark Smith <[e-mail]>]

On Fri, 21 Aug 2020 at 03:58, Vasilenko Eduard
<[e-mail]> wrote:
>
> 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.
>

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.


> Eduard
> -----Original Message-----
> From: Mudric, Dusan [mailto:[e-mail]]
> Sent: 20 августа 2020 г. 16:08
> To: Alexandre Petrescu <[e-mail]>; Vasilenko Eduard <[e-mail]>; [e-mail]
> Cc: Dusan Mudric <[e-mail]>
> Subject: Re: [**EXTERNAL**] New Version Notification for draft-mudric-6man-lcs-00.txt
>
>
>     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$
>          > --------------------------------------------------------------------
>          >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------