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

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

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