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

[Vasilenko Eduard <[e-mail]>]

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
- if it is home environment, then resource location is manual - LLA could be chosen without any protocol extensions.
Do you have any evidences that the problem is really applicable to real life?

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.

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