commit e70357ba5099bded4457b9373ae2120dac651796 Author: Nick Mathewson nickm@torproject.org Date: Tue Oct 16 21:58:35 2012 -0400
add proposal 212-using-old-consensus --- proposals/000-index.txt | 2 + proposals/212-using-old-consensus.txt | 109 +++++++++++++++++++++++++++++++++ proposals/xxx-using-old-consensus.txt | 108 -------------------------------- 3 files changed, 111 insertions(+), 108 deletions(-)
diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 2fa2be6..02c88be 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -133,6 +133,7 @@ Proposals by number: 209 Tuning the Parameters for the Path Bias Defense [OPEN] 210 Faster Headless Consensus Bootstrapping [OPEN] 211 Internal Mapaddress for Tor Configuration Testing [OPEN] +212 Increase Acceptable Consensus Age [OPEN]
Proposals by status: @@ -182,6 +183,7 @@ Proposals by status: 209 Tuning the Parameters for the Path Bias Defense [for 0.2.4.x+] 210 Faster Headless Consensus Bootstrapping [for 0.2.4.x+] 211 Internal Mapaddress for Tor Configuration Testing [for 0.2.4.x+] + 212 Increase Acceptable Consensus Age [for 0.2.4.x+] ACCEPTED: 117 IPv6 exits [for 0.2.4.x] 140 Provide diffs between consensuses diff --git a/proposals/212-using-old-consensus.txt b/proposals/212-using-old-consensus.txt new file mode 100644 index 0000000..55de290 --- /dev/null +++ b/proposals/212-using-old-consensus.txt @@ -0,0 +1,109 @@ +Filename: 212-using-old-consensus.txt +Title: Increase Acceptable Consensus Age +Author: Mike Perry +Created: 01-10-2012 +Status: Open +Target: 0.2.4.x+ + +Overview + + This proposal aims to extend the duration that clients will accept + old consensus material under conditions where the directory authorities + are either down or fail to produce a valid consensus for an extended + period of time. + +Motivation + + Currently, if the directory authorities are down or fail to consense + for 24 hours, the entire Tor network will cease to function. Worse, + clients will enter into a state where they all need to re-bootstrap + directly from the directory authorities, which will likely exacerbate + any potential DoS condition that may have triggered the downtime in the + first place. + + The Tor network has had such close calls before. In the past, we've + been able to mobilize a majority of the directory authority operators + within this 24 hour window, but that is only because we've been + exceedingly lucky and the DoS conditions were accidental rather than + deliberate. + + If a DoS attack was deliberately timed to coincide with a major US + and European combined holiday such as Christmas Eve, New Years Eve, or + Easter, it is very unlikely we would be able to muster the resources to + diagnose and deploy a fix to the authorities in time to prevent network + collapse. + +Description + + Based on the need to survive multi-day holidays and long weekends + balanced with the need to ensure clients can't be captured on an old + consensus forever, I propose that the consensus liveness constants be + set at 3 days rather than 24 hours. + + This requires updating two consensus defines in the source, and one + descriptor freshness variable. The descriptor freshness should be + set to a function of the consensus freshness. + + See Implementation Notes for further details. + +Security Concerns: Using an Old Consensus + + Clients should not trust old consensus data without an attempt to + download fresher data from a directory mirror. + + As far as I could tell, the code already does this. The minimum + consensus age before we try to download new data is two hours. + + However, the ability to accept old consensus documents does introduce + the ability of malicious directory mirrors to feed their favorite old + consensus document to clients to alter their paths until they + download a fresher consensus from elsewhere. Directory guards + (Proposal 207) may exacerbate this ability. + + This proposal does not address such attacks, and seeks only a modest + increase in the valid timespan as a compromise. + + Future consideration of these and other targeted-consensus attacks + will be left to proposals related to ticket #7126[1]. Once those + proposals are complete and implemented, raising the freshness limit + beyond 3 days should be possible. + +Implementation Notes + + There appear to be at least three constants in the code involved with + using potentially expired consensus data. Two of them + (REASONABLY_LIVE_TIME and NS_EXPIRY_SLOP) involve the consensus itself, + and two (OLD_ROUTER_DESC_MAX_AGE and TOLERATE_MICRODESC_AGE) deal with + descriptor liveness. + + Two additional constants ROUTER_MAX_AGE and ROUTER_MAX_AGE_TO_PUBLISH + are only used when submitting descriptors for consensus voting. + + FORCE_REGENERATE_DESCRIPTOR_INTERVAL is the maximum age a router + descriptor will get before a relay will re-publish. It is set to 18 + hours. + + OLD_ROUTER_DESC_MAX_AGE is set at 5 days. TOLERATE_MICRODESC_AGE + is set at 7 days. + + The consensus timestamps are used in + networkstatus_get_reasonably_live_consensus() and + networkstatus_set_current_consensus(). + + OLD_ROUTER_DESC_MAX_AGE is checked in routerlist_remove_old_routers(), + router_add_to_routerlist(), and client_would_use_router(). + + It is my opinion that we should combine REASONABLY_LIVE_TIME and + NS_EXPIRY_SLOP into a single define, and make OLD_ROUTER_DESC_MAX_AGE a + function of REASONABLY_LIVE_TIME and FORCE_REGENERATE_DESCRIPTOR_INTERVAL: + + #define REASONABLY_LIVE_TIME (3*24*60*60) + #define NS_EXPIRY_SLOP REASONABLY_LIVE_TIME + #define OLD_ROUTER_DESC_MAX_AGE \ + (REASONABLY_LIVE_TIME+FORCE_REGENERATE_DESCRIPTOR_INTERVAL) + + Based on my review of the above code paths, these changes should be all + we need to enable clients to use older consensuses for longer while + still attempting to fetch new ones. + +1. https://trac.torproject.org/projects/tor/ticket/7126 diff --git a/proposals/xxx-using-old-consensus.txt b/proposals/xxx-using-old-consensus.txt deleted file mode 100644 index 3e2a57a..0000000 --- a/proposals/xxx-using-old-consensus.txt +++ /dev/null @@ -1,108 +0,0 @@ -Title: Increase Acceptable Consensus Age -Author: Mike Perry -Created: 01-10-2012 -Status: Open -Target: 0.2.4.x+ - -Overview - - This proposal aims to extend the duration that clients will accept - old consensus material under conditions where the directory authorities - are either down or fail to produce a valid consensus for an extended - period of time. - -Motivation - - Currently, if the directory authorities are down or fail to consense - for 24 hours, the entire Tor network will cease to function. Worse, - clients will enter into a state where they all need to re-bootstrap - directly from the directory authorities, which will likely exacerbate - any potential DoS condition that may have triggered the downtime in the - first place. - - The Tor network has had such close calls before. In the past, we've - been able to mobilize a majority of the directory authority operators - within this 24 hour window, but that is only because we've been - exceedingly lucky and the DoS conditions were accidental rather than - deliberate. - - If a DoS attack was deliberately timed to coincide with a major US - and European combined holiday such as Christmas Eve, New Years Eve, or - Easter, it is very unlikely we would be able to muster the resources to - diagnose and deploy a fix to the authorities in time to prevent network - collapse. - -Description - - Based on the need to survive multi-day holidays and long weekends - balanced with the need to ensure clients can't be captured on an old - consensus forever, I propose that the consensus liveness constants be - set at 3 days rather than 24 hours. - - This requires updating two consensus defines in the source, and one - descriptor freshness variable. The descriptor freshness should be - set to a function of the consensus freshness. - - See Implementation Notes for further details. - -Security Concerns: Using an Old Consensus - - Clients should not trust old consensus data without an attempt to - download fresher data from a directory mirror. - - As far as I could tell, the code already does this. The minimum - consensus age before we try to download new data is two hours. - - However, the ability to accept old consensus documents does introduce - the ability of malicious directory mirrors to feed their favorite old - consensus document to clients to alter their paths until they - download a fresher consensus from elsewhere. Directory guards - (Proposal 207) may exacerbate this ability. - - This proposal does not address such attacks, and seeks only a modest - increase in the valid timespan as a compromise. - - Future consideration of these and other targeted-consensus attacks - will be left to proposals related to ticket #7126[1]. Once those - proposals are complete and implemented, raising the freshness limit - beyond 3 days should be possible. - -Implementation Notes - - There appear to be at least three constants in the code involved with - using potentially expired consensus data. Two of them - (REASONABLY_LIVE_TIME and NS_EXPIRY_SLOP) involve the consensus itself, - and two (OLD_ROUTER_DESC_MAX_AGE and TOLERATE_MICRODESC_AGE) deal with - descriptor liveness. - - Two additional constants ROUTER_MAX_AGE and ROUTER_MAX_AGE_TO_PUBLISH - are only used when submitting descriptors for consensus voting. - - FORCE_REGENERATE_DESCRIPTOR_INTERVAL is the maximum age a router - descriptor will get before a relay will re-publish. It is set to 18 - hours. - - OLD_ROUTER_DESC_MAX_AGE is set at 5 days. TOLERATE_MICRODESC_AGE - is set at 7 days. - - The consensus timestamps are used in - networkstatus_get_reasonably_live_consensus() and - networkstatus_set_current_consensus(). - - OLD_ROUTER_DESC_MAX_AGE is checked in routerlist_remove_old_routers(), - router_add_to_routerlist(), and client_would_use_router(). - - It is my opinion that we should combine REASONABLY_LIVE_TIME and - NS_EXPIRY_SLOP into a single define, and make OLD_ROUTER_DESC_MAX_AGE a - function of REASONABLY_LIVE_TIME and FORCE_REGENERATE_DESCRIPTOR_INTERVAL: - - #define REASONABLY_LIVE_TIME (3*24*60*60) - #define NS_EXPIRY_SLOP REASONABLY_LIVE_TIME - #define OLD_ROUTER_DESC_MAX_AGE \ - (REASONABLY_LIVE_TIME+FORCE_REGENERATE_DESCRIPTOR_INTERVAL) - - Based on my review of the above code paths, these changes should be all - we need to enable clients to use older consensuses for longer while - still attempting to fetch new ones. - -1. https://trac.torproject.org/projects/tor/ticket/7126