#774: updated URI syntax for IPv6 link-local zone identifiers

Visit on Github.

Opened Sep 12, 2022

Wotcher TAG!

I'm requesting a TAG review of "Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers" (draft-ietf-6man-rfc6874bis).

Explainer

From the 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.

This IETF draft proposes updating URI/IRI IP-literal syntax as follows:

 IP-literal = "[" ( IPv6address / IPv6addrz / IPvFuture  ) "]"

 ZoneID = 1*( unreserved )

 IPv6addrz = IPv6address "%" ZoneID

in order to help ensure adoption within browsers and other tools. One goal is to ease use of IPv6 link-local address literals in browsers when/where on-link device configuration is being performed.

This is a clarification and, importantly, simplification of RFC 6874.

Specification

The latest version of this draft can be found at https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc6874bis.

Tests

None of the kind TAG might expect. With respect to implementation, at a minimum, a patch to wget to support this change exists.

User research

Section 2 and Section 4 of draft -02 capture observations of IP address literal parsers and use (or lack thereof) currently. This forms part of the motivation for this document.

Security and Privacy self-review

Section 5 of draft -02 covers security and privacy considerations.

Primary contacts

Organization

This document is a product of the IETF IPv6 Maintenance working group (6man).

Key pieces of review

This document updates the IP-literal ABNF specification of URIs/IRIs. As such, any feedback on the correctness or additional thoughts on the document in general would be very much appreciated.

External trackers

  • The document status tracker here

Further details:

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify becarpenter, furry13, ekline

Discussions

Comment by @ekline Sep 12, 2022 (See Github)

@becarpenter @furry13

Comment by @becarpenter Sep 13, 2022 (See Github)

