Subject: ietf.org unaccessible for Tor users

From: Yui Hirasawa <[email-masked]>
Date: Sun, 13 Mar 2016 16:35:21 +0200

Hello IETF,

Today when I tried to go read a standard on the ietf.org website I was
met with a CloudFlare CAPTCHA page.

By using CloudFlare IETF is actively blocking Tor connections to IETF
page. CloudFlare also works as man-in-the-middle and all encryption to
ietf.org is null and void which means IETF is actively helping the
authoritarian governments weaken the encryption on the Internet.
CloudFlare also requires proprietary javascript to be run by Tor users
who want to access websites which makes fingerprinting them very easy.
Because CloudFlare is a man-in-the-middle it can also inject websites
with malicious javascript, such as fingerprinting javascript. CloudFlare
also collects all connection data and is subject to US secret courts and
thus using it is directly contributing to the mass surveillance of the
Internet.

Tor project has also finally started noticing this[1]. And I wrote a
small thing[2] about it on my website recently as well.

IETF using CloudFlare is a very bad thing for the security and
neutrality of the Internet and this should be fixed immediately.

If you think there is some other place where I could notify people about
this then please send me an email.

[1]: https://trac.torproject.org/projects/tor/ticket/18361
[2]: https://GNU.moe/thoughts/cloudflare.html

---

From: Randy Bush <[email-masked]>
Date: Tue, 15 Mar 2016 08:26:37 +0900

> page.

i agree this is a problem.  but i am not sure about the solution space.
are we trading one form of security for another?

what is the treat model which drives us to tls/https?  authenticity of
the data?  privacy of what i access?  in the scheme of things, how
important are our data anyway and what are we trading for perceived
protection?

how much load-spreading and resilience do ietf web/wiki/archives
actually need?  if they need a cdn, and i am not so sure they do, can we
have a cdn which supports tls without being a monkey in the middle?  do
we pay to deploy a half dozen anycasted instances of our own and
maintain them [0]?

some of this we have discussed before, maybe not as insightfully as we
might have.

randy

0 - sysadmin is similar to doing the dishes; you go to sleep with a
    clean kitchen, but there will be more dishes tomorrow.

---

From: "John Levine" <[email-masked]>
Date: 15 Mar 2016 00:26:04 -0000

>> By using CloudFlare IETF is actively blocking Tor connections to IETF

Only if you're a robot that can't do the captcha.

>have a cdn which supports tls without being a monkey in the middle?

Cloudflare provides DDoS protection along with the load spreading.  For
the second question, I've seen a lot of CDNs and can't think of one that
does a good job with TLS certificates.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 14 Mar 2016 21:55:55 -0400

Hi,

Speaking only as myself:

> important are our data anyway and what are we trading for perceived

I think the question of what we want to accomplish is important and
the one I'd hope we'd focus on first when trying to answer these
questions.  It seems to me that people ought to be able to access IETF
stuff in as many ways as we can think of, and to do that without fear
of repercussions.  yet we need to do something about the attacks
against the IETF sites, which have been painful and which we need to
be prepared to handle.

No brilliant suggestions here, just questions.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Michel Py <[email-masked]>
Date: Tue, 15 Mar 2016 04:01:21 +0000

> Andrew Sullivan wrote :
> yet we need to do something about the attacks against the IETF sites, which have been painful and which we need to be prepared to handle.

About a month ago, I did a quick analysis on Tor exit nodes and found that about half of them are on a blacklist of some kind. I am not assessing the validity of the various methodologies used to blacklist the addresses, I'm just counting beans. The captcha mentioned earlier is a middle way, as some organizations go further and block Tor entirely. Call it profiling all you want, it's no different than a spam blacklist : it's IP reputation; being a Tor exit node does carry a burden in the metric used to assess the reputation and therefore the threat potential. If it looks like a duck and quacks like a duck, some people are going to wonder if it's a duck. I'm not judging here, I'm just looking at numbers.

> No brilliant suggestions here, just questions.

None here either. Regrettably, some guys out there are using Tor for bad purposes, it also is a foregone conclusion that some of the attacks carried over Tor are part of the equivalent of a joe-job.

Trolling about Tor being blocked does not help, though. Here is the challenge for the brilliant minds in here : make it so it preserves the anonymity of people who genuinely need it, but stop it from being an attack vector. It means cleaning up when it enters the system, instead of having users cleaning when it exits the system.
 
Michel.

---

From: Narelle <[email-masked]>
Date: Tue, 15 Mar 2016 15:09:51 +1100

> Only if you're a robot that can't do the captcha.

I haven't checked this particular captcha but they are notoriously unusable
for those people who use text to speech readers, are dyslexic or have other
cognitive impairments.

Google has adopted 'reCaptcha' which seems to pass the accessibility
requirements for most of the vision impaired people we work with.

See: https://www.w3.org/TR/turingtest/

<goog_1496355201>
https://www.visionaustralia.org/business-and-professionals/digital-access-consulting/resources/blog---accessibility-and-assistive-technology-blog/blog/accessibility-blog/2014/12/09/effective-alternatives-to-inaccessible-captchas

In fact, we've been running a campaign against it with some success...
http://www.accan.org.au/news-items/media-releases/603-consumer-advocates-unite-to-kill-captcha

So while I have every sympathy for the use of content distribution systems,
I don't have any sympathy for things which break accessibility. Could this
please be added to the tender/purchasing requirements next time around?

Narelle Clark

---

From: Yoav Nir <[email-masked]>
Date: Tue, 15 Mar 2016 08:17:06 +0200

> does a good job with TLS certificates.

Maybe we should have a BoF to address this.
https://www.ietf.org/mailman/listinfo/lurk

---

From: Leif Johansson <[email-masked]>
Date: Tue, 15 Mar 2016 09:09:41 +0100

> Only if you're a robot that can't do the captcha.

I believe you missed an important point the OP made: those captchas
require javascript that effectively nullify any privacy that using
Tor in this case gives you.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 15 Mar 2016 08:20:45 +0000

I don’t have a solution, but I wanted to say that I feel the pain.

It is important that IETF documents are accessible via Tor. It is important that whatever CAPTCHA's are being employed, they are accessible to everyone. It is important that we at the IETF are able to deal with DoS attacks.

I’m not ready to believe that the above requirements are fundamentally in conflict.

I have a question thought and couple of other observations.

The question: Yui: I was under the (perhaps mistaken) assumption that ietf.org is generally accessible to everyone in the usual way, but that some blacklisted nodes will have to go through a CAPTCHA process before being able to continue. Is this so, or is there an experience that says nodes are blocked and there isn’t even a possibility to go through a CAPTCHA? Or is the problem that there is a CAPTCHA but you do not feel that it is done in a way that is appropriate? Does all this relate to http or https traffic?

The observations:

o   I do not feel that contracted running of multiple copies of our servers constitutes a man-in-the-middle arrangement.

o   I have asked the matter to be discussed in our IT/tools/IAOC meetings, but I’ll note that we may not have any more magical answers than what is already being discussed on the list.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 15 Mar 2016 08:37:56 +0000

Leif,

> Tor in this case gives you.

Ok. I think I’m now understanding this better than I did before. Thanks.

Are there examples of CAPTCHAs that don’t require javascript and are accessible to a wide variety of users?

Jari

---

From: Leif Johansson <[email-masked]>
Date: Tue, 15 Mar 2016 10:15:08 +0100

> Are there examples of CAPTCHAs that don’t require javascript and are accessible to a wide variety of users?

I think Narelle just provided a bunch of links.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 15 Mar 2016 11:14:53 +0100

On 3/15/16 9:20 AM, Jari Arkko wrote:
> It is important that IETF documents are accessible via Tor.

I'll bite: why is it important that IETF documents be accessible via Tor?

Eliot

---

From: Christian de Larrinaga <[email-masked]>
Date: Tue, 15 Mar 2016 10:18:20 +0000

One Internet or something?

> Eliot Lear <mailto:[email-masked]>
> 15 March 2016 at 10:14
>
> Jari Arkko <mailto:[email-masked]>
> 15 March 2016 at 08:20
> It is important that IETF documents are accessible via Tor. It is
> important that whatever CAPTCHA's are being employed, they are
> accessible to everyone. It is important that we at the IETF are able
> to deal with DoS attacks.
>
> The question: Yui: I was under the (perhaps mistaken) assumption that
> ietf.org is generally accessible to everyone in the usual way, but
> that some blacklisted nodes will have to go through a CAPTCHA process
> before being able to continue. Is this so, or is there an experience
> that says nodes are blocked and there isn’t even a possibility to go
> through a CAPTCHA? Or is the problem that there is a CAPTCHA but you
> do not feel that it is done in a way that is appropriate? Does all
> this relate to http or https traffic?
>
> The observations:
>
> o I do not feel that contracted running of multiple copies of our
> servers constitutes a man-in-the-middle arrangement.
>
> o I have asked the matter to be discussed in our IT/tools/IAOC
> meetings, but I’ll note that we may not have any more magical answers
> than what is already being discussed on the list.
>
> Jari
>
> Randy Bush <mailto:[email-masked]>
> 14 March 2016 at 23:26
>
> Yui Hirasawa <mailto:[email-masked]>
> 13 March 2016 at 14:35
> Hello IETF,
>

-- 
Christian de Larrinaga  FBCS, CITP,
-------------------------
@ FirstHand
-------------------------
+44 7989 386778
[email-masked]
-------------------------

---

From: Eliot Lear <[email-masked]>
Date: Tue, 15 Mar 2016 11:25:43 +0100

> One Internet or something?

By the logic nobody should use a Tor browser.  That way we have one
Internet.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 15 Mar 2016 10:38:03 +0000

Because some users under scrutiny of some nation states deem they need to use tor for their privacy and safety for all their browsing. It would be extremely dangerous to continuously switch tor off and on.

Note we are not talking about ietf being available as a hidden service, just that tor exit node IPs visiting the ietf sites do not require JavaScript - the latter compromises tor security for the user in general.

Sent from my iPhone

> On Mar 15, 2016, at 10:14, Eliot Lear <[email-masked]> wrote:
> 
> 
>

---

From: Randy Bush <[email-masked]>
Date: Tue, 15 Mar 2016 19:48:34 +0900

> accessible to a wide variety of users?

why should someone accessing an ietf site need to pass a captcha?
what's the threat model?  what if they want to automate something?

and, btw, i do not enable javascript and i can't pass many captchas,
with or without a tor tunnel.  e.g. trying to pay some online bills.

randy

---

From: Alec Muffett <[email-masked]>
Date: Tue, 15 Mar 2016 10:52:12 +0000

I'm going to express my personal views here, though I believe they're both cogent and sane:

On Mar 15, 2016, at 10:14 AM, Eliot Lear <[email-masked]<mailto:[email-masked]>> wrote:
On 3/15/16 9:20 AM, Jari Arkko wrote:
I don’t have a solution, but I wanted to say that I feel the pain.

Because Tor is another browser - actually several browsers, especially with Orbot meaning that a **lot** of Android users transparently sit behind it - and Tor is being used by a huge number of people.

I have three distinct lines of though regarding this:

= Accessibility =

We have long since left behind the world of "This Website is Best Viewed Using [browser] in 1024x768 Screensize!" - because accessibility is important.

We don't pick-and-choose what browsers people use to access websites any more, we embrace communication and leave them to render content in their preferred way, from Tor through Chrome to screen-readers.

= Threat Models =

Is it really in your best interests to block people from your website?

If you're mostly a read-only site - and the IETF site appears to be onesuch - then I would be amazed if a DDoS attack would come via Tor when it would be so much more effective and easier to set up coming from some random Botnet.

Simple economics suggest that the best way to knock the IETF website offline is to use a Botnet - so if (and perhaps I am wrong) the IETF wants to defend itself against DDoS, to block Tor is to defend yourself against the wrong tuple of (threat, actor) - if Tor is a threat to the IETF website at all.

