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

[Alexandre Petrescu <[e-mail]>]

Hi, Eduard,

Le 24/08/2020 à 10:55, Vasilenko Eduard a écrit :
> Hi Dusan,

> [Dusan] The proposed mechanism is to use address resolution for GUA,
>  to obtain Destination LLA, when it is found that a destination GUA 
> is on link. It is exactly the problem: you have not proposed any 
> details how to do it.
> 
> Another problem for adoption could be on use case:
> 
> - if it is corporate environment, then Server is probably on a 
> separate segment from client, and both are protected by FW on the 
> perimeter

True, especially if Server might be a DHCPv6 server for multiple subnets.

In the design space, we might not want a central Server to perform that
resolution GUA-LLA for all Hosts in a domain.  We might want that
resolution to be targetting the Host that owns the addresses, a little
bit like NS/NA does.

However, we might want to consider the next-hop router instead of Server.

> - if it is home environment, then resource location is manual - LLA 
> could be chosen without any protocol extensions.

True, in some small home environments tables of mappings LLA-GUA could
be maintained manually, and protocol extensions might not be necessary.

> Do you have any evidences that the problem is really applicable to 
> real life?

We will provide some more details soon.

> PS: Vendor names are typically better to use "Vendor1" and
> "Vendor2", real vendors could have an objections that they are not
> capable to do something.

YEs yes, true enough.   Anonymizing names helps avoid pointing the finger.

Alex, and Dusan

> 
> Ed/ -----Original Message----- From: Mudric, Dusan 
> [mailto:[e-mail]] Sent: 21 августа 2020 г. 20:24 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-20, 1:57 PM, "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.
>> 
> [Dusan] rfc6724#section-5, SASA Rule 2
> 
> "   Rule 2: Prefer appropriate scope. If Scope(SA) < Scope(SB): If 
> Scope(SA) < Scope(D), then prefer SB and otherwise prefer SA. 
> Similarly, if Scope(SB) < Scope(SA): If Scope(SB) < Scope(D), then Hi
> prefer SA and otherwise prefer SB."
> 
> prefers the closest Scope(S) to the given destination Scope(D). If D 
> is GUA, a source will selects its S-GUA, rather than S-LLA.
> 
> Even if it might be possible to make S-LLA - to - D-GUA connection, 
> for security reasons it is preferred that both parties use LLAs for 
> ON-LINK communication.
> 
> But if I am a Cisco router computer software I can not force a 
> Juniper router computer software to do whatever.  If Juniper
> computer contacts me by using a GUA all I can do is to reply to it
> using my LLA.  I have no way to signal it to tell it 'please use an
> LLA instead'. This draft is proposing  such a new way.
> 
> So, this draft is saying "I have your GUA destination address  but I 
> would like to talk to you using our LLAs. If you agree to give me 
> your LLA, we will talk using our LLAs".
> 
>>> 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.
> 
> Yes, I think it is time to see what others think.
> 
>>> PS: I do not believe that it is possible to map Destination GUA 
>>> to Destination LLA.
>> 
> [Dusan] The proposed mechanism is to use address resolution for GUA, 
> to obtain Destination LLA, when it is found that a destination GUA is
> on link. LLA is a Link Local Address, not 'link-layer address' MAC 
> address. Address resolution NA message can be extended to provide 
> D-LLA. That is how a source will learn about destination LL address.
> 
> The existing address resolution mechanisms (NS/NA) would resolve a 
> link-layer address of a GUA that is used by the same interface on 
> which GUA is attached. The existing address resolution mechanism 
> (NS/NA) does not offer means to obtain the link-local address of an 
> interface of a GUA. This draft is proposing to change the current 
> mechanism to be able to negotiate LLAs.
> 
> Alex
> 
>> 
>>> 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!f7qBGY2iA8pCnxJAbIUGbxahnxInuh9WqA0
>> MxmIe6D_mOhy38kXzuv1SQv-G$
>> 
>> 
>> 
>> 
> Status:
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-mud
>>
>>
>>
>>
>> 
ric-6man-lcs/__;!!OSsGDw!f7qBGY2iA8pCnxJAbIUGbxahnxInuh9WqA0MxmIe6D_mO
>> hy38kXzuq3WYxzi$
>> 
>> 
>> 
>> 
> Htmlized:
>> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-mudric-6
>>
>>
>>
>>
>> 
man-lcs-00__;!!OSsGDw!f7qBGY2iA8pCnxJAbIUGbxahnxInuh9WqA0MxmIe6D_mOhy3
>> 8kXzuvX3ounT$
>> 
>> 
>> 
>> 
> Htmlized:
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draf
>>
>>
>>
>>
>> 
t-mudric-6man-lcs__;!!OSsGDw!f7qBGY2iA8pCnxJAbIUGbxahnxInuh9WqA0MxmIe6
>> D_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!fONP9f1G2DpYm4hiHyFwVVjqExwPBwSwmSlxAzxAgzOnTGru3lZoLcdvdY
>> KG$
>> 
>> 
>> 
>> 
>> --------------------------------------------------------------------
>>>
>>
>>
>