ipv4 + ipv6 exit : v6 policy is displayed twice, v4 isn't displayed

changed milestone to %Tor: 0.2.7.x-final

added 026-backport 2016-bug-retrospective PostFreeze027 component::core tor/tor ipv6 milestone::Tor: 0.2.7.x-final priority::very high resolution::fixed status::closed type::defect version::tor 0.2.7 labels

Good catch. But it's not a bug. Here's why:

Your relay writes its full IPv4 exit policy to its server descriptor, but it only includes a summary of its IPv6 exit policy in the same document. The reason is that normal clients don't care about the details anymore but only use the summary these days. If an exit node rejects a connection they thought was permitted, they'll try somewhere else. In theory, relays could switch to only including an IPv4 exit policy summary in their server descriptors, but nobody wrote that code yet. In this case it seems like both summaries are the same, even if the detailed exit policies differ.

So, there's no way how Atlas could display the long form of your IPv6 exit policy. But can you think of a way to make this more intuitive for Atlas users? Should we throw out the full exit policy entirely?

Trac:
torrc

torrc

Erm, the current behaviour shows in this example a wrong "IPv4 Exit Policy Summary" and an incomplete "Exit Policy" (torrc attached).

So better show nothing than wrong/incomplete values IMO.

If that's really the torrc that your relay currently uses, then there's possibly a bug in Tor. Here's a recent server descriptor published by your relay:

router zwiebeltoralf 5.9.158.75 443 0 0
or-address [2a01:4f8:190:514a::2]:443
platform Tor 0.2.6.7 on Linux
protocols Link 1 2 Circuit 1
published 2015-05-18 14:48:49
fingerprint F1BE 1542 9B3C E696 D680 7F4D 4A58 B1BF EC45 C822
uptime 0
bandwidth 8388608 41943040 3236864
extra-info-digest 29047D780FB5E5774B44D359C24FA68A16FDCF77
onion-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBALyeOrYKA4kdObL4DFWgEOV9OCnJRSOkGHGNyYGZOTiFWwE7lgfmZm2w
fQcGwo/Auv/vOHBbifYjdO3z/Mdhx96imieloV4a9+Q69i6f9lK/r0VjlsxudIvN
mVYqd145RV+d5mv45WLS+H1D6+XrkR/+LIBYT11/maEV8ICWHlBvAgMBAAE=
-----END RSA PUBLIC KEY-----
signing-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBANdI7BYS2UyCQ+2jVJnTMKyvYm41U4tAsE2+XD6CrmKF+Mm6ePyan9uw
spmfPcG9l5vVNUC2npldyxhbbExTskzhw4BGDhDbSPZGnclC3AmCuJUz+Gj4FbC4
x+2m83XAUFUzCI9R1tHkEYPEThJiapl7hN/iUEvcX9l3B8bX61zfAgMBAAE=
-----END RSA PUBLIC KEY-----
hidden-service-dir
contact replace k with c : kontakt @ zwiebeltoralf . de
ntor-onion-key OUk2GV0LkdUTNTuETpte/eqIKp4tfmF383e/C0uCehs=
reject 0.0.0.0/8:*
reject 169.254.0.0/16:*
reject 127.0.0.0/8:*
reject 192.168.0.0/16:*
reject 10.0.0.0/8:*
reject 172.16.0.0/12:*
reject 5.9.158.75:*
accept *:443
accept *:989-995
accept *:6660-6669
accept *:6679
accept *:6697
reject *:*
ipv6-policy accept 443,989-995,6660-6669,6679,6697
router-signature
-----BEGIN SIGNATURE-----
CbsQ3/HNBJJLRmm4yE+KIyQW46U92Mn1z7wPZW79FUdxbvGpAC1LrdWT3VTWAGyV
+wDKd9iFyJqLLFyLj5QdjPfeomRrC91fGeYKOMUHI62t039WhBj0sWoVpafLWQzt
gQgJswW/DGEN5SGjYmTAAjQbX+B5jz0K7Zn4s87fx60=
-----END SIGNATURE-----

Changing component to Tor, because if this is really a bug in Tor, fixing that would be more important than making Atlas' interface more intuitive.

Trac:
Component: Onionoo to Tor

IMO it there is an issue - the output of my script http://www.zwiebeltoralf.de/pub/info.py shows a lot of used ports of bitcoins and so which are not opened in ipv6.

Oh interesting. Another related ticket (the spec around this needs clarification): #16103 (moved)

Trac:
Keywords: N/A deleted, 026-backport ipv6 added
Milestone: N/A to Tor: 0.2.7.x-final

I'd merge patches for these for 0.2.7 if they come in on time. In some cases, that will require figuring out an as-yet-unsolved bugs.

Trac:
Keywords: 026-backport ipv6 deleted, 026-backport, ipv6, PostFreeze027 added

Trac:
Priority: normal to major

I think this is maybe a bug, or maybe a documentation error? Either way, it's really-need-to-fix IMO.

Trac:
Priority: major to critical

As far as I'm aware, the current tor code treats accept and accept6 identically, and treats reject and reject6 identically.