If IETF was worried about having its content scraped-and-duplicated, yes I could totally see Tor as a risk to the IETF website; but I am not aware of that being part of the IETF threat model, else you'd require logged-in access already.

= Addresses Are Not People =

IP Reputation Systems are (at best) a hint, not a panacea, and we should remember that.

Elsewhere - to politicians, to activists - I've had to repeatedly explain that "1 IP Address != 1 Human Being", that you can't simply arrest the person who pays the ISP because their IP address apparently downloaded a movie; yet sometimes we are weirdly blind to the inverse, we seem happy to draw red lines* around chunks of internet space and call them "bad places", where only "unpeople" live.

It's not really logical to hold both perspectives firmly and simultaneously - sometimes an IP address is just one person.  And - conversely - behind those red lines drawn on the network map are an enormous number of normal, good people.  Probably more good people than bad.

So why make communication and participation harder for them?

    -a

* https://en.wikipedia.org/wiki/Redlining

--

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 15 Mar 2016 10:57:36 +0000

I fully agree that we ought enable people to access the IETF
site via Tor. That is entirely consistent with [1] (as is
still allowing plaintext, so let's not re-do that discussion:-)
Actually, I'd say that making life harder for people who
choose to use Tor is inconsistent with the spirit of [1]
unless there's some very good reason for that, e.g. if it
put other folks access to the IETF site at significant risk.
I don't think that last is the case.

As Jari said there're some folks who're looking at this so
I'd suggest we give 'em a bit of time to figure stuff out.
If someone feels that's taking too long, feel free to ping
me and I'll hassle whoever is the stuckee at that point and
report back.

Cheers,
S.

PS: I just installed TBB on a machine and didn't see any
captcha. That may mean that it's exit node specific I guess.

[1] https://www.ietf.org/iesg/statement/maximizing-encrypted-access.html

On 15/03/16 10:38, Paul Wouters wrote:
>>> I donâ€™t have a solution, but I wanted to say that I feel the pain.
>>>

---

From: Rich Kulawiec <[email-masked]>
Date: Tue, 15 Mar 2016 07:08:22 -0400

1. Captchas are worthless security theater.

If a given site is not a target, then of course they're not needed.

If a given site is a target, then they will be bypassed at will by
any modestly-talented, modestly-resourced attacker -- either
with automation, with humans, or with a combination of the two. [1]

In either case, they serve only to complicate site design/operation
and to make life more difficult for people who *already* are facing
difficulties.

2. If the goal (or one of the goals) here is to ensure that IETF
content is accessible to everyone and remains so in the face of
various attacks (and what *are* those, exactly?) then one simple
and robust approach is to set up static mirrors *and* to enable
rsync access so that anyone who wishes to can set up their own.

---rsk

[1] A few (of many) items discussing this, in no particular order:

	Stanford researchers outsmart captcha codes
	http://www.physorg.com/news/2011-11-stanford-outsmart-captcha-codes.html

	CIntruder: pentesting tool to bypass captchas
	http://cintruder.sourceforge.net/

	How a trio of hackers brought Google's reCAPTCHA to its knees
	http://arstechnica.com/security/2012/05/google-recaptcha-brought-to-its-knees/

	Snapchat Account Registration CAPTCHA Defeated
	http://it.slashdot.org/story/14/01/23/2037201/snapchat-account-registration-captcha-defeated

	Gone in 60 seconds: Spambot cracks Live Hotmail CAPTCHA
	http://arstechnica.com/news.ars/post/20080415-gone-in-60-seconds-spambot-cracks-livehotmail-captcha.html

	Troy Hunt: Breaking CAPTCHA with automated humans
	http://www.troyhunt.com/2012/01/breaking-captcha-with-automated-humans.html

	Now Even Photo CAPTCHAs Have Been Cracked
	http://it.slashdot.org/article.pl?sid=08/10/14/1442213

	Cheap CAPTCHA Solving Changes the Security Game
	https://freedom-to-tinker.com/blog/felten/cheap-captcha-solving-changes-security-game/

---

From: Eliot Lear <[email-masked]>
Date: Tue, 15 Mar 2016 12:12:16 +0100

> I don't think that last is the case.

Unless Tor itself is used for botnet C&C [1,2]?

Eliot

[1]
https://www.defcon.org/images/defcon-18/dc-18-presentations/D.Brown/DEFCON-18-Brown-TorCnC.pdf
[2] http://www.welivesecurity.com/2013/07/24/the-rise-of-tor-based-botnets/

---

From: Jari Arkko <[email-masked]>
Date: Tue, 15 Mar 2016 11:34:24 +0000

Folks,

When I said that access via Tor is important it was in the context of it being just another way to access Internet, kind of like different types of access networks or browsers. Didn’t want to attach any particular meaning to Tor or anything else. In positive or negative sense. Of course we want to maximise the ability of people to access IETF content, at least if it gets major usage.

However, I do want to make an argument that denial of service attacks are a fact of life. I know we don’t have foolproof solutions for them, but we have some practical means to deal with some of the effects, unfortunately somethings affecting proper usage as well. But I do think we need the ability for our network managers (or the ones that we delegate this to) deal with attacks using means that are necessary. Perhaps those means can be improved, but there will need to be some means.

Jari

---

From: Christian de Larrinaga <[email-masked]>
Date: Tue, 15 Mar 2016 11:34:42 +0000

With respect that is not the reasoning.

Cloudflare are intercepting access from some IPs and imposing a man in
the middle dialogue before "granting" access to
https://www.ietf.org/rfc.html

e.g. This is the report I get below a captcha -  CloudFlare Ray ID:
283f99aee908294a • Your IP: 93.115.95.206 • Performance & security by
CloudFlare

There may be other usability issues with the ietf site such as
javascript use but that is a separate issue I think to having a traffic
policeman standing permanently in the middle of the road.

The question is does IETF need that policeman to do that filtering? Is
it desirable? I don't get the sense that it is.

Christian

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 15 Mar 2016 11:39:28 +0000

> it desirable? I don't get the sense that it is.

I believe there have been attacks in the past that had they
been at larger scale could have taken the IETF site offline.
CF are a mitigation for that. I think some such mitigation
is sadly necessary. But I also think we want that to work
better, to not track folks and to not get in the way of access,
unless taking such actions is really necessary. (I don't think
it is myself, at least not in the normal course of events, but
then I don't see the operations stuff.)

Cheers,
S.

---

From: Leif Johansson <[email-masked]>
Date: Tue, 15 Mar 2016 12:40:55 +0100

> Unless Tor itself is used for botnet C&C [1,2]?

By that you mean Tor is used to transport packets to botnet C&C - much
like the Internet is used to transport packets to botnet C&C?

	Cheers Leif

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Mar 2016 11:44:44 +0000

The MiTM solution people are describing here seems like a very crude solution to this problem.   Perhaps the right way to address this problem is with less susceptible web server software, rather than with a privacy-destroying hack?

---

From: Alec Muffett <[email-masked]>
Date: Tue, 15 Mar 2016 11:44:40 +0000

Interesting. 

Jari, do you have any metrics to suggest that DDoS attacks are coming through Tor? 

Ideally meaningful high-bandwidth ones?

- a

---

From: "John R Levine" <[email-masked]>
Date: 15 Mar 2016 07:58:04 -0400

> I haven't checked this particular captcha but ...
>

So does Cloudmark.  You can see an example here:

https://support.cloudflare.com/hc/en-us/articles/203306930-Does-CloudFlare-block-Tor-

For all its noble intentions, most of the traffic that comes out of Tor is 
malicious.  (Any service that is anonymous and free has the same 
problems.)  Cloudmark and other providers don't block or filter it for 
political reasons, they do so to protect their users.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Christian de Larrinaga <[email-masked]>
Date: Tue, 15 Mar 2016 11:59:23 +0000

If it is necessary then that suggests a prioritised IETF workplan.
C
> Stephen Farrell <mailto:[email-masked]>
> 15 March 2016 at 11:39
>
> Christian de Larrinaga <mailto:[email-masked]>
> 15 March 2016 at 11:34
> Christian de Larrinaga <mailto:[email-masked]>
> 15 March 2016 at 11:30
> javascript use but that is a separate issue I think to having a
> traffic policeman standing permanently in the middle of the road.
>
> 15 March 2016 at 10:25
> Christian de Larrinaga <mailto:[email-masked]>
> 15 March 2016 at 10:18

---

From: John Kristoff <[email-masked]>
Date: Tue, 15 Mar 2016 12:19:49 +0000

On Tue, Mar 15, 2016 at 07:58:04AM -0400, John R Levine wrote:
> For all its noble intentions, most of the traffic that comes out of
> Tor is malicious.

This paper suggests an amount of malicious traffic that can be
categorized is approximately 10%.

  <http://www.cs.uml.edu/~xinwenfu/paper/TorWard14_Fu.pdf>

John

---

From: Antonio Prado <[email-masked]>
Date: Tue, 15 Mar 2016 13:28:12 +0100

On 3/15/16 9:20 AM, Jari Arkko wrote:
> I do not feel that contracted running of multiple copies of our servers constitutes a man-in-the-middle arrangement.

hi,

couldn't be possible to mirror IETF site inside TOR (ietf.onion)?

--
antonio

---

From: "John R Levine" <[email-masked]>
Date: 15 Mar 2016 08:38:13 -0400

>  <http://www.cs.uml.edu/~xinwenfu/paper/TorWard14_Fu.pdf>

It's a nice paper, but there's a lot of malicious traffic that an IDS 
doesn't recognize.

As Cloudmark points out, they don't block or filter Tor IPs because it's 
Tor, they do it because they see very high levels of abuse.

Regards,

---

From: Rich Kulawiec <[email-masked]>
Date: Tue, 15 Mar 2016 08:39:59 -0400

> Unless Tor itself is used for botnet C&C [1,2]?

Or unless the host itself is engaged in providing persistent/systemic
spam/malware/abuse support services?

	Cloudflare: The New Face of Bulletproof Spam Hosting
	http://tacit.livejournal.com/595116.html

---rsk

---

From: Randy Bush <[email-masked]>
Date: Tue, 15 Mar 2016 21:50:34 +0900

> For all its noble intentions, most of the traffic that comes out of

cite please

---

From: Eliot Lear <[email-masked]>
Date: Tue, 15 Mar 2016 13:58:50 +0100

> like the Internet is used to transport packets to botnet C&C?

Yes, but we at least can spot the C&C on the Internet.  See upthread
about how hard that is with Tor.

Eliot

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 15 Mar 2016 09:05:09 -0400

Perhaps what we really need is a configuration that recognizes the two
security requirements:

1) Defend ietf.org from DDoS attack
2) Provide access to Tor users.

The first requirement is at least as important as the first.

Sln1: If it is possible, perhaps the Cloudflare config could be set up
so that connections over Tor go to one particular server that is run
by IETF direct and not in the critical path.

Broken: You would have to have the site in the IETF server room and
where there is a site, there is a pipe and it is really the pipe that
is DDoSed.

Sln2: Can Cloudflare adjust their CAPTCHA scheme so that it only
queries users if an attack is actually in progress.

Question: Is this what they do already? Was the CAPTCHA showing up
because of a dumb blacklist or was it showing up because the IP was on
a blacklist AND that IP was currently performing a DDoS AND that DDoS
was aimed at ietf.org?

I suspect IETF use is atypical where Tor is concerned. Most sites
probably just want to shut Tor exit nodes out.

---

From: Alec Muffett <[email-masked]>
Date: Tue, 15 Mar 2016 13:20:59 +0000

On Mar 15, 2016, at 13:05, Phillip Hallam-Baker <[email-masked]<mailto:[email-masked]>> wrote:

Hi Phillip!

Yes, I actually think it's more simple even than you describe:

