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

Yes, that will work for GUAs, as I said earlier. :)

On Thu, Jun 30, 2022 at 9:06 AM Vasilenko Eduard <
vasilenko.eduard@huawei.com> wrote:

> Thanks Ted. Good to know.
>
> What about opening a session to https://whatismyipaddress.com or similar?
> (from the victim)
>
> /64 is easy to assume.
>
> Ed/
>
> *From:* Ted Lemon [mailto:mellon@fugue.com]
> *Sent:* Thursday, June 30, 2022 6:19 PM
> *To:* Vasilenko Eduard <vasilenko.eduard@huawei.com>
> *Cc:* Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org>;
> 6man WG <ipv6@ietf.org>
> *Subject:* Re: I-D Action: draft-ietf-6man-rfc6874bis-01.txt
>
>
>
> 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.
>
>
>
> On Thu, Jun 30, 2022 at 6:33 AM Vasilenko Eduard <
> vasilenko.eduard@huawei.com> 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:ipv6-bounces@ietf.org] *On Behalf Of *Ted Lemon
> *Sent:* Thursday, June 30, 2022 3:45 PM
> *To:* Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org>
> *Cc:* 6man WG <ipv6@ietf.org>
> *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=
> 40huawei.com@dmarc.ietf.org> 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:brian.e.carpenter@gmail.com]
> *Sent:* Thursday, June 30, 2022 1:03 PM
> *To:* Vasilenko Eduard <vasilenko.eduard@huawei.com>
> *Cc:* 6man WG <ipv6@ietf.org>
> *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, <vasilenko.eduard@huawei.com>
> 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:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter
> Sent: Thursday, May 19, 2022 3:53 AM
> To: ipv6@ietf.org
> 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, internet-drafts@ietf.org 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/
> >>
> >> There is also an HTML version available at:
> >> 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
> >>
> >>
> >> Internet-Drafts are also available by rsync at
> >> rsync.ietf.org::internet-drafts
> >>
> >>
> >> _______________________________________________
> >> I-D-Announce mailing list
> >> I-D-Announce@ietf.org
> >> https://www.ietf.org/mailman/listinfo/i-d-announce
> >> Internet-Draft directories: http://www.ietf.org/shadow.html or
> >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>