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

[Alexandre Petrescu <[e-mail]>]

Hi, Mark,

Please allow us some comments in this interaction.

Le 21/08/2020 à 01:02, Mark Smith a écrit :
> 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.

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.

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

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