Question: Is this what they do already? Was the CAPTCHA showing up
because of a dumb blacklist or was it showing up because the IP was on
a blacklist AND that IP was currently performing a DDoS AND that DDoS
was aimed at ietf.org<http://ietf.org>?

Cloudflare recently posted this:

Why might a Tor visitor be blocked or challenged?

Due to the behavior of some individuals using the Tor network (spammers, distributors of malware, attackers, etc.), the IP addresses of Tor exit nodes may earn a bad reputation, elevating their CloudFlare threat score. Our basic protection level issues CAPTCHA-based challenges to visitors whose IP address has a high threat score, depending on the level chosen by the CloudFlare customer. The choices for security range from Essentially Off to I'm Under Attack. The default level is Medium.

What additional control do CloudFlare customers have over traffic from visitors using Tor?

Since late February 2016, CloudFlare treats Tor exit nodes as a "country" of their own. There's no geography associated with these IPs, but this approach lets CloudFlare customers override the default CloudFlare threat score to define the experience for their Tor visitors.

CloudFlare updates its list of Tor exit node IP addresses every 15 minutes.

Control is in the Access Rules section of the Firewall app.

If I read it/the rest of the post rightly, it appears that Cloudflare customers (IETF?) can nowadays flip a switch which whitelists Tor whilst still providing all the other protections that Cloudflare provide.

Basically it appears that all IETF need to do is decide whether people accessing the IETF website over Tor constitutes a threat, and modify control panel settings accordingly?

    -a

---

From: Alec Muffett <[email-masked]>
Date: Tue, 15 Mar 2016 13:11:46 +0000

Hi Eliot!

On Mar 15, 2016, at 12:58, Eliot Lear <[email-masked]<mailto:[email-masked]>> wrote:
Yes, but we at least can spot the C&C on the Internet.  See upthread about how hard that is with Tor.

I just want to round back and check that we're all discussing the same thing.

The thread so far seems to be regards "People who use Browsers over Tor have problems accessing IETF because CAPTCHA from IETF's Hosting Provider".

Elsewhere, other people have made clear arguments that perhaps this is an issue, because IETF broad participation and open access, and has written principles against surveillance.

My understanding is that you are making an argument that making life hard for people who access IETF's website over Tor is justified, because some DDoS botnets use Tor as command-and-control backhaul - which is not a unique situation, other botnets use IRC, or HTTP and some with SSL.

So, yes, sometimes Tor gets used by bad people to do bad stuff.  That much is correct, and is a criticism which can actually be thrown at HTTP or the Internet in general.

So - with this understanding - why pick on people who want to access the IETF over Tor?  Perhaps you wish to make some kind of moral stand against network protocols which are sometimes used to do bad things?

If so, why not start with TCP?

    -a

---

From: Leif Johansson <[email-masked]>
Date: Tue, 15 Mar 2016 14:40:01 +0100

Skickat från min iPhone

> 15 mars 2016 kl. 13:58 skrev Eliot Lear <[email-masked]>:
> 
> 
> 

Maybe if we didn't use quite so much encryption it would be even easier!

Or cloudflare could just implement RFC 3514 and we'd be protected that way.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Mar 2016 10:01:58 -0400

Jari Arkko <[email-masked]> wrote:
    > accessible to everyone. It is important that we at the IETF are able to
    > deal with DoS attacks.

These systems do not need to be the same system, do they?
I think we are talking about www.ietf.org, and not datatracker.

I think that most of www.ietf.org is static; that it could be rsync'ed, and
we could have instances (with different names) that aren't behind cloudflare
(but, which would be far more DDoS'able).

    > ietf.org is generally accessible to everyone in the usual way, but that
    > some blacklisted nodes will have to go through a CAPTCHA process before
    > being able to continue. Is this so, or is there an experience that says
    > nodes are blocked and there isn’t even a possibility to go through a
    > CAPTCHA? Or is the problem that there is a CAPTCHA but you do not feel
    > that it is done in a way that is appropriate? Does all this relate to
    > http or https traffic?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Mar 2016 10:04:22 -0400

Paul Wouters <[email-masked]> wrote:
    > Because some users under scrutiny of some nation states deem they need
    > to use tor for their privacy and safety for all their browsing. It
    > would be extremely dangerous to continuously switch tor off and on.

Right...+1..

so it's not that some need to access *IETF* via Tor, but that by
always using Tor, their accesses to IETF are part of the chaff that protects
their wheat.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 15 Mar 2016 15:13:37 +0100

> always using Tor, their accesses to IETF are part of the chaff that protects

Precisely so.  By providing the chaff we are making a moral decision to
help those who use Tor.  Have we done so consciously and is it the right
one?  That is my point.  I'd like to say I have the answer, but I
don't.  And the answer only matters if we are doing this solely for Tor
users.  I do think proponents should be able to answer the question.

Eliot

---

From: Randy Bush <[email-masked]>
Date: Tue, 15 Mar 2016 23:23:19 +0900

> The thread so far seems to be regards "People who use Browsers over
> Tor have problems accessing IETF because CAPTCHA from IETF's Hosting
> Provider".

i would add

   cloudflare breaking what should be end to end encryption opens the
   user to a mitm.  no, i am not saying cloudflare are bad folk.  but,
   for example, 
     o they could be served with a fisa order to see my traffic
     o they could be served with a fisa order to serve subtly different
       documents to queries from <name your favorite regime>
     o and all the other problems of having monkeys in the middle

   in these more privacy conscious days, we should be setting an example
   of how our own technology (and those of our friends in other sdos)
   can be used to maximize privacy and integrity.  client blocking,
   discrimination, and breaking e2e encryption are not what i consider
   nice examples.

my threat model for our data and services is much more about integrity
and privacy than availability.  i.e. i will put up with some degree of
ddos (after all i read this list:-) to be more assured that i am getting
an unaltered copy of rfc1925 and no one else knows i am reading it.

as with anything else, this point can be stretched to extremes that are
silly; no i probably will be unhappy with a one week outage.  but what
attacks have we actually experienced?  i know what we, a backbone isp,
get, and they're tens of g/s.  but does anyone throw gigs at
datatracker?

and another of my lives is as a measurement researcher.  so please spare
me "most of tor traffic is malicious" without citation, or the rfc
archive gets a 50g ddos every few weeks without actual measurement.

The plural of anecdote is not data.
-- Roger Brinner, economist
The plural of anecdote is not evidence.
-- Bill Lockyer, California Attorney General

randy

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 15 Mar 2016 14:25:15 +0000

On 15/03/16 14:13, Eliot Lear wrote:
> By providing the chaff 

We are not doing that. We are providing our usual web site is
all. That we need to turn off an additional control added by
CF is not the same as actively providing cover traffic.

> we are making a moral decision to
> one? 

I don't think we (the IETF) need to decide that. We need to
decide to re-level the field for exit nodes so that people
who access the IETF site via those hosts aren't discommoded.

Speaking personally, I'd answer your question with a yes, but
not on moral grounds, rather because Tor is one of the most
widely used privacy enhancing technologies; the IETF should
encourage use of such so that we learn how to make privacy
better on the Internet, so therefore we should, I think, be
actively encouraging its use so we learn more about it. I
don't think the IETF has established that as a consensus
position, but nor should we have to. It's fairly obvious I
reckon.

I'd also say yes on moral grounds as it happens, but one yes
should be enough for everyone except Molly Bloom:-)

Cheers,
S.

---

From: Tim Chown <[email-masked]>
Date: Tue, 15 Mar 2016 14:33:29 +0000

> On 15 Mar 2016, at 14:23, Randy Bush <[email-masked]> wrote:
> 

This.

> On 15 Mar 2016, at 14:25, Stephen Farrell <[email-masked]> wrote:
> 

And this.

Otherwise, it seems we have short memories.

Tim

---

From: "John Levine" <[email-masked]>
Date: 15 Mar 2016 14:59:25 -0000

>     o and all the other problems of having monkeys in the middle

AMS could be served with exactly the same orders.  I don't understand
what point you're making here, unless you want to move the entire IETF
infrastructure to some country with different access laws.

R's,
John

---

From: Michel Py <[email-masked]>
Date: Tue, 15 Mar 2016 16:25:56 +0000

> Alec Muffett wrote :
> I suspect IETF use is atypical where Tor is concerned. Most sites probably just want to shut Tor exit nodes out.

This is something that Tor has failed to realize. Unlike the IETF, many sites have no requirement or need to talk to people in another continent who need to hide their identity.

> why pick on people who want to access the IETF over Tor?

I don't think the IETF picks on people. The IETF tries to protect itself against a known and very active attack vector.

> Perhaps you wish to make some kind of moral stand against network protocols which are sometimes used to do bad things?

It's not sometimes, it's all the time.

> John R Levine wrote :
> For all its noble intentions, most of the traffic that comes out of Tor is malicious.

I would not go as far as saying "most of the traffic" (as it implies some volume) but "most of the exit nodes are engaged in some malicious activity".

> (Any service that is anonymous and free has the same problems.)  Cloudmark and other providers
> don't block or filter it for political reasons, they do so to protect their users.

True. I don't use Cloudmark but I essentially do the same.

Michel.

---

From: Leif Johansson <[email-masked]>
Date: Tue, 15 Mar 2016 18:11:05 +0100

> I would not go as far as saying "most of the traffic" (as it implies some volume) but "most of the exit nodes are engaged in some malicious activity".

Thats true to the same extent  that "the Internet is mostly about cat videos" is true and yet here we are working on it ... Personally I'm allergic to cats!

---

From: Michel Py <[email-masked]>
Date: Tue, 15 Mar 2016 17:55:27 +0000

>> Michel Py wrote :
>> I would not go as far as saying "most of the traffic" (as it implies some
>> volume) but "most of the exit nodes are engaged in some malicious activity".
> Leif Johansson wrote :
> Thats true to the same extent  that "the Internet is mostly about cat videos"

That is true to the extent that I counted myself several times and the last time I counted (this year) out of the known 1827 Tor exit nodes, 896 were marked as having "malicious" activities; it goes over the half mark on a regular basis. This data is not public (yet) but it will be soon, it's not based on Cloudflare data. I'm not the only one who has observed it either; there are reasons why both attack mitigation solution providers and end-networks filter and/or block Tor.

This is not guesswork.

Michel.

---

From: Alec Muffett <[email-masked]>
Date: Tue, 15 Mar 2016 18:07:33 +0000

> On Mar 15, 2016, at 17:55, Michel Py <[email-masked]> wrote:
> 

So, what percentage of the volume/outflow from those same proxies was "non-malicious"?

Surely you're making the mistake of categorizing the neighborhood, when you should be categorizing the people?

By comparison: what percentage of the world's SMTP is spam? What percentage of the world's HTTP is filesharing?

If you're not looking at the whole picture, you are making a "one bad apple" mistake - amplified, because Tor rotates their occasional bad apples around exit nodes just like everyone else.

    -a

---

From: Rich Kulawiec <[email-masked]>
Date: Tue, 15 Mar 2016 14:10:26 -0400

On Tue, Mar 15, 2016 at 08:20:45AM +0000, Jari Arkko wrote:
> nodes are blocked and there isn?t even a possibility to go through a

1. Not everyone uses a web browser (with a GUI) to access every website.
Some people use text-only browsers like lynx or w3m, because they have
small resource requirements, small(er) attack surfaces, they conserve
bandwidth, and especially for sites like the IETF's, they (should) suffice
nicely.

2. Not everyone uses a web browser to access every website.  Some folks
use wget or curl or similar tools, either to grab individual documents
of interest or perhaps to create local caches/mirrors.  For people
on low-bandwidth connections (or with time-limited access to high-bandwidth
connections) this is an effective way to build and retain a local stash
of items-of-interest.

Neither of these work well with captchas, Javascript, etc.

There should be *no* requirement to enable Javascript or deal with
captchas (which, and see my other message upthread about this, are a
laughably poor "defense" mechanism) or provide tracking data to third
parties, when all someone wants to do is snag a copy of an RFC or read
an email thread or otherwise avail themselves of most (if not all) IETF
resources.

