Opened 8 years ago

Last modified 2 years ago

#3587 new defect

Accounting should work with pluggable transports

Reported by: asn Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-bridge tor-pt needs-design
Cc: Actual Points:
Parent ID: #3591 Points: 5
Reviewer: Sponsor:

Description

A bridge operator supporting pluggable transports should still be able to enforce accounting policies.

(This is also related to #3586)

Child Tickets

Change History (14)

comment:1 Changed 8 years ago by asn

Parent ID: #3591

comment:2 Changed 8 years ago by nickm

Accounting _and_ rate-limiting (they're different).

comment:3 Changed 8 years ago by nickm

Milestone: Tor: unspecified

I'd like to get a better answer than our current one here, but for now this needs to be unspecified

comment:4 in reply to:  3 Changed 8 years ago by asn

Replying to nickm:

I'd like to get a better answer than our current one here, but for now this needs to be unspecified

Our current answer is doing accounting and rate-limiting directly on the pluggable transport proxy binary. It's a temporary hacky solution for operators who really want to enforce some traffic limit, but we should indeed make it better. And by better, I mean more dynamic and usable.

My suggestion would be to have tor using the Extended OR Port transmit real-time accounting/rate-limiting information to the proxy. IIRC you don't like the idea of the Extended OR Port maintaining a continuous relationship with the proxy, and you want the Extended OR Port restricted to carrying data after the initial negotiation.

comment:5 Changed 8 years ago by nickm

Our current answer is doing accounting and rate-limiting directly on the pluggable transport proxy binary

Yup. I think this will have to do for 0.2.3.x.

My suggestion would be to have tor using the Extended OR Port transmit real-time accounting/rate-limiting information to the proxy. IIRC you don't like the idea of the Extended OR Port maintaining a continuous relationship with the proxy, and you want the Extended OR Port restricted to carrying data after the initial negotiation.

This would definitely need specification.

I think the right way to do it, if we need continuous feedback between the plugin and Tor, is to have the Extended OR port's role here be limited to establishing an identifier for each connection, so that Tor can tell the plugin about connections out-of-band.

comment:6 in reply to:  5 Changed 8 years ago by asn

Replying to nickm:

Our current answer is doing accounting and rate-limiting directly on the pluggable transport proxy binary

Yup. I think this will have to do for 0.2.3.x.

My suggestion would be to have tor using the Extended OR Port transmit real-time accounting/rate-limiting information to the proxy. IIRC you don't like the idea of the Extended OR Port maintaining a continuous relationship with the proxy, and you want the Extended OR Port restricted to carrying data after the initial negotiation.

This would definitely need specification.

Yes.

I think the right way to do it, if we need continuous feedback between the plugin and Tor, is to have the Extended OR port's role here be limited to establishing an identifier for each connection, so that Tor can tell the plugin about connections out-of-band.

How much out-of-band are you thinking of? Do you mean an extra Tor port, which will only be used to transfer information between Tor and the plugin based on the identifiers negotiated through Extended OR port?

comment:7 Changed 8 years ago by nickm

Yes, something like that.

comment:8 Changed 8 years ago by asn

Do you think I should also pass the clients' addresses through this new "Transport Metadata port", and keep the Extended OR port only for negotiating identifiers and passing transport traffic?
That's what makes sense to me.

If it makes sense to you as well, I think that I should delete the current Extended OR port section from 180, and create a new proposal specifying both the Extended OR port and the "Transport Metadata port", and reference the new proposal in 180.

comment:9 Changed 8 years ago by asn

Also, in your opinion, do you think I should do this Extended OR port refactoring, before or after #4685 gets delivered?

I would like to do it before #4685, but if we want to have everything in #3591 crossed-out for #4685 it would make more sense to do it afterwards. I think a sane plan, would be to prepare the specification side of this for #4685, and implement it afterwards (or even before, if I end up having enough time).

comment:10 Changed 8 years ago by nickm

I think we should do a new transport metadata proposal together. We should IMO not edit 180 any further: instead, we should extract the implemented part of 180 into a new spec.

I don't have a strong feeling about what goes in which protocol. I think that keeping the addresses as part of the extended or port idea could be a good idea, since otherwise Tor doesn't know where the connection is really coming from for a little while. But there could be a way to make it work simply, maybe.

I don't think that this blocks #4685 in any straightforward way.

comment:11 in reply to:  10 Changed 8 years ago by asn

Replying to nickm:

I think we should do a new transport metadata proposal together. We should IMO not edit 180 any further: instead, we should extract the implemented part of 180 into a new spec.

I don't have a strong feeling about what goes in which protocol. I think that keeping the addresses as part of the extended or port idea could be a good idea, since otherwise Tor doesn't know where the connection is really coming from for a little while. But there could be a way to make it work simply, maybe.

I don't think that this blocks #4685 in any straightforward way.

Please see https://lists.torproject.org/pipermail/tor-dev/2012-January/003225.html for a draft.

comment:12 Changed 7 years ago by nickm

Keywords: tor-bridge added

comment:13 Changed 7 years ago by nickm

Component: Tor BridgeTor

comment:14 Changed 2 years ago by nickm

Keywords: tor-pt needs-design added
Points: 5
Severity: Normal
Note: See TracTickets for help on using tickets.