I'll add that recently I wrote a javascript mechanism to demonstrate that although theoretically one can script a scanning attack to discover link-local addresses via URLs with link-local address literals, it's impracticably slow (as suggested in the draft's Security Considerations). Even so, I won't publish the script. (The technique would also be able to discover any kind of IP address; it's by no means limited to IPv6 link-local.)

Discussed Oct 1, 2022 (See Github)

bumped

Discussed Oct 1, 2022 (See Github)

Yves: looks okay, but need to understand more

Discussed Oct 1, 2022 (See Github)

Yves: no progress. I want to look at the impact of the new syntax on the existing parser and things that can be treated as ? identifiers or not

Hadley: before plenary?

Yves: I won't be in plenary

Hadley: Dan said 6 days ago that we'd hope to get back to them soon. Can Dan carry it on while you're gone?

Yves: I can comment to say it looks good but need to work on a few things.

Comment by @torgo Oct 19, 2022 (See Github)

Hi @ekline just FYI we're looking at this and we hope to get back to you soon.

Discussed Nov 1, 2022 (See Github)

Yves: they replied but I don't think the refutation they gave is necessarily good.

Dan: Martin Thompson said he'd given feedback. Would be good to respond as Yves said, and to acknolwedge Martin's message which seems to suggest lack of implementer support. "Considering the lack of implementer support mentioned, it doesn't seem likely we can review this positively"

Discussed Nov 1, 2022 (See Github)

Dan: mixed messages..

Yves: it's right that malformed url or wrongly decoded url will be rejected, but this is not the proper way to do processing and escaping. It's relying on the fact there won't be bugs in parsing of things that have an escape char that is not an escape char. To me it's bad design. For the attacks, it's like many other things that can be attacked using local addresses. The IETF people against it need to fight. We expressed our concerns. I asked to have more discussion with the people in charge of revising the URL RFC, I think that's the proper place to discuss that. We can close with concerns and say we want to have that resolved in IETF.

Dan: I could ping mnot and ask him to weigh in on the issue, but perhaps we shouldn't do that

Yves: we can ask mark and martin if that would be a good course of action for them as well. Discuss closing at plenary.

Comment by @ekline Nov 1, 2022 (See Github)

Thank you. I've been slow to advance things on my end, but I do believe we should understand the W3C position before we take any irreversible steps. =)

Much appreciated, and happy end-of-year holiday season (already?!).

Comment by @becarpenter Nov 1, 2022 (See Github)

Be sure to check the latest version of the draft, there were significant updates since this issue was opened: https://www.ietf.org/archive/id/draft-ietf-6man-rfc6874bis-04.html There's also a very new issue noted at https://mailarchive.ietf.org/arch/msg/ipv6/G4pOCYDGXo-sYtzLxcooQP__WzU/

Comment by @martinthomson Nov 4, 2022 (See Github)

This thread might provide some useful input: https://mailarchive.ietf.org/arch/msg/ipv6/lkrJjMUwZrUC7jYAo2mYCS4fpeA/

Comment by @becarpenter Nov 4, 2022 (See Github)

FYI, the latest (-04) version was intended to respond to Martin's points, among other Last Call comments.

Comment by @becarpenter Nov 6, 2022 (See Github)

New version today : https://www.ietf.org/archive/id/draft-ietf-6man-rfc6874bis-05.html There's one change, adding a note that zone IDs with upper case letters won't work. (That's an issue we can't fix, due to a shortfall in RFC4007.)

Comment by @ylafon Nov 9, 2022 (See Github)

I looked at it, and wonder about its use to discover private information about the shape of the local network, especially when zones are interfaces. Also the use of % as the delimiter for the zone id means that you should either rewrite the entire abnf, or exclude all abnf-generated parsers. Having specific exclusions from the common use of % in URIs means specific code that has to be maintained and likely ways to abuse old parsers that would consider the % as the usual escape mechanism. In both case, this is not desirable.

Comment by @becarpenter Nov 9, 2022 (See Github)

About the malicious discovery issue, such an attack is impractical. This is discussed at https://www.ietf.org/archive/id/draft-ietf-6man-rfc6874bis-05.html#section-6-5 . I tried writing an address-scanning script (exploiting the fact that Windows supports a default Zone ID) and tested it on Firefox, Chrome and Edge. It's impractically slow since the search space is 2**64. (I have no intention of publishing my script and my Javascript skills are weak, but if you read the following thread, you will get the gist: https://mailarchive.ietf.org/arch/browse/ipv6/?gbt=1&q=scripting%20attacks )

The draft does update the ABNF and (as required by IETF process) we've validated the result. Most parsers don't seem to be written that way, however.

Comment by @ylafon Nov 24, 2022 (See Github)

Hi, we discussed the issue again during our last teleconference. The issue of malicious discovery is still there as it won't start with a brute-force attack, but more on probable zone names (especially if it involves interface names). Also the use of % as a delimiter is still seen as problematic as it is the escape delimiter and can lead to exploit of existing parsers that are not careful about when to apply unescaping. The lack of implementation support in browsers is another source of concern, it would be good also to get agreement within IETF, especially with the group in charge of maintenance of rfc3986. Thanks

Comment by @becarpenter Nov 24, 2022 (See Github)

Hi,

(I am blind copying this to the IETF 6MAN WG. Be careful when replying.)

On 25-Nov-22 02:10, Yves Lafon wrote:

Hi, we discussed the issue again during our last teleconference. The issue of malicious discovery is still there as it won't start with a brute-force attack, but more on probable zone names (especially if it involves interface names).

That is correct and is discussed at https://www.ietf.org/archive/id/draft-ietf-6man-rfc6874bis-05.html#section-6-6 . This theoretical risk has always existed for IPv6 literal addresses in URLs and is not specific to link-local addresses. The primary defence is the 64-bit size of the interface identifier space, which is impracticably large for a brute force search. This is one reason why the IETF now recommends pseudo-random interface identifiers, and has little to do with link-local addresses. (If you're looking for a practical brute force search, try starting at https://192.168.178.1/ .)

Given that, this is hardly an argument against supporting Zone IDs.

Also the use of |%| as a delimiter is still seen as problematic as it is the escape delimiter and can lead to exploit of existing parsers that are not careful about when to apply unescaping.

Why is there an "exploit" here? The worst that can happen is that a server rejects the URL. We discuss this eventuality in the draft at https://www.ietf.org/archive/id/draft-ietf-6man-rfc6874bis-05.html#section-4-1 , and it's really a feature, not a bug.

The lack of implementation support in browsers is another source of concern, it would be good also to get agreement within IETF, especially with the group in charge of maintenance of rfc3986.

We're trying to provide the egg half of the chicken-and-egg dilemma. It will be for each browser implementer to decide whether to proceed with the chicken. Of course the normal cross-area review process is under way in the IETF.

Thanks for the update.

 Brian

Thanks

— Reply to this email directly, view it on GitHub https://github.com/w3ctag/design-reviews/issues/774#issuecomment-1326433378, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMKET5QCMHVPQNBQBM3IDTWJ5SMLANCNFSM6AAAAAAQK45ROU. You are receiving this because you were mentioned.Message ID: @.***>

Discussed Dec 1, 2022 (See Github)

Yves: goal was to close with concerns or unsatisfied. The IETF group in charge of URLs should discuss it.

Dan: I don't think we're satisfied

Yves: we voiced our concerns and we would like those to be discussed in an ietf group

Dan: I also dont' think we can say unsatisfied... ambivalent or out of scope?

Yves: ambivalent would be better, but clearly we need more stakeholder support as well. Browsers indicated they didn't want to implement it.

Dan: so it should be unsatisfied.

Yves: this still shouldn't be a blocker - ietf might find a way that will work.

<blockquote> Hi folks - We've expressed some concerns about the current proposal especially around the use of '%' as a delimiter. Also it seems there is lack of implementer support, which is a concern to us. Hence we're going to close this one with an "unsatisfied" label. Our suggestion is that discussion should continue at the IETF, with the group in charge of RFC3986. We look forward to hearing from you again when these issues have been resolved. </blockquote>

Dan: cloeses and leaves comment

Comment by @torgo Dec 20, 2022 (See Github)

Hi folks - As discussed in today's TAG breakout. We've expressed some concerns about the current proposal especially around the use of '%' as a delimiter. Also it seems there is lack of implementer support, which is a concern to us. Hence we're going to close this one with an "unsatisfied" label. Our suggestion is that discussion should continue at the IETF, with the group in charge of RFC3986. We look forward to hearing from you again when these issues have been resolved.

Comment by @becarpenter Dec 20, 2022 (See Github)

Erik, et al.,

Please see the attached response from W3CTAG. Their remaining comments are not new and have been addressed previously:

a) The necessity to use "%" is unfortunate but inevitable, due to the fact that it was defined as the delimiter by RFC 4007 in 2005 and has been embedded in operating systems and the socket API ever since. It was a bad choice but we are stuck with it, and the proposed ABNF is parsable (as illustrated by the corresponding patch to WGET). We have not heard from any browser implementer that it cannot be parsed.

b) The "lack of implementer support" is not unusual for advancement to an IETF Proposed Standard; it is only when a document is advanced to Internet Standard that it becomes an issue. In fact, this "bug" has been re-activated for FireFox. **

Therefore, there are no further updates to the draft at this time.

As far as I know, there is no group in the IETF "in charge of RFC3986" apart from the IESG. May we proceed?

Regards Brian Carpenter

** https://bugzilla.mozilla.org/show_bug.cgi?id=700999#c94

On 20-Dec-22 21:33, Daniel Appelquist wrote:

Hi folks - As discussed in today's TAG breakout https://github.com/w3ctag/meetings/blob/gh-pages/2022/telcons/12-19-agenda.md. We've expressed some concerns about the current proposal especially around the use of '%' as a delimiter. Also it seems there is 2005, which is a concern to us. Hence we're going to close this one with an "unsatisfied" label. Our suggestion is that discussion should continue at the IETF, with the group in charge of RFC3986. We look forward to hearing from you again when these issues have been resolved.

— Reply to this email directly, view it on GitHub https://github.com/w3ctag/design-reviews/issues/774#issuecomment-1359002511, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMKET6RRHSVOWSMTNKPA4TWOFVNHANCNFSM6AAAAAAQK45ROU. You are receiving this because you were mentioned.Message ID: @.***>