---rsk

---

From: "John R Levine" <[email-masked]>
Date: 15 Mar 2016 14:12:03 -0400

> Surely you're making the mistake of categorizing the neighborhood, when you should be categorizing the people?

No, Cloudmark specifically said they block or filter Tor IPs because the 
IPs send them malicious traffic, not because they're Tor.

> By comparison: what percentage of the world's SMTP is spam? What percentage of the world's HTTP is filesharing?

About 90% of SMTP is spam.  SMTP from Tor nodes is so close to 100% that I 
don't know anyone who accepts mail from them.

R's,
John

---

From: Theodore V Faber <[email-masked]>
Date: Tue, 15 Mar 2016 18:42:45 +0000

On 3/15/16 11:12, John R Levine wrote:
> About 90% of SMTP is spam.  SMTP from Tor nodes is so close to 100%
> that I don't know anyone who accepts mail from them.

Um, 90% by weight or by volume?

More seriously what's the claim there: number of connections? Bytes?
Messages? Recipients?  (A possibility is that all of them are 90%, but
that seems unlikely to me and would be worh pointing out, too.)

Besides which 90% vs 100% doesn't seem very significant to me. Tor
nodes may send more absolute SMTP traffic, of course.  In that case it
seems like the volume and not the composition would be the telling marke
r.

- -- 
Ted Faber <[email-masked]>
Engineering Specialist
Computer Systems Research Department
310-336-7373

---

From: John Kristoff <[email-masked]>
Date: Tue, 15 Mar 2016 19:15:30 +0000

> Um, 90% by weight or by volume?

How many Tor exit nodes will deliver TCP destination port 25 traffic?
Almost none from what I can tell from the current database.  Port 25 is
disabled by default in Tor installations.

John

---

From: "John R Levine" <[email-masked]>
Date: 15 Mar 2016 15:32:43 -0400

> Um, 90% by weight or by volume?

About the same either way.

> that seems unlikely to me and would be worh pointing out, too.)

Really, it's about the same.  People have been collecting stats on this 
for upwards of a decade.  For more details, Google is your friend.

> Besides which 90% vs 100% doesn't seem very significant to me.

I gather you've never run a large mail system or talked to people who do. 
The 90% is an average over all sources.  Some sources like the IETF's mail 
system send about 0% spam, some like Tor and botnetted old Wordpress 
servers send 100%, others are in between.  To keep the load manageable, 
you reject mail from the very spammy sources and use your servers to 
filter what you accept.

There's a reason that every mail system of any size has a Spamhaus 
subscription.

R's,
John

---

From: Leif Johansson <[email-masked]>
Date: Tue, 15 Mar 2016 20:36:29 +0100

Skickat från min iPhone

> That is true to the extent that I counted myself several times and the last time I counted (this year) out of the known 1827 Tor exit nodes, 896 were marked as having "malicious" activities; it goe…

My point was that sometimes the good outweigh the bad anyway.

---

From: Randy Bush <[email-masked]>
Date: Wed, 16 Mar 2016 06:55:18 +0900

> always using Tor, their accesses to IETF are part of the chaff that
> protects their wheat.

it is not ours to judge what is someone's chaff or grain.

randy

---

From: Randy Bush <[email-masked]>
Date: Wed, 16 Mar 2016 06:59:07 +0900

> that I don't know anyone who accepts mail from them.

cite, please.

i accept mail from them.

wild unsubstantiated assertions do not aid reasoned discussion.

randy

---

From: <[email-masked]>
Date: Wed, 16 Mar 2016 03:50:01 +0000 (UTC)

> also say yes on moral grounds as it happens, but one yes 

It's a little far-fetched to expect those people familiar
with turgid, uninteresting, overlong, badly-written, misspelled
and ungrammatical internet-drafts to also be familiar with
Ulysses.
 Lloyd Wood [email-masked] http://about.me/lloydwood 

----- Original Message -----
From: Stephen Farrell <[email-masked]>
To: Eliot Lear <[email-masked]>; Michael Richardson <[email-masked]>; IETF Disgust List <[email-masked]>
Sent: Wednesday, 16 March 2016, 1:25
Subject: Re: ietf.org unaccessible for Tor users

Cheers,
S.

---

From: Leif Johansson <[email-masked]>
Date: Wed, 16 Mar 2016 07:18:00 +0100

Skickat från min iPhone

> Lloyd Wood [email-masked] http://about.me/lloydwood 

Its an Irish thing

---

From: Eliot Lear <[email-masked]>
Date: Wed, 16 Mar 2016 07:53:56 +0100

> it is not ours to judge what is someone's chaff or grain.

That's a moral cop out.

---

From: Randy Bush <[email-masked]>
Date: Wed, 16 Mar 2016 15:57:20 +0900

>> it is not ours to judge what is someone's chaff or grain.

whew!  i was worried there was no one here omniscient enough to tell us
what is right to see and what is wrong.  thanks!

---

From: Eliot Lear <[email-masked]>
Date: Wed, 16 Mar 2016 08:00:55 +0100

> what is right to see and what is wrong.  thanks!

I couldn't let you solely occupy that particular role.

---

From: Randy Bush <[email-masked]>
Date: Wed, 16 Mar 2016 16:06:34 +0900

>> whew!  i was worried there was no one here omniscient enough to tell
>> us what is right to see and what is wrong.  thanks!

let me try it with less irony and with simpler language.

it is not ours to say what others should and should not read, or to
which they should have easier access.  to do so is called censorship.

randy

---

From: Eliot Lear <[email-masked]>
Date: Wed, 16 Mar 2016 08:32:09 +0100

> which they should have easier access. to do so is called censorship.

Nobody's prohibiting access to any of our public documents.  And as
someone pointed out elsewhere, if one wants to copy every last bit of
IETF documentation, they are able to do so and provide whatever access
they wish.  To my knowledge nobody else has raised the concern that that
the Tor people are raising, and so we are being asked to specifically
support Tor.  Fine.  That means we then need to consider the
benefit/harm of our actions regarding who precisely we are helping.  I
asked that question honestly without an answer, but with concerns.

Eliot

---

From: <[email-masked]>
Date: Wed, 16 Mar 2016 07:36:51 +0000 (UTC)

The IETF is censoring gopher!
 Lloyd Wood [email-masked] http://about.me/lloydwood 

----- Original Message -----
From: Eliot Lear <[email-masked]>
To: Randy Bush <[email-masked]>
Cc: Michael Richardson <[email-masked]>; IETF Disgust List <[email-masked]>
Sent: Wednesday, 16 March 2016, 18:32
Subject: Re: ietf.org unaccessible for Tor users

Eliot

---

From: Warren Kumari <[email-masked]>
Date: Wed, 16 Mar 2016 08:27:48 +0000

[ Intentional top post ]
So, the original email (~65 messages ago!) raised the issue that ietf.org
wasn't accessible over Tor because of the CAPTCHA.

29 emails ago Alec Muffett posted:
https://mailarchive.ietf.org/arch/msg/ietf/mzh5xox0WGE4_KDeyJC0RpxTceY

This said that CloudFlare treats Tor as a country, and you can twiddle the
knob to whitelist / decrease the threat level assigned to the Tor
"country".

I haven't seen anything discussing this - while the current round of beard
pulling provides me with much entertainment, perhaps we could *also*
discuss twiddling the knob or, more productively, see if the folk
responsible for keeping this running know about the knob? Presumably it
could be twiddled until / unless the *IETF* actually sees pain from Tor?

W

---

From: Dave Cridland <[email-masked]>
Date: Wed, 16 Mar 2016 09:45:56 +0000

> could be twiddled until / unless the *IETF* actually sees pain from Tor?
That's a very sensible suggestion, and is therefore probably off topic for
this thread.

---

From: Leif Johansson <[email-masked]>
Date: Wed, 16 Mar 2016 10:49:34 +0100

On 2016-03-16 09:27, Warren Kumari wrote:
> I haven't seen anything discussing this - while the current round of
> beard pulling provides me with much entertainment, perhaps we could
> *also* discuss twiddling the knob or, more productively, see if the folk

+1

---

From: Rich Kulawiec <[email-masked]>
Date: Wed, 16 Mar 2016 06:46:38 -0400

> wild unsubstantiated assertions do not aid reasoned discussion.

Actually, John is spot-on with this one.  Comparison of statistics from
(a) a fair number of diverse production mail servers and (b) a large-ish
number of spamtraps over a period of many years does in fact show that
the percentage of spam from Tor nodes asymptotically approaches 100%.
(I have never bothered to rigorously analyze it because for my purposes
the difference between 98.94% and 99.31% is irrelevant.)

This of course is not equivalent to a statement that all of the SMTP
traffic from Tor nodes is spam.  There is some non-spam.  But for all
practical purposes, it's lost in the noise floor.

But to circle back around to where this started: whatever the percentage
is and however it fluctuates, it really doesn't matter to a web site that
speaks HTTP(S).

---rsk

---

From: Randy Bush <[email-masked]>
Date: Wed, 16 Mar 2016 20:44:44 +0900

> *also* discuss twiddling the knob or, more productively, see if the
> folk responsible for keeping this running know about the knob?
> Presumably it could be twiddled until / unless the *IETF* actually
> sees pain from Tor?

would be nice.  the op had a second issue. the cert masquerade opening a
mitm.

randy

---

From: Paul Wouters <[email-masked]>
Date: Wed, 16 Mar 2016 08:31:28 -0400

An internet where to survive on you need an third party anti-ddos service is pretty fundamentally wrong. As much as I love cloudfare, the fact that we need it is something we inside and outside the ietf, should address with haste.

Paul

Sent from my iPhone

> On Mar 16, 2016, at 03:32, Eliot Lear <[email-masked]> wrote:
> 
> 
>

---

From: Jari Arkko <[email-masked]>
Date: Wed, 16 Mar 2016 12:37:20 +0000

Warren is spot on. Not a surprise, of course :-)

The takeaway for me from this thread is problems with CAPTCHA’s, some situations where CAPTCHA’s don’t even appear, the tuning of various filters, and possible additional mirrors. I have asked the IETF tools and IT folks to take a look. This isn’t the only thing they are doing, so it will probably take some time to figure out what we can do. And they still must be able to deal with denial of service attacks from all over the Internet and not just Tor, and yes, the tools at our disposal will be imperfect, and yes, there will be some pain for some users as a result. They will do their best. Don’t expect miracles.

I would also like to ask that we not dwell deeply on the goodness or not of Tor or any other networks or systems for that matter. We’re not here to pass judgment, but of course we try to enable access to IETF resources as widely as we can.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 16 Mar 2016 12:55:26 +0000

I also wanted to address the question of “outside services”.

There are obviously various different technical arrangements. From one box to multiple boxes to clouds, load balancers, front-ends, own and shared networks, etc.

But I want to be clear that the IETF services do not run by themselves. There are real people and real costs involved in running the services. Arrangements differ, some services are run by volunteers (thank you!) and some under commercial arrangements that we explicitly contract and pay for. AMS, some data centre facilities, Cloudfare, and software developer companies, for instance. We have the ability to decide what we want, though obviously within some constraints of what is reasonably available and/or at what cost.

I think it is useful to discuss whether our technical arrangements should evolve somehow. But I don’t think we can get away from the fact that we’ll be using commercial services of one or other kind. I wouldn’t draw the line between inside and outside at the CDNs, for instance.

Jari

---

From: Rich Kulawiec <[email-masked]>
Date: Wed, 16 Mar 2016 14:03:00 -0400

On Wed, Mar 16, 2016 at 08:31:28AM -0400, Paul Wouters wrote:
> An internet where to survive on you need an third party anti-ddos
> service is pretty fundamentally wrong.

I strongly concur.

