Re: I-D Action: draft-ietf-6man-rfc6874bis-01.txt

[Brian E Carpenter <[e-mail]>]

On 01-Jul-22 03:18, Ted Lemon wrote:
> At least according to Stack Overflow, no such API exists in web browsers. It used to be possible to use WebRTC for this, but apparently that has been fixed.

Exactly. The script I wrote uses a very basic feature of Javascript, which is the ability to launch an HTTP operation towards an arbitrary URL.

    Brian


> 
> On Thu, Jun 30, 2022 at 6:33 AM Vasilenko Eduard <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     We are talking about malicious script in the browser on the victim client.____
> 
>     It could ask the OS about available GUA addresses.____
> 
>     No need to guess.____
> 
>     Ed/____
> 
>     *From:*ipv6 [mailto:[e-mail] <mailto:[e-mail]>] *On Behalf Of *Ted Lemon
>     *Sent:* Thursday, June 30, 2022 3:45 PM
>     *To:* Vasilenko Eduard <vasilenko.eduard=[e-mail] <mailto:[e-mail]>>
>     *Cc:* 6man WG <[e-mail] <mailto:[e-mail]>>
>     *Subject:* Re: I-D Action: draft-ietf-6man-rfc6874bis-01.txt____
> 
>     __ __
> 
>     With GUA/ULA you have to guess the prefix. LLAs all share the same prefix. So you have a lot fewer bits to guess with a LLA. Of course, you might be able to get the GUA prefix by connecting to some service, but this won’t work for ULA. ____
> 
>     __ __
> 
>     On Thu, Jun 30, 2022 at 03:37 Vasilenko Eduard <vasilenko.eduard=[e-mail] <mailto:[e-mail]>> wrote:____
> 
>         I do not see the difference from the scan of the local GUA/ULA subnet (it does not need a zone too).____
> 
>         Why improve security only for LLA, leaving GUA/ULA with the same level of security?____
> 
>         IMHO: it does not make sense. The attacker would scan GUA/ULA if LLA is more difficult. He would get his result anyway.____
> 
>         ____
> 
>         Moreover, the interface name is a challenge only for the legitimate user.____
> 
>         An attacker could easily find the type of the operating system and guess it.____
> 
>         It is weak protection against attacker.____
> 
>         ____
> 
>         Moreover2, a daemon to listen for port 80 would have much more probability to be connected to GUA/ULA, not LLA.____
> 
>         The attacker would probably start scanning from GUA anyway.____
> 
>         ____
> 
>         Hence, better to give the user more convenience because security is not possible to improve in this way.____
> 
>         Ed/____
> 
>         *From:*Brian Carpenter [mailto:[e-mail] <mailto:[e-mail]>]
>         *Sent:* Thursday, June 30, 2022 1:03 PM
>         *To:* Vasilenko Eduard <[e-mail] <mailto:[e-mail]>>
>         *Cc:* 6man WG <[e-mail] <mailto:[e-mail]>>
>         *Subject:* Re: I-D Action: draft-ietf-6man-rfc6874bis-01.txt____
> 
>         ____
> 
>         There is an opposite argument: supporting a default zone makes an attack easier because the zone does not need to to be guessed.____
> 
>         Windows does exactly what you suggest, by the way; I could not run my tests on Linux.____
> 
>         Regards,
>              Brian Carpenter
>              (via tiny screen & keyboard)
>         ____
> 
>         ____
> 
>         On Thu, 30 Jun 2022, 21:22 Vasilenko Eduard, <[e-mail] <mailto:[e-mail]>> wrote:____
> 
>             Hi Brian,
>             Just one small idea: does it make sense to request
>             "All applications claiming support for this document SHOULD choose one LLA zone as the default.
>             If the user would omit the zone for the literal request to fe80:: then the application SHOULD use the default zone".
>             It would greatly simplify life for many users because they have only one interface on the host - they would never need to investigate the name of the zone that is very OS-specific.
> 
>             I do not like the request in RFC 4007:
>             index value zero at each scope SHOULD be reserved to mean "use the default zone"
>             IMHO: it is much better to omit the zone name completely to get access to the default zone.
>             People may not know that zone 0 has a special meaning.
> 
>             Formally, what I have proposed does not contradict RFC 4007
>             Because the default zone could be omitted and could be 0 at the same time
>             (both would lead to the same default zone).
> 
>             If you would say "No" to this request
>             Then please, repeat RFC 4007 that the default zone SHOULD be and SHOULD be "0".
>             Please, remind people of this fact.
>             Eduard
>             -----Original Message-----
>             From: ipv6 [mailto:[e-mail] <mailto:[e-mail]>] On Behalf Of Brian E Carpenter
>             Sent: Thursday, May 19, 2022 3:53 AM
>             To: [e-mail] <mailto:[e-mail]>
>             Subject: Re: I-D Action: draft-ietf-6man-rfc6874bis-01.txt
> 
>             There's been no more discussion for several weeks. Can we move on to a WG Last Call?
> 
>             Regards
>                  Brian Carpenter
>             On 08-Apr-22 14:29, Brian E Carpenter wrote:
>              > Hi,
>              >
>              > This version reflects comments at the IETF and on the list.
>              > Change log:
>              > * Extended use cases (added Microsoft WSD)
>              > * Clarified relationship with RFC3986 language
>              > * Allow for legacy use of RFC6874 format
>              > * Augmented security considerations
>              > * Editorial and reference improvements
>              >
>              > Note that some of the text about RFC3986 that Shang Ye suggested to
>              > remove has been retained, but modified. Further comments about this,
>              > or any other aspect, are very welcome.
>              >
>              > Regards
>              >      Brian + co-authors
>              >
>              > On 08-Apr-22 14:13, [e-mail] <mailto:[e-mail]> wrote:
>              >>
>              >> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>              >> This draft is a work item of the IPv6 Maintenance WG of the IETF.
>              >>
>              >>           Title           : Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers
>              >>           Authors         : Brian Carpenter
>              >>                             Stuart Cheshire
>              >>                             Robert M. Hinden
>              >>      Filename        : draft-ietf-6man-rfc6874bis-01.txt
>              >>      Pages           : 13
>              >>      Date            : 2022-04-07
>              >>
>              >> Abstract:
>              >>      This document describes how the zone identifier of an IPv6 scoped
>              >>      address, defined as <zone_id> in the IPv6 Scoped Address Architecture
>              >>      (RFC 4007), can be represented in a literal IPv6 address and in a
>              >>      Uniform Resource Identifier that includes such a literal address.  It
>              >>      updates the URI Generic Syntax and Internationalized Resource
>              >>      Identifier specifications (RFC 3986, RFC 3987) accordingly, and
>              >>      obsoletes RFC 6874.
>              >>
>              >>
>              >> The IETF datatracker status page for this draft is:
>              >> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/ <https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/>
>              >>
>              >> There is also an HTML version available at:
>              >> https://www.ietf.org/archive/id/draft-ietf-6man-rfc6874bis-01.html <https://www.ietf.org/archive/id/draft-ietf-6man-rfc6874bis-01.html>
>              >>
>              >> A diff from the previous version is available at:
>              >> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc6874bis-01 <https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc6874bis-01>
>              >>
>              >>
>              >> Internet-Drafts are also available by rsync at
>              >> rsync.ietf.org::internet-drafts
>              >>
>              >>
>              >> _______________________________________________
>              >> I-D-Announce mailing list
>              >> [e-mail] <mailto:[e-mail]>
>              >> https://www.ietf.org/mailman/listinfo/i-d-announce <https://www.ietf.org/mailman/listinfo/i-d-announce>
>              >> Internet-Draft directories: http://www.ietf.org/shadow.html <http://www.ietf.org/shadow.html> or
>              >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
>              >>
> 
>             --------------------------------------------------------------------
>             IETF IPv6 working group mailing list
>             [e-mail] <mailto:[e-mail]>
>             Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>             --------------------------------------------------------------------____
> 
>         --------------------------------------------------------------------
>         IETF IPv6 working group mailing list
>         [e-mail] <mailto:[e-mail]>
>         Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>         --------------------------------------------------------------------____
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------