When an accept or accept6 line has an address "*", it's treated as "all IPv4 and IPv6 addresses". For example, "accept *:443" and "accept6 *:443" both mean "accept connections to all IPv4 and IPv6 addresses on port 443".

So all ExitPolicy lines in the attached torrc past line 39 are being ignored: "ExitPolicy reject6 :"

However, if you specify "accept6 *6:443" you will get the behaviour you're looking for: "accept connections to all IPv6 addresses on port 443".

Ugh. I think that accept6/reject6 shpuld either get a warning, or start meaning ipv6 only. And the manpage has to get fixed too. Possibly the sample torrc as well.

Ideally, I'd like to see the following:

accept6/reject6 means IPv6 only, accept6 : means all IPv6 addresses, warn on IPv4 address or *4

In addition, we could:

introduce accept4/reject4, which mean IPv4 only, accept4 : means all IPv4 addresses, warn on IPv6 address or *6
deprecate accept/reject, which mean IPv4 and IPv6, accept : means all IPv4 and IPv6 addresses, warn on all uses and recommend user moves to accept4/accept6/reject4/reject6

I think this provides a sensible migration path and I'm happy to code it (I'm familiar with the code in question).

What do you think, nickm? Which parts would you want in 027? Would you want any of it in 026?

I've given this some further thought today. In summary:

The current accept/accept6 scheme is confusing, as accept6 looks like it should mean all IPv6 addresses only.
My first suggestion of changing accept6 to mean IPv6 addresses, without changing the meaning of accept (both IPv4 and IPv6), just seems to add to the confusion.
I no longer like the semantics of changing accept to mean IPv4 addresses, as it changes the meaning of accept : and reject :, which is the last entry in many ExitPolicy blocks. This could cause IPv6 Exits to have many more open ports, a serious issue.

I am now if favour of the following scheme: (based on my second suggestion above)

accept/reject don't change semantics, they mean both IPv4 and IPv6 addresses.
- This preserves the semantics of accept : and reject :, which are vital to the correct operation of many ExitPolicy blocks.
- Warn that any torrc ExitPolicy entries after an accept : or reject : are ignored. (This would perhaps have assisted toralf in discovering and resolving their issues at config time.)
- Warn that any accept/reject *:N entries cover both IPv4 and IPv6.
accept4/reject4 mean IPv4 addresses only. (Using with *:N means IPv4 only.)
- Using accept4/reject4 with IPv6 addresses or *6:N is an error or a warning. It has no effect.
- Info about new behaviour for consistency with accept6/reject6?
accept6/reject6 mean IPv6 addresses only. (Using with *:N means IPv6 only.)
- Using accept6/reject6 with IPv4 addresses or *4:N is an error or a warning. It has no effect.
- Warn or info about changed behaviour.

This has the following impacts:

accept6/reject6 lines change behaviour to only affect IPv6. This could change the number of open IPv4 or IPv6 ports on existing Exits. However, this is likely to be closer to actual operator intent.
counter-intuitive combinations are now flagged using warnings or errors.

We may also need to make similar changes to the default exit policy in-code, manpage, sample torrc, and torspec.

Hm. This sounds pretty comprehensive and sensible. How much of this do you think it makes sense to do for 0.2.7, seeing that I really want to stop fixing non-showstopper non-regression issues this week?

We can't make the changes I suggested above.

I just read router_add_exit_policy, which already enforces the following conditions when parsing Exit relay descriptors:

accept/reject must not be followed by an IPv6 address
accept6/reject6 must not be followed by an IPv4 address This descriptor-parsing code is already deployed to the authorities, thousands of relays, and millions of clients.

So I suggest a matching set of changes on the torrc parsing side:

accept6/reject6 must not be followed by an IPv4 address, including *4
- if this happens, warn and ignore the ExitPolicy entry
accept6/reject6 : produces an accept6/reject6 IPv6 wildcard address only
- this is changed behaviour, but it's probably what the operator expected
- info about changed behaviour?
accept/reject must not be followed by an IPv6 address, including *6
- if this happens, warn and ignore the ExitPolicy entry
accept/reject : produces an accept/reject wildcard IPv4 address only
- info/warn about changed behaviour?)

This last change is consistent with the other changes, and resolves toralf's issue. But it might confuse operators who end their policies in accept/reject : and expect it to catch IPv4 and IPv6. That said, the existing order dependency between IPv4 and IPv6 lines is how we got into this mess, and we need to kill it.

The fixes in comment 15 are required to get policies_parse_exit_policy_internal working as intended. Currently, the ipv6_exit parameter is ignored if the last line is accept *:*. (Which can't be the intention, surely.)

I'll need to add IPv6 entries to DEFAULT_EXIT_POLICY in policies.c as well. (Previous versions of tor would have parsed it and used it to cover both IPv4 and IPv6.)

And if local_address should take an array of local IPv4 and IPv6 addresses, not just a single IPv4 address. Split off into #17027 (moved). (This is a potential security issue, as it allows connections to local ports on an exit.)

ipv4 + ipv6 exit : v6 policy is displayed twice, v4 isn't displayed

Child items ...

Activity