What's wrong is fairly easy to understand: DDoS attacks do not magically
fall out of the sky.  They come from systems, that are on networks, that
are run by people.  Those people (and the organizations they work for)
are responsible for their role in those attacks, but they are rarely,
if ever, held accountable for them.  There is thus no reason for them
to perform due diligence and/or to exhibit the competence and
professionalism required to make their operations cease being operational
hazards to the entire rest of the Internet.

Everyone worries about what's inbound; few worry about what's outbound.

And so now we all have to pay in cost and complexity for their negligence
(or in some cases, their willingness to look the other way in return for
profits).  The entire business model of these third party anti-DDoS
services is based on this unfortunate situation.  (Not that I'm putting
the blame on those services: they didn't create this problem.)

Even large operations with (for all practical purposes) unlimited
personnel and budgets are guilty of this.  E.g., two months ago,
Amazon was the #1 spamming network on this planet thanks to massive
and persistent infestation their cloud.  I'm at a loss to figure out
how that's even possible: who allowed *that* to happen on their watch?

Until people/operations are held accountable by their peers for
what they allow to escape their networks, this situation won't change.

---rsk

---

From: Adam Roach <[email-masked]>
Date: Wed, 16 Mar 2016 13:55:31 -0500

On 3/16/16 2:32 AM, Eliot Lear wrote:
> To my knowledge nobody else has raised the concern that that

It's a little off topic, but I'll bite. I'm only replying in the hope 
that we can get past the sidelong aspersions that imply that these users 
are somehow undeserving of access.

This FAQ gives information in a far more thoughtful and comprehensive 
way than I could have hoped to regarding the users who make use of the 
TOR network: https://www.torproject.org/about/torusers.html.en

One of the less obvious things, though, is that switching back and forth 
between Tor and normal browsing on the same machine opens you up to 
certain fingerprinting attacks (cf. 
https://www.w3.org/2001/tag/doc/unsanctioned-tracking/#limitations-of-technical-solutions). 
These attacks can allow determined adversaries to correlate your 
"regular" traffic with your Tor-routed traffic. These are mostly 
state-level actors, although some non-state institutions have 
demonstrated the ability to unmask Tor traffic using this class of 
technique.

So, in particular, the people you're blocking when you make Tor access 
impossible or difficult, are frequently going to be the ones who risk 
persecution, imprisonment, or death if they're discovered. Think human 
rights activists, citizen journalists, and anonymous whistleblowers in 
oppressive regimes. They're the ones who literally *cannot* afford to 
turn Tor off.

/a

---

From: Michael StJohns <[email-masked]>
Date: Wed, 16 Mar 2016 15:22:46 -0400

> I think it is useful to discuss whether our technical arrangements should evolve somehow. But I don’t think we can get away from the fact that we’ll be using commercial services of one or other kin…

To expand on this slightly.  There's a cost for pretty much everything 
we do/the IETF does/the IETF staff does/that needs to be done.  Someone 
has to foot the bill. In looking at the Tor question I would ask:  Can 
we make a reasonable accommodation for TOR at a minimal cost (in money, 
time, management) (i.e. what exactly will this do to the bottom line and 
the security of the system?) ?  If the costs are substantial/not 
trivial, WOULD the TOR users be willing to spend their own money to 
subsidize the access?   If not, SHOULD the IETF subsidize the access?

I may be misreading the thread, but it appears to be not so much that 
you can't access the IETF information through TOR because of the Captcha 
(caused by the TOR sites being on a blacklist/not being on a white 
list), but because those with the TOR browser don't want to allow the 
use of Javascript.  E.g. its not primarily a technical issue (which I 
would say that would get almost universal support to fix) exactly - but 
one of choice or philosophy with technical ramifications.

And lest anyone think I'm skimming over the whole reason for using Tor:  
One reductio ad absurdum  thing to do  (extreme pain) would be to 
require Captcha for *all* accesses to the IETF web pages - e.g. ignore 
the evaluation of perceived threat from the querying site and make all 
of us share in the pain.  The other one would be to remove Captcha for 
all.  I don't think either of these passes the smell test.

Later, Mike

ps - if there's a cost, and the IETF is expected to pay it, I'd much 
rather we/they spend the money on additional or improved assistive 
technologies to enable broader access to IETF content along these lines: 
http://www.internetsociety.org/doc/internet-accessibility-internet-use-persons-disabilities-moving-forward

---

From: Eliot Lear <[email-masked]>
Date: Wed, 16 Mar 2016 20:29:58 +0100

Adam,

As I've told others, if this were JUST about access, I wouldn't care. 
I'm quite confident that many criminals have read and used our specs. 
That's the price of free and open society.  We can't and shouldn't
control that.  But it's not just about access, for reasons previously
mentioned.  As to the moral argument, the moment it's more than access,
we become a party to this activity when we make an accommodation for
Tor.  And in case you missed it, I referenced several negative aspects
of the Tor network earlier, and I'm sure you could easily find plenty
more.  There was nothing sidelong about it.

Eliot

---

From: Adam Roach <[email-masked]>
Date: Wed, 16 Mar 2016 14:34:27 -0500

On 3/16/16 14:29, Eliot Lear wrote:
> And in case you missed it, I referenced several negative aspects
> more.

Sure. There are plenty of negative aspects of any technology. I'm making 
an assertion that we need to be aware that we're throwing the baby out 
with the bathwater when we take steps to block Tor (such as engaging 
CloudFlare's DDoS protection), while you seem to be willfully ignorant 
of the presence of the baby at all.

/a

---

From: Eliot Lear <[email-masked]>
Date: Wed, 16 Mar 2016 20:37:35 +0100

On 3/16/16 8:34 PM, Adam Roach wrote:
>
> Sure. There are plenty of negative aspects of any technology. I'm
> making an assertion that we need to be aware that we're throwing the
> baby out with the bathwater when we take steps to block Tor (such as
> engaging CloudFlare's DDoS protection), while you seem to be willfully
> ignorant of the presence of the baby at all.

It's not bathwater, but a cesspool, and I do not know just how much baby
was ever there.

---

From: Adam Roach <[email-masked]>
Date: Wed, 16 Mar 2016 14:47:02 -0500

> It's not bathwater, but a cesspool, and I do not know just how much baby

As is the nature of a service used by people who need to stay anonymous 
for their own safety, you're not going to find a lot in the way of data 
or anecdote here. However, there is a good, high-profile case with which 
you may have some passing familiarity:

" Snowden and Poitras quickly set up a more secure channel for 
communication. Poitras created an anonymous email account, doing so with 
the Tor Browser that masks your identity on the web, and she created a 
new GPG key, just for communicating with Citizenfour. This was advisable 
because, if she were under surveillance by the NSA or any other 
intelligence agency, they might have compromised her known accounts, and 
she would prefer for there to be no trace of her true name in the 
correspondence with this secrecy-seeking stranger."

(from https://theintercept.com/2014/10/28/smuggling-snowden-secrets/)

So... not zero?

/a

---

From: Michael StJohns <[email-masked]>
Date: Wed, 16 Mar 2016 16:23:38 -0400

On 3/16/2016 3:47 PM, Adam Roach wrote:
> As is the nature of a service used by people who need to stay 
> anonymous for their own safety,

There's the set of TOR users, and there's the subset of TOR users that 
need to have the property of "anonymity for safety",  and then there's 
the set of people who need/want access to the IETF.

Could you provide an educated guess on the size of the intersection of 
those last two sets?   1?  10s? 100s? 1000s?  More?   I'm trying to 
understand the amount of hyperbole being slung about.

Finally, are there any other methods  besides Tor you can think of that 
would give "anonymity for safety" while still providing access to the 
IETF data? (Hint: asking a friend to photocopy paper or send you a usb 
stick.... or...)

Later, Mike

---

From: Linus Nordberg <[email-masked]>
Date: Wed, 16 Mar 2016 21:25:02 +0100

Michel Py <[email-masked]> wrote
Tue, 15 Mar 2016 17:55:27 +0000:

| That is true to the extent that I counted myself several times and the
| last time I counted (this year) out of the known 1827 Tor exit nodes,
| 896 were marked as having "malicious" activities; it goes over the
| half mark on a regular basis. This data is not public (yet) but it
| will be soon, it's not based on Cloudflare data. I'm not the only one
| who has observed it either; there are reasons why both attack
| mitigation solution providers and end-networks filter and/or block
| Tor.
| 
| This is not guesswork.

What did you count and how? Let's start with the very easy part and see
if we should go further later: At what point in time did the Tor network
have 1827 exit relays? The Tor Metrics site [0] suggests that this has
never happened [1].

[0] https://metrics.torproject.org/
[1] https://metrics.torproject.org/relayflags.html?start=2008-01-01&end=2016-03-16&flag=Exit

---

From: Adam Roach <[email-masked]>
Date: Wed, 16 Mar 2016 15:30:16 -0500

> understand the amount of hyperbole being slung about.

I'm just going to put back the second half of the sentence that you cut 
off in your quote above: "you're not going to find a lot in the way of 
data or anecdote here."

> Finally, are there any other methods  besides Tor you can think of 
> that would give "anonymity for safety" while still providing access to 
> the IETF data? (Hint: asking a friend to photocopy paper or send you a 
> usb stick.... or...)

I propose you limit yourself to those methods of participation for a 
suitably long time period -- say, a year or so -- and then report back 
with your experiences of whether you think it posed an unreasonable barrier.

/a

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 16 Mar 2016 13:42:09 -0700

Michael StJohns wrote:
> There's the set of TOR users, and there's the subset of TOR users that need
> to have the property of "anonymity for safety",  and then there's the set of
> people who need/want access to the IETF.
> 
> would give "anonymity for safety" while still providing access to the IETF
> data? (Hint: asking a friend to photocopy paper or send you a usb stick....
> or...)

I don't have any answer to your question, but a belief that it could grow and shift over time as governments change. Nobody has addressed the question from Antonio Prado about setting up ietf.onion. I have never setup or used Tor, so I may be off base, but it would appear that the IETF could run a Tor router with a bandwidth-throttled exit policy that blocks all addresses except a mirror pointed to by the ietf.onion name. Basically a public hidden service.

Attackers could dos the throttle, but other than that, it would appear to remove the need for the worse-than-useless captcha while not opening up the IETF to abuse of the relay, and solve the access problem in the subject line. 

Tony

---

From: Rich Kulawiec <[email-masked]>
Date: Wed, 16 Mar 2016 16:35:10 -0400

On Wed, Mar 16, 2016 at 03:22:46PM -0400, Michael StJohns wrote:
> And lest anyone think I'm skimming over the whole reason for using
> Tor:  One reductio ad absurdum  thing to do  (extreme pain) would be
> to require Captcha for *all* accesses to the IETF web pages - e.g.
> ignore the evaluation of perceived threat from the querying site and
> make all of us share in the pain.  The other one would be to remove
> Captcha for all.  I don't think either of these passes the smell
> test.

Why not?  I've already pointed out (upthread, with references) that
captchas have no defensive value.  Zero.  None.  They're snake-oil.
Pretending that they will actually stop a modestly-determined,
modestly-resourced attacker is foolish.  *If* there is a need for
defensive measures, and if there is, I'd like to see that need qualified
and quantified, then fine: let's use some of the defensive mechanisms
that have been shown to work *and* which don't impede access by the
impaired/disabled, by Tor users, by those with Javascript turned off,
by those using alternate browsers or command-line programs, etc.

---rsk

---

From: Michael StJohns <[email-masked]>
Date: Wed, 16 Mar 2016 16:49:34 -0400

On 3/16/2016 4:30 PM, Adam Roach wrote:
>> There's the set of TOR users, and there's the subset of TOR users 
>> that need to have the property of "anonymity for safety", and then 
>> there's the set of people who need/want access to the IETF.
>>
>> Could you provide an educated guess on the size of the intersection 
>> of those last two sets?   1?  10s? 100s? 1000s? More?   I'm trying to 
> I'm just going to put back the second half of the sentence that you 
> cut off in your quote above: "you're not going to find a lot in the 
> way of data or anecdote here."

Fair enough - so you're asking me to take it on faith that there is a 
real problem and that it effects sufficient numbers of folks that the 
IETF should spend *its* money and effort to fix?    Which fix might in 
itself cause other problems affecting all the rest of us.

Let me ask it another way - what is the minimum number of  people that 
this affects before you think the IETF should spend its resources?  100? 
10? 1?   (Note - I'm asking for the case where the cost to provide the 
accommodation is non-trivial).

>> that would give "anonymity for safety" while still providing access 
>> to the IETF data? (Hint: asking a friend to photocopy paper or send 
>> you a usb stick.... or...)
>

I propose that at least one person with fear for their life if their 
anonymity is compromised who needs continuous access to the IETF for 
that same 1 year actually explain the problem in a non-anecdotal way.   
I'm still trying to wrap my head around an "I must not be caught" 
protocol designer.

Mike

---

From: Michel Py <[email-masked]>
Date: Wed, 16 Mar 2016 20:59:01 +0000

> Linus Nordberg wrote :
> What did you count and how? Let's start with the very easy part and see if we should go
> further later: At what point in time did the Tor network have 1827 exit relays?

Sometime January 3, 2016.

Right now, this file has 14997 lines which is 3 comment lines and 1494 entries; it is updated on a regular basis.
https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=8.8.8.8

# This is a list of all Tor exit nodes from the past 16 hours that can contact 8.8.8.8 on port 80 #
# You can update this list by visiting https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=8.8.8.8 #
# This file was generated on Wed Mar 16 20:04:27 UTC 2016 #
[..]

Michel.

---

From: Michel Py <[email-masked]>
Date: Wed, 16 Mar 2016 21:00:19 +0000

Sorry, fat fingers. Let's try again

Right now, this file has 1497 lines which is 3 comment lines and 1494 entries; it is updated on a regular basis.
https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=8.8.8.8

Michel.

---

From: John C Klensin <[email-masked]>
Date: Wed, 16 Mar 2016 17:26:29 -0400

--On Wednesday, March 16, 2016 13:42 -0700 Tony Hain
<[email-masked]> wrote:

> Michael StJohns wrote:
>...
>> Could you provide an educated guess on the size of the
>> intersection of those last two sets?   1?  10s? 100s? 1000s?
>> More?   I'm trying to understand the amount of hyperbole
>> being slung about.
>... 
> I have never setup or used Tor, so I may be off
> base, but it would appear that the IETF could run a Tor router
> with a bandwidth-throttled exit policy that blocks all
> addresses except a mirror pointed to by the ietf.onion name.
> Basically a public hidden service.
>...

Noting the above including the repeatedly-asked question of who
needs this and why the IETF should assume the costs and also
noting that we've discontinued mechanisms for accessing IETF
materials when too few people were using them (the RFC printing
and (postal) mailing service being only the most prominent
example), let me suggest something far more simple:   It has
been firm IETF policy for a very long time that there are no
restrictions on mirrors of IETF files and data and
redistribution of IETF mailing lists.  Assuming that the sum of
the number of people who want or need to access IETF materials
via TOR and the number of people who feel strongly about helping
the first group(s) protect themselves is non-trivial (from the
amount of impassioned discussion on the topic, we already know
that sum is not-zero), why don't those people simply set up an
appropriate mirror, establish whatever access mechanisms that
suit their needs and requirements, and go happily on their way?
That would avoid both the stresses on IETF services and staff
that concern Mike (and me) but also any disclosure to IETF
personnel about who was using the service and why -- disclosure
that, under the proposed privacy policy, might become public
information.

     john

---

From: Adam Roach <[email-masked]>
Date: Wed, 16 Mar 2016 16:31:24 -0500

> I'm still trying to wrap my head around an "I must not be caught" 

Admittedly it's not being done in the IETF, but I would think that a 
Russian working on bitcoin-related protocols would be justifiably 
concerned about their safety at the moment, given that Russia recently 
imposed a penalty of two years of jail time for simply using 
cryptocurrencies.

It's not terribly far-fetched to think that a similarly-minded regime 
might at some point in the not-to-distant future take a similarly dim 
view of working on security protocols in the IETF, such as PERC (or 
anything in the SEC area) -- backed up with similar consequences.

/a

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 16 Mar 2016 21:49:31 +0000

Mike,

On 16/03/16 20:49, Michael StJohns wrote:
> IETF should spend *its* money and effort to fix? 

Did you miss the mail upthread where it was pointed out that
removing the restriction is a simple checkbox which I assume
costs no more money than we're giving CF already?

If we allow Tor access and that turns out to be a source of
problems, then I do think we ought re-evaluate, but I don't
think there's any cost here to the IETF to turn off the
restriction.

And to clarify another thing: this is not only about the captcha,
in testing today using TBB sometimes one gets access, sometimes
one gets a captcha and sometimes access is denied with no captca.
It seems to depend on the exit node IP.

Cheers,
S.

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 16 Mar 2016 15:33:31 -0700

> I'm still trying to wrap my head around an "I must not be caught"

Funny, but I thought the target of the documents was "implementers". While
it is easy to look around an IETF meeting and start to believe that the
documents are "by and for protocol designers", that should not be the case.
It should also not be hard to believe in an "I must not be caught"
implementer an app that used IPsec. 

John C Klensin wrote:
...
> 
> Noting the above including the repeatedly-asked question of who needs
> this and why the IETF should assume the costs and also noting that we've
> discontinued mechanisms for accessing IETF materials when too few people
> were using them 

The flip side of that is that having a Tor router implemented as suggested
would provide the appropriate count of how much it gets used.

(the RFC printing and (postal) mailing service being only
> the most prominent
> been firm IETF policy for a very long time that there are no restrictions
on
> mirrors of IETF files and data and redistribution of IETF mailing lists.

True, but that in itself constitutes an attack vector. If someone wanted to
subvert anyone that was trying to use Tor to access the IETF documents, the
easiest thing to do would be to create the proposed mirror, but make subtle
and incompatible changes to the documents so that any implementation based
on them would fail. If the implementer had no way to reference the correct
documents without exposing themselves, they would never know there was a
change.

> Assuming that the sum of the number of people who want or need to access
> IETF materials via TOR and the number of people who feel strongly about
> helping the first group(s) protect themselves is non-trivial (from the
> amount of impassioned discussion on the topic, we already know that sum
> is not-zero), why don't those people simply set up an appropriate mirror,
> establish whatever access mechanisms that suit their needs and
> requirements, and go happily on their way?

I would argue that the community of implementers that believed they need Tor
access would be better served by knowing the documents came from the 'source
of truth' on the matter, and that any future questions about usage quantity
would be easy to answer. 

> That would avoid both the stresses on IETF services and staff that concern
> Mike (and me) but also any disclosure to IETF personnel about who was
> using the service and why -- disclosure that, under the proposed privacy
> policy, might become public information.

While I agree that this is likely best set up, tested, and well documented
by 'motivated volunteers', I don't believe that pushing the entire operation
out the door is the correct response. If the privacy policy would disclose
who and why this was being used, it probably needs tuning up anyway. The
only thing that should be exposed about an explicitly 'anonymous access
path' is the count of users. Disclosing where, why, or what, would only
serve to curtail usage as a means to justify shutting it down. That said,
there would likely need to be policy about who has access to the information
that the Tor node knows, to avoid accidental release of information.

Tony

---

From: Michael StJohns <[email-masked]>
Date: Wed, 16 Mar 2016 21:20:52 -0400

> implementer an app that used IPsec.

There are  "participators" (or protocol designers) who would be expected 
to go back time and again to the IETF website to grab new stuff 
(internet drafts etc), and possibly contribute, and there "implementers" 
who are usually coming after the fact and grabbing the final document 
for implementation.  It's generally not cost effective - unless you're 
very involved in the design process - to implement the internet draft 
flavor of the week.  I think of the IETF website primarily serving the 
first group with access to the second group kind of a happy accident.  
(I'm not quite as flip about it as that, but keep in mind the target 
audience of the ID's and all of the cruft that goes with moving them 
through the standards process vs the target audience of RFC's).

So my point was more about there being lots of sources for finished 
documents (RFCs) that aren't the IETF (google Request for comments 
mirror) where someone with a Tor browser can just grab those without the 
IETF doing anything.   There are also plenty of ways for others to make 
mirrors of IETF content that don't involve intercession by the IETF 
staff (you've mentioned setting up a TOR public hidden service - I'd 
suggest that its better to have a Tor'ite do it that the IETF) - and 
many have done so.

WRT to your example - its really "implementer that built an app that 
used IPSec for something that broke some law somewhere".  It's not 
generally the IPSec per se that's a violation (or for that matter any of 
the IETF protocols), but what they get used for.  And even then, he's 
more likely to be grabbing one of the open source packages that 
implement the IETFs protocols than implementing something himself.

I mostly get where you're coming from - but I'm finding it hard to 
believe that the size of the intersection of "Tor users", "safety via 
anonymity required users" and "IETF participants" is very large - if it 
contains any elements at all.

What I've asked for is for data on the size of the problems - and what 
I've been told is that no data is to be had.  I'm OK with that, but that 
turns statements about why things are needed from objectively 
evaluatable proposals into subjective positions where either side might 
have all or part of the truth.   Or put another way, turns good factual 
arguments which I can evaluate into simple opinions which each of us 
will take with a different grain of salt.

---

From: Michael StJohns <[email-masked]>
Date: Wed, 16 Mar 2016 21:41:32 -0400

> costs no more money than we're giving CF already?

I didn't miss that.  Did you miss that turning it off may allow 
malicious traffic?  That malicious traffic may have a cost?  Or that 
this isn't targeted specifically against TOR, but against any site with 
a sufficiently bad reputation? Or that many TOR sites have a bad 
reputation?  My guess is that you didn't miss any of this, but I 
repeated it just in case.

That said, I think your next paragraph is a reasonable way forward. But 
that I do think there will be a cost to turn it off because someone will 
have to monitor and evaluate (and possibly remediate) if there is a 
problem.

To be clear, are you arguing for turning off Captcha in in 
circumstances?  Or just giving TOR a pass?  Can we leave it on for 
anything that requires an IETF login?

> It seems to depend on the exit node IP.
As I understand it, CF scores IP addresses based on reported "badness".  
If you're on TOR and you pick (or have picked for you) an exit router 
that's got a high badness score, then you get a Captcha at the IETF (and 
other CF sites).  My understanding is that if you come from non Tor 
sites with high badness scores you will also get a Captcha.  The 
specific problem( for us)/benefit(for the TOR users) is that you can't 
differentiate from the good TOR connections (if any) vs the bad TOR 
connections coming from the same tor exit router.  Captcha is there to 
try and establish there is some sort of human behind the connection and 
to provide some protection against automated attacks.

What's interesting about your comment is that there is enough 
differentiation in TOR output that different nodes score differently at 
CF.  It suggests to me that TOR may not be cleaning up it's fingerprints 
as well as it would like.

Later, Mike

---

From: Randy Bush <[email-masked]>
Date: Thu, 17 Mar 2016 11:03:44 +0900

> costs no more money than we're giving CF already?

they added this a few weeks back.  very cool.  thanks to warren for
actually checking again.

randy

---

From: Warren Kumari <[email-masked]>
Date: Thu, 17 Mar 2016 02:19:57 +0000

... and now that we have finally reached centithread status, I think we
need to address the core question on censorship and the use of Tor for
malicious or dissident / free speech - if the Internet and Tor were
available 75 years ago, would Hitler have tried blocking access to it?

W

---

From: Leif Johansson <[email-masked]>
Date: Thu, 17 Mar 2016 07:23:50 +0100

Skickat från min iPhone

> 16 mars 2016 kl. 22:49 skrev Stephen Farrell <[email-masked]>:
> 
> 
> Mike,
> 

Sorry Stephen - coming up with rational & simple proposals has already been ruled OT in this thread.

---

From: Leif Johansson <[email-masked]>
Date: Thu, 17 Mar 2016 08:27:25 +0100

> will take with a different grain of salt.

I have an idea: instead of a CAPTCHA, can't we get CF to implement
"proove that you are an IETFer" test that requires you to dive into
an inane thread on the IETF list and identify the precise point where
it jumped the shark.

---

From: Stefan Winter <[email-masked]>
Date: Thu, 17 Mar 2016 08:59:31 +0100

Hi,

> The takeaway for me from this thread is problems with CAPTCHA’s, some situations where CAPTCHA’s don’t even appear, the tuning of various filters, and possible additional mirrors. I have asked the…

The takeaway for me is that the end-to-end principle is dead. The times
where all intelligence should be in end hosts only, no middleboxes, and
KISS have gone, and techniques going in the opposite direction are not
only in use, but even embraced by IETF operations.

We are discussing only how to tweak middleboxes to be better; rather
than discussing how best to get rid of middleboxes.

I believe this is actually a bad thing in a wider view: the IETF
advocates the use of encryption everywhere; and at the same time we see
that those wonderful middleboxes have a problem with encryption and
generate MITM like situations. Yet, we continue to use them.

There's a bit of a contradiction in here.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

---

From: Stefan Winter <[email-masked]>
Date: Thu, 17 Mar 2016 11:12:12 +0100

Hi,

> But the fact that these solutions exist points to a need unmet by existing e2e approaches. Someone in IETF operations had presumably thought out their requirements when this service was procured. Embedding e2e within a solution that satisfies those same operational requirements sounds like a potential IETF WG charter in the making.

I'm sure that the situation as it is now is the result of planning; this
solution satisfies a need.

For the IETF as an SDO, this should be a lesson learnt then: we keep
developing protocols for an end-to-end world. The world out there is not
end-to-end though. (*)

And then people in the IETF wonder why the IETF is becoming more and
more irrelevant to the world out there.

It might be time to admit that end-to-end is not the one noble thing to
aspire to; but instead to accept deployed reality and develop protocols
which are of relevance in the presence of proxies, load-balancers, and more.

Is that a job for "just" a working group? I don't know; it more feels
like a cross-cutting job for the entire organisation.

Greetings,

Stefan Winter

(*) Since we all love anecdotes: I remember a Minneapolis IETF when a
bar BOF had the topic of "proxy threats" which aimed to create a
document stating why proxies (be it web, RADIUS, ...) are evil and
should be avoided. Fast forward to this discussion here, and I have to
wonder when exactly I slipped into this parallel universe.

> 
> Josh.
> 
> Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
> 
> Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.  
> 

Tel: +352 424409 1
Fax: +352 422473

---

From: "Varma, Eve (Nokia - US)" <[email-masked]>
Date: Thu, 17 Mar 2016 10:19:05 +0000

Hi,

This brings to mind the Aug. 2000 paper, "Rethinking the design of the Internet: The end to end arguments vs. the brave new world" (D. D. Clark, M. Blumenthal).

Best regards,
Eve

-----Original Message-----
From: ietf [mailto:[email-masked]] On Behalf Of EXT Stefan Winter
Sent: Thursday, March 17, 2016 6:12 AM
To: Josh Howlett; [email-masked]
Subject: Re: ietf.org end-to-end principle

Hi,

> But the fact that these solutions exist points to a need unmet by existing e2e approaches. Someone in IETF operations had presumably thought out their requirements when this service was procured. E…

I'm sure that the situation as it is now is the result of planning; this solution satisfies a need.

For the IETF as an SDO, this should be a lesson learnt then: we keep developing protocols for an end-to-end world. The world out there is not end-to-end though. (*)

And then people in the IETF wonder why the IETF is becoming more and more irrelevant to the world out there.

It might be time to admit that end-to-end is not the one noble thing to aspire to; but instead to accept deployed reality and develop protocols which are of relevance in the presence of proxies, load-balancers, and more.

Is that a job for "just" a working group? I don't know; it more feels like a cross-cutting job for the entire organisation.

Greetings,

Stefan Winter

(*) Since we all love anecdotes: I remember a Minneapolis IETF when a bar BOF had the topic of "proxy threats" which aimed to create a document stating why proxies (be it web, RADIUS, ...) are evil and should be avoided. Fast forward to this discussion here, and I have to wonder when exactly I slipped into this parallel universe.

--
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Thu, 17 Mar 2016 10:31:12 +0000

Hi,

For quite a while I have been asking whoever was willing to pay attention whether the good-ole e2e principle is no longer applicable, and we should start to formulate something like a c2c (where c would stand for “cloud”) or similar principle, and think about how to preserve the desired properties of Internet communication in its context.

Be goode,

On 17 Mar 2016, at 11:19 , Varma, Eve (Nokia - US) <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Best regards,
Eve

-----Original Message-----
From: ietf [mailto:[email-masked]] On Behalf Of EXT Stefan Winter
Sent: Thursday, March 17, 2016 6:12 AM
To: Josh Howlett; [email-masked]<mailto:[email-masked]>
Subject: Re: ietf.org<http://ietf.org> end-to-end principle

Hi,

Greetings,

Stefan Winter

Josh.

Tel: +352 424409 1
Fax: +352 422473

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 17 Mar 2016 10:38:00 +0000

On 17/03/16 10:31, DIEGO LOPEZ GARCIA wrote:
>  whether the good-ole e2e principle is no longer applicable

I always think of it as the end to end argument, not principle,
and from that perspective, I think it remains entirely applicable.

S.

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Thu, 17 Mar 2016 10:40:04 +0000

Hmmm… Shall I rephrase it as how to apply the end to end argument in the context of current mostly cloud-based interactions?

On 17 Mar 2016, at 11:38 , Stephen Farrell <[email-masked]<mailto:[email-masked]>> wrote:

S.

Dr Diego R. Lopez
Telefonica I+D

---

From: Linus Nordberg <[email-masked]>
Date: Thu, 17 Mar 2016 12:11:45 +0100

Michael StJohns <[email-masked]> wrote
Wed, 16 Mar 2016 21:20:52 -0400:

| I mostly get where you're coming from - but I'm finding it hard to
| believe that the size of the intersection of "Tor users", "safety via
| anonymity required users" and "IETF participants" is very large - if
| it contains any elements at all.

For many priviliged internet users it's not about not getting caught
because they are doing something illegal in their jurisdiction. It's
about providing as little material as possible for the profiles on their
person. Or protecting the host security of their workstation. Or simply
practicing their right to freedom of information without authenticating
themselves on layer three.

If the size of the intersection of "people who protect themselves" and
"IETF participants" is low, let's make it larger! We should start by
removing any obstacles for accessing IETF sites over Tor.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 17 Mar 2016 12:23:31 +0000

Stefan,

This is a really interesting discussion, and probably worthwhile for our perception of where the Internet is headed.

But, before we draw too many conclusions, may I ask what constitutes an end-to-end solution in this space, and what does not? I may be dense today, but it isn’t necessarily clear for me.

Which ones of the following practices are not end-to-end:

* a mirror
* a server that implements some (possibly dynamic) rules on what connection attempts are honoured
* collaboration between the routing system and servers on controlling dos attacks
* a server that has login or captcha procedures, run on the server
* a server that login or captcha procedures, but they are implemented on a different entity where traffic is redirected as needed
* a server that is duplicated or copied in multiple instances
* server(s) residing on an any cast address
* arrangements where DNS or other mechanisms are used to distribute requests to the most suitable or geographically local point
* a server whose function is distributed to a number of nodes (such as a load balancer in front)
* arrangements where the server is run by a contracted party
* the concept of a CDN

(My quick reaction to all of the above is that these are still arrangements that are in the hands of the party that serves information; the emergence of these practices in the Internet is more about the scale of the services than about inserting NAT- or firewall like other parties on a path. But I could be wrong...)

Jari

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 17 Mar 2016 09:03:26 -0400

> and from that perspective, I think it remains entirely applicable.

Exactly. And the end to end argument is entirely about the decisions
you make about placing complexity.

What has not changed in 30 years is that the Inter-Network remains an
area where complexity is to be avoided. If you are working at the
packet layer, the end-to-end principle is unchanged.

Above the packet layer, the end-to-end principle was never absolute
and it can't be. A given bilateral communication can only be initiated
by one party which means the other has to be the responder. It is not
possible for an initiator to communicate directly with an initiator.
The only way such a communication can be established is if they both
talk to an intermediary that can act as a responder for both.

If you look at the design of SMTP, you will see this architecture has
been in place for 30-odd years. And it is in Jabber and pretty much
every other 'peer to peer' scheme.

In every protocol, we try to reduce complexity wherever we can. But
there is always a minimum that can't be reduced except at cost to
functionality or performance or creating complexity elsewhere.

If you read the end-to-end paper you will find arguments against
putting that complexity at the ends as well as the network core. In
many but not all cases, a middlebox is exactly where it should go.

---

From: Stefan Winter <[email-masked]>
Date: Thu, 17 Mar 2016 15:56:53 +0100

Hi,

> But, before we draw too many conclusions, may I ask what constitutes an end-to-end solution in this space, and what does not? I may be dense today, but it isn’t necessarily clear for me.

Well we'd first have to define what an "end" is :-)

As I read your list, I realised that pretty much any of those can be
called end-to-end - or not, depending on what an end is for you.

If the "end" is one particular host on the internet, mirrors are "many
ends" already.

That is either a concern or not, depending on whether the ends are all
controlled by one entity (so that it can guarantee content
synchronisation among them all) or by independent third parties.

Mirrors run by the same entity are all alike; it doesn't matter which
one you connect to.

Mirrors run independently are different, because they are controlled by
different entities and can be subject to manipulations.
FTP mirrors have realised that a long time ago, and repos typically
carry extra metadata to prevent de-syncronisation: package signatures,
MD5sums on a different host for manual verification, ...

At that point, something on the application layer is starting to work
around the fact that "the" end is actually just "one out of many" ends.

For "servers which are duplicated" and load balancers the same reasoning
applies. As soon as some of the ends are different from others, problems
start to arise if one needs to identify which end exactly one is talking to.

In the examples where you talk about "a server" which does various
things, that looks like a single end to me. The fact that it may load
remote content from other sites is just HTML&friends.

In fact, the browser world is very much used to the fact that a website
is not an end; it's a collection of many ends, glued together to form a
cohesive appearance. And I guess all of us know the complexities around
that concept: mixed content, cross-site scripting, unability of end
users to identify the actual source... and yet, it works (somewhat,
depending on your personal definition of "works"). And if it is
well-known and works on the application layer, maybe we shouldn't
despise on it on the lower layers. Yes, we'll have to bite the bullet of
much more complexity than we currently are comfortable with.

The thing is: it's not like we have much choice.

"NAT is evil, there shall not be NAT!" said the IETF.
"Oh really?" said the NAT steam roller as he rolled over a pile of RFCs.

CDN steam rollers are following suit :-)

> (My quick reaction to all of the above is that these are still arrangements that are in the hands of the party that serves information; the emergence of these practices in the Internet is more abou…

Scale is about making something big. CDNs make things... different (and
enable making it big in the process). The difference shows at some spots
(TLS) but not others.

My definition of an end is probably (but this really needs much
thinking) that "one end" is something that is controlled by one entity
(for somethings on any layer; IP hosts, HTML web pages, ...). As you
distribute control to more than one entity, you create multiple ends. If
you then need to identify one particular end out of the set for some
reason, things can get complicated.

I hope that the above actually holds water on many layers. Applying it
to anycast addresses feels ok: anycasting is nice if the entire set of
servers is under central control. If it's not, and one host out of the
set starts giving strange answers, or routing to one instance goes bad,
identifying the problem can become mighty complicated.

If I'm talking rubbish, sorry for stealing everyone's time :-)

Greetings,

Stefan

Tel: +352 424409 1
Fax: +352 422473

---

From: Josh Howlett <[email-masked]>
Date: Thu, 17 Mar 2016 09:50:22 +0000

> where all intelligence should be in end hosts only, no middleboxes, and KISS
> have gone, and techniques going in the opposite direction are not only in
> use, but even embraced by IETF operations.

+1

Josh.

---

From: Josh Howlett <[email-masked]>
Date: Thu, 17 Mar 2016 11:33:59 +0000

Hi,

> It might be time to admit that end-to-end is not the one noble thing to aspire
> to; but instead to accept deployed reality and develop protocols which are of
> relevance in the presence of proxies, load-balancers, and more.

I don't personally see the case for e2e as one of nobility; its primarily an economic one. E2e places the cost of interoperability on the ends, where it belongs. These are the entities benefiting from the interoperation and so they should rightly bear the cost of that. When we break e2e we can reduce the cost of interoperability for some ends, but at the expense of others; either directly, or indirectly through the loss of utility, such as security as we're discussing in this instance. Like pollution that blows downwind from a factory, this transfer of costs to other actors is what economists call an negative externality. The cost of managing the system as a whole will tend to increase, its utility will tend to diminish, and eventually we end up with a lifeless pond.

We're not going to stop people from trying to find creative ways of making money from non-e2e solutions. Instead, we should focus on reducing the market opportunity by making it cheaper to do the right things, and having pragmatic solutions ready. I definitely don't think we should walk away from e2e; the Red Queen is running fast enough already.

Josh.

---

From: Melinda Shore <[email-masked]>
Date: Thu, 17 Mar 2016 09:20:14 -0800

> and from that perspective, I think it remains entirely applicable.

Yes, I do as well, but the IETF has not always responded
pragmatically to the ways networks are being deployed today
(and "cloud to cloud" isn't the issue).  During the 90s,
ideological purity on the part of a number of participants
and at least one IESG member prevented us from responding
well to the NAT situation.

But here's a problem: ideological purity and adherence to
good design principles tend to look like one another and I'm
not sure that it's always possible to tell one from another
except in hindsight.  Another problem is that sometimes the
"right" way to solve a problem, at least within our framework,
doesn't work well with network operators' business models.

I do think that one way to start to address some of this is
to reshape the way the organization is structured so being in
a leadership role (that is to say, the ones most likely
to be in position to block publication of a document they don't
like and to charter new work) isn't a full-time job, so that
people whose actual job it is to build networks, talk to
customers, and so on are able to step into those positions.  I
don't think that will fix the problem but I think it would be
an incremental improvement.

Melinda

---

From: joel jaeggli <[email-masked]>
Date: Thu, 17 Mar 2016 10:48:22 -0700

On 3/17/16 2:50 AM, Josh Howlett wrote:
>> The takeaway for me is that the end-to-end principle is dead. The
>> times where all intelligence should be in end hosts only, no
>> middleboxes, and KISS have gone, and techniques going in the
>> opposite direction are not only in use, but even embraced by IETF
>> operations.
> 
> +1
> 
> But the fact that these solutions exist points to a need unmet by
> existing e2e approaches. Someone in IETF operations had presumably
> thought out their requirements when this service was procured.
> Embedding e2e within a solution that satisfies those same operational
> requirements sounds like a potential IETF WG charter in the making.

I'm  not really sure what you folks are talking about anymore. A CDN
whether internal or a third party is an extension of the applications
stack, not a bump in the wire.

building scalable performant low latency services is a distributed
systems problem and there are a number of areas of the ietf activity
(all of them probably) involved in doing.

> Josh.
> 
> Jisc is a registered charity (number 1149740) and a company limited
> by guarantee which is registered in England under Company No.
> 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One
> Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
> 
> Jisc Services Limited is a wholly owned Jisc subsidiary and a company
> limited by guarantee which is registered in England under company
> number 2881024, VAT number GB 197 0632 86. The registered office is:
> One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.
> 
>

---

From: Eliot Lear <[email-masked]>
Date: Thu, 17 Mar 2016 22:45:12 +0100

On 3/17/16 6:20 PM, Melinda Shore wrote:
> (and "cloud to cloud" isn't the issue).  

I started thinking it was an argument, and then John Wroclawski
forcefully corrected me.  My view these days is that it is an efficiency
principle.  It's not that nothing happens in the middle, but rather that
things must go where they are most efficiently deployed from a systemic
perspective.  Where is it necessary to implement something in the
middle, such as perhaps an IGP or a BGP, there's nothing wrong with
that.  Similarly, DDOS protection is best done as close to the source. 
If that's the network, so long as it doesn't cause other failures,
great.  NAT has survived because by and large it hasn't so seriously
harmed end to end that the network couldn't be useful.  Though it
certainly has broken its fair share.  I think pseudo-SMTP aware firewall
may have done as much damage.

I view the Tor case as interesting because they're a bit of a hybrid. 
There's a bit of application and a bit of network.  The exit-node is
semantically aware of JSON but strips it out.  Interesting case study.

Eliot

> During the 90s,

---

From: <[email-masked]>
Date: Fri, 18 Mar 2016 01:27:12 +0000 (UTC)

> I don't personally see the case for e2e as one of nobility; its primarily an economic one.

Really?

The end-to-end papers are clear in presenting arguments about ensuring system reliability, and the
related performance considerations for that.

L.

when someone says 'rightly bear the cost,' look for a rent-seeker.
 Lloyd Wood [email-masked] http://about.me/lloydwood 

----- Original Message -----
From: Josh Howlett <[email-masked]>
To: Stefan Winter <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Thursday, 17 March 2016, 22:33
Subject: RE: ietf.org end-to-end principle

Hi,

Josh.

---

From: Leif Johansson <[email-masked]>
Date: Fri, 18 Mar 2016 08:58:02 +0100

> (all of them probably) involved in doing.

very true

---

From: Josh Howlett <[email-masked]>
Date: Fri, 18 Mar 2016 10:27:26 +0000

> >  E2e places the cost of interoperability on the ends, where it belongs.
> 
> The basic principle (it's NOT an argument) is that functions should go where
> they most efficiently belong.

Yes. I think that's a fine restatement in terms of architectural optimisation. Personally I prefer to think about this in terms of costs, because it's all too easy to conflate "efficient" with "cost effective". There is often a correlation, but not always, and of course it is the latter that actually drives procurement and so deployment.

(The actor bearing the cost isn't necessarily the one performing the architectural function. I pay my ISP to run BGP; in principal I could make alternative arrangements myself that could yield greater efficiency, but it would be wildly less cost effective).
 
A corollary to this is that designing successfully for systemic efficiency is really hard if you don't understand how the costs will be bourn throughout the system.

Josh.

---

From: joel jaeggli <[email-masked]>
Date: Sat, 19 Mar 2016 09:04:37 -0700

On 3/17/16 3:40 AM, DIEGO LOPEZ GARCIA wrote:
> Hmmm… Shall I rephrase it as how to apply the end to end argument in
> the context of current mostly cloud-based interactions? 

You seem to have a implicit but unstated assumption that an application
or service exists in one and only one place.
>
>> On 17 Mar 2016, at 11:38 , Stephen Farrell <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>
>>
> ------------------------------------------------------------------------
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su
> destinatario, puede contener información privilegiada o confidencial y
> es para uso exclusivo de la persona o entidad de destino. Si no es
> usted. el destinatario indicado, queda notificado de que la lectura,
> utilización, divulgación y/o copia sin autorización puede estar
> prohibida en virtud de la legislación vigente. Si ha recibido este
> mensaje por error, le rogamos que nos lo comunique inmediatamente por
> esta misma vía y proceda a su destrucción.
>
> The information contained in this transmission is privileged and
> confidential information intended only for the use of the individual
> or entity named above. If the reader of this message is not the
> intended recipient, you are hereby notified that any dissemination,
> distribution or copying of this communication is strictly prohibited.
> If you have received this transmission in error, do not read it.
> Please immediately reply to the sender that you have received this
> communication in error and then delete it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu
> destinatário, pode conter informação privilegiada ou confidencial e é
> para uso exclusivo da pessoa ou entidade de destino. Se não é vossa
> senhoria o destinatário indicado, fica notificado de que a leitura,
> utilização, divulgação e/ou cópia sem autorização pode estar proibida
> em virtude da legislação vigente. Se recebeu esta mensagem por erro,
> rogamos-lhe que nos o comunique imediatamente por esta mesma via e
> proceda a sua destruição

---

From: Dave Crocker <[email-masked]>
Date: Sat, 19 Mar 2016 12:51:49 -0700

> an incremental improvement.

There have been a number of arguments raised, in favor of reducing the 
amount of time needed to perform various I* tasks, and especially that 
of area director.  But while 'diversity' and 'size of the pool of 
candidates' have often been mentioned, I don't recall previously seeing 
the above point made, nevermind highlighted.  And highlighted it should 
be...

I think Melinda's suggestion that we would get more leaders who are 
directly responsible for delivering technology and products and 
services, rather than merely being adjuncts to such efforts, is 
remarkably well-taken.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Jari Arkko <[email-masked]>
Date: Mon, 21 Mar 2016 01:04:43 +0200

> There have been a number of arguments raised, in favor of reducing the amount of time needed to perform various I* tasks, and especially that of area director.  But while 'diversity' and 'size of the pool of candidates' have often been mentioned, I don't recall previously seeing the above point made, nevermind highlighted.  And highlighted it should be...
> 
> I think Melinda's suggestion that we would get more leaders who are directly responsible for delivering technology and products and services, rather than merely being adjuncts to such efforts, is remarkably well-taken.

That has certainly been the general thinking in the IESG. Leadership that is connected to day-to-day networking work will be more connected with real-world realities, priorities (besides being easier to recruit and can more easily fund their activities).

(But cutting tasks is difficult, it is more of a culture of what ADs feel they must do; some ADs are able to combine significant day job efforts with the task, successfully, however.)

Jari

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Sun, 20 Mar 2016 23:13:04 +0000

On 19 Mar 2016, at 17:04 , joel jaeggli <[email-masked]<mailto:[email-masked]>> wrote:

Not at all. That’s precisely the point. Applications (at both ends) can exist in a distributed or simultaneous way, while many of the terms in which e2e is expressed imply these single instances.

Dr Diego R. Lopez
Telefonica I+D

---

From: Hui Deng <[email-masked]>
Date: Tue, 22 Mar 2016 09:36:45 +0800

even it has multiple/distributed instance within the cloud, it still counted as one end.
DENG HuiFrom: [email-masked]
To: [email-masked]
Subject: Re: ietf.org end-to-end principle
Date: Sun, 20 Mar 2016 23:13:04 +0000
CC: [email-masked]; [email-masked]

On 19 Mar 2016, at 17:04 , joel jaeggli <[email-masked]> wrote:

--

Dr Diego R. Lopez

Telefonica I+D

Tel:    +34 913 129 041

Mobile: +34 682 051 091

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la
 lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination,
 distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a
 leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Joe Touch <[email-masked]>
Date: Tue, 22 Mar 2016 12:15:36 -0700

>> they most efficiently belong.

I've never seen it that way, but rather:

E2E services and capabilities cannot be composed *solely* from their HBH
components.

I.e., the HBH remains useful for many reasons - efficiency among them.
It's always more useful to retransmit over the lossy hop than to wait
for the ends to retransmit, but E2E recovery remains required.

There's also the problem of defining "end" vs "middle". I use a variant
of HW vs SW (i.e. HW = that which you can kick; SW = that which you
cannot kick):

	- endpoint - that which *I* can kick (or SW that runs thereon)
	- middle - that which *I* cannot kick

It hammers home the essence that end/middle is always a relative
distinction.

Joe