Subject: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded

From: Barry Leiba <[email-masked]>
Date: Fri, 31 Aug 2012 01:42:59 -0400

The IESG discussed draft-ietf-appsawg-http-forwarded-07 on this week's
teleconference (Thursday).  The IESG evaluation record can be found
here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ballot/

Stephen Farrell holds the main objections, but several other ADs agree
with him or with variants of his position.  The main two points are
these:
(1) This is NOT a good thing to standardize, and we shouldn't.
(2) This causes a serious privacy exposure, so *if* we do standardize
it, we have to address that.

After the telechat, Stephen switched his ballot from DISCUSS to
ABSTAIN.  There are two other ABSTAIN positions.  There also remain
three DISCUSS positions.  The document cannot progress unless all
three of those DISCUSS positions are cleared *and* at least one of
them moves to NO OBJECTION (well, *and* that assumes that both ADs who
are on vacation come back and ballot NO OBJECTION as well).

In short, this document is in serious trouble.

To continue discussion, the IESG intends to have a teleconference with
the document authors, and perhaps with other proponents.  If anyone
would like to actively participate in that discussion, please contact
me off list, and we'll see if we can add you -- we do need to keep it
small.  Then we'll see if we have a way forward.

Barry

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 31 Aug 2012 08:20:13 +0200

Hi Barry,

> it, we have to address that.

Well, I find it amazing that standardizing something which has been in
use everywhere for the last 10-15 years is suddenly considered as causing
issues.

If the document is finally not accepted, what will happen simply is that
everyone will naturally continue to use the x-forwarded-for header as
usual, that's all.

In my experience the main usage is on reverse-proxies, to pass the
information to origin servers, mainly for logging purposes. Its use
is already quite rare on outgoing connections. Maybe section 8.3
should be improved to suggest that "proxies forwarding traffic to
untrusted locations should refrain from using the extension" ?

Regards,
Willy

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 31 Aug 2012 10:31:52 +0300

Hi Willy, 

the purpose of standardization is not to publish specifications covering everything that is is deployed. Standardization is more than just documenting; it also gives a signal to the wider Internet community that the IETF endorses a certain technology (particularly with Standards Track documents). I am sure there is lots of technology deployed that would at best lead to "don't try this at home" recommendations. 

Everyone who has ever followed the cookie and tracking debate may have noticed that this is not an uncontroversial topic. There are more considerations that need to be taken into account when design protocols than just whether it is technically possible to shuffle stuff around. 

In fact I am really curious why Opera spends resources in standardizing these parameters when they are (hopefully) also trying to convince end customers that their browser is something they should put their trust in.

Ciao
Hannes

On Aug 31, 2012, at 9:20 AM, Willy Tarreau wrote:

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Eliot Lear <[email-masked]>
Date: Fri, 31 Aug 2012 09:34:11 +0200

Willy, Barry,

Is the way forward here an applicability statement?  If the real use is
reverse proxies it is possible to make that more clear in the document.

Eliot

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 31 Aug 2012 10:39:54 +0300

Eliot, 

The reverse proxy story is a way to make this look good and we know it
will be used otherwise. 

I don't know why aren't acknowledging that there are privacy concerns as
well even if they are inconvenient for an engineer. Just adding fluffy
and warm text does not make these concerns go away. I think we are
cheating here. 

Ciao
Hannes

> -----Original Message-----
> From: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of ext Eliot Lear
> Sent: Friday, August 31, 2012 10:34 AM
> To: Willy Tarreau
> Cc: Barry Leiba; Apps Discuss
> Subject: Re: [apps-discuss] Status of
draft-ietf-appsawg-http-forwarded

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 31 Aug 2012 09:54:30 +0200

Hi Hannes,

> The reverse proxy story is a way to make this look good and we know it

It's not a way to make it look good, it's really used and needed on
server-side.

> and warm text does not make these concerns go away. I think we are

But then what are you proposing ? It's just like saying that we should
forbid eating with forks and knifes in restaurants because some people
might use the knife to kill their noisy neighbour. Everything which is
created has good and bad usages. And I see this draft as an opportunity
to remind implementors about what to do and what not to do. Right now,
they're acting blindly, deploying their proxies without even knowing
that they're sending xff to the whole world.

Regards,
Willy

---

From: Eliot Lear <[email-masked]>
Date: Fri, 31 Aug 2012 10:19:09 +0200

> The reverse proxy story is a way to make this look good and we know it

I think you are concerned that an ill informed national policy might
require the use of this header, such that it exposes PII to UNAUTHORIZED
people.  It's not that you're thinking that enterprise administrators
will have removed their brains and simply would allow this sort of
exposure.  Is that correct?  If so, I understand and share this concern,
and it should be documented that this is the wrong lever and can lead to
serious security problems, if used on an outbound proxy.

As I understand it, you and Alissa just released a brand new related RFC
on this topic relating to GEOPRIV, by the way.  Congratulations!

Eliot

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 31 Aug 2012 10:54:31 +0100

Hannes has, to some extent captured the nature of my Discuss (which I don't
think Barry represented at all well in his original email).

The current document does not lead me to understand what problem is being
solved. I am just shown a solution (which I believe is perfectly functional).

I need to see why this is being developed and what it is for. I should note that
it is possible that when I am shown the answer to that question, I will decide
that I don't believe the problem or that it is out of scope for the IETF or that
it is pure evil :-) But until I see the answer I cannot begin to guess.

I also need to understand why if, as I am repeatedly told, there is a perfectly
functional solution in place at the moment (to the extent that if we did not
publish this document as an RFC, the existing solution would simply continue to
be used), we need to document another solution.

These details need to be captured in the document. Hopefully, the WG has already
reached agreement on these points (or else why request publication?) and so the
task is as simple as writing up a record of the WG's discussions.

On the topic of privacy, I believe that the WG is well aware that privacy is a
sensitive issue and can easily see that this document could be construed as
violating privacy. Therefore (per my Comment) the WG really should spend some
time documenting (in this I-D) the impact this work has on privacy. It may be
that the such text can demonstrate that the work does not have a substantive
impact.

Thanks,
Adrian

> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
> Sent: 31 August 2012 08:40
> To: ext Eliot Lear; Willy Tarreau
> Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded
> 
> Eliot,
>

---

From: Andreas Petersson <[email-masked]>
Date: Fri, 31 Aug 2012 12:52:37 +0200

On Fri, 31 Aug 2012 10:39:54 +0300

> and warm text does not make these concerns go away. I think we are

Have you read the section "Privacy Considerations"?

 /Andreas Petersson

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 31 Aug 2012 13:17:39 +0100

Hi Eliot,

On 08/31/2012 09:19 AM, Eliot Lear wrote:
> people.  

I don't know of any country-level requirements here though
they could exist or come into existence if XFF were to be
standardised.

>From what I've read, e.g. [1,2], it appears to be on by default
in some popular proxies which would imply that if you consider
the client IP address as PII, then that's being sent loads of
places with nothing remotely resembling authorization.

I don't know for sure though, some real usage information
would be useful both about who is sending it and what sites
are doing when they get it.

S.

[1] http://en.wikipedia.org/wiki/X-Forwarded-For
[2] http://meta.wikimedia.org/wiki/XFF_project

> It's not that you're thinking that enterprise administrators

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 31 Aug 2012 13:19:35 +0100

Hi Willy,

On 08/31/2012 08:54 AM, Willy Tarreau wrote:
> And I see this draft as an opportunity

That sounds like two different but good things. Thing1 being
tell implementers more about what to do and not to do with XFF
code and whether to have it on by default or not if they do
support it, and thing2 being to tell deployers about the
consequences of having XFF turned on or off and what you
can and cannot safely do with XFF.

Neither would require standardising a new header field.

But I don't think those things are in this draft, which
basically says how to manipulate a new header field that does
the same thing as XFF, but is more well-defined.

I suspect a document that described XFF implementation
and deployment issues as above would be good input for
designing for a new header field, were that to be
desirable. (I remain unconvinced.)

S.

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 31 Aug 2012 14:49:40 +0200

Hi Stephen,

> Neither would require standardising a new header field.

IIRC the first motivation for changing the header field name is that
X-anything cannot be a standard header by definition. The second one
is that as with any non-standard thing,some usages were not
compatible among implementations (eg: encoding of IPv6 addresses,
passing of source port, original Host header and scheme).

> the same thing as XFF, but is more well-defined.

Maybe then a bit more of context may help at the beginning of the
draft ?

> desirable. (I remain unconvinced.)

As I explained above, due to implementation incompatibilities which
currently exist, trying to force changing how XFF is currently used
would at best be ignored, at worst make things worse from an interop
point of view.

Regards,
Willy

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 31 Aug 2012 14:03:17 +0100

Hiya,

> passing of source port, original Host header and scheme).

But those only apply after one is convinced that standardising
a "better" XFF is a good idea.

> Maybe then a bit more of context may help at the beginning of the

I suspect its really a different document entirely that
documents current XFF implementation and deployment
practices. I reckon that text might be a good bit longer
than the entire current draft.

> would at best be ignored, at worst make things worse from an interop

I do get the point but I don't agree that just because a
buggy <<foo>> has been deployed means we ought to standardise
<<foo>> without those bugs.

S.

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 31 Aug 2012 15:08:55 +0200

> a "better" XFF is a good idea.

All people working on the server side are already convinced about that,
they're all facing the same interoperability issues and they need it
for logging purposes (at least).

> than the entire current draft.

It would not be wise to document wrong practices of non-standard header
fields which do not respect the standardized header field format. HTTP
is crappy enough to avoid adding another exception on top of it.

> <<foo>> without those bugs.

I don't get your point here, sorry. I read it as "we failed somewhere,
let's not fix it because it already exists" so I assume you meant
something else :-/

Regards,
Willy

---

From: Barry Leiba <[email-masked]>
Date: Fri, 31 Aug 2012 09:09:13 -0400

> I need to see why this is being developed and what it is for.

Sorry, Adrian: my intent was to give only the briefest summary of the
situation, and to send people to the DISCUSS text for more details.
Thanks for joining the discussion on the list.

Barry

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 31 Aug 2012 14:16:00 +0100

> for logging purposes (at least).

That last is kinda vague though isn't it?

> is crappy enough to avoid adding another exception on top of it.

I don't get how that squares with what you said earlier:

   "And I see this draft as an opportunity
    to remind implementors about what to do and what not to do.
    Right now, they're acting blindly, deploying their proxies
    without even knowing that they're sending xff to the whole
    world."

> let's not fix it because it already exists" so I assume you meant

I did. I meant that just because something is deployed is not
by itself sufficient reason to standardise (a less buggy version
of) that thing. TLS MITM proxies are an entirely different case
where that same issue arises. (I do hope I've not sent the thread
into a rathole about TLS MITM there;-)

S.

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 31 Aug 2012 15:32:21 +0200

> That last is kinda vague though isn't it?

How is the need for server-side logging something vague ? It's mandatory
by law in a number of places (maybe everywhere ?) and is one of the
basic security requirements. Most servers require this also to protect
against abuse. I won't make the insult of presenting what purposes a
server has of its visitor's IP address, we all have such requirements.

>     without even knowing that they're sending xff to the whole

Right now this is something needed but not documented since not
standardized. Some people even point me to wikipedia to explain
to me what they're trying to achieve! So they tend to use default
settings from the products they use, and there are not two similar
behaviours across products so there is no good nor bad practice.
I have already seen XFF being emitted by outgoing proxies and I
had to explain the admin what to do to avoid this.

> of) that thing.

It's not because it's deployed, It's because there is a real need and
without any standard, interoperability issues are created.

In turn, I don't see why addressing issues in something which already
exists should be wrong and discouraged.

Regards,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Fri, 31 Aug 2012 15:43:54 +0200

On 2012-08-31 15:32, Willy Tarreau wrote:
> ...
> ...

+1

The alternative is to take the draft, publish it elsewhere, and have the 
header field name registered anyway.

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 31 Aug 2012 16:07:52 +0200

> header field name registered anyway.

Exactly and it will be a new de-facto standard just like current header.

Regards,
Willy

---

From: John C Klensin <[email-masked]>
Date: Fri, 31 Aug 2012 12:28:03 -0400

Hi.

This is not my main area of expertise, but, based on reading the
DISCUSS positions and thinking that I've gotten at least the
main points of the thread, a suggestion...

Three main points seem to dominate the conversation so far:

	(1) This is widely deployed, possibly with variations.
	
	(2) If misused, and possible even if used properly, it
	raises some significant privacy (and maybe security)
	issues.
	
	(3) We think we know how to make it better.  It is not
	clear that "better" would solve the problems of (2) even
	if it might improve things somewhat.  There is also the
	question of whether "better" would be perceived as good
	enough or important enough in practice to deploy and
	replace the installed base.  The IETF's track record of
	getting "better" versions deployed when something is
	already out there and perceived as widely deployed and
	working has not been good.

The above doesn't justify standardization.  However, it seems to
me that it would make a lot of sense to recast the document into
Informational form and publish it.   I'd think that conditions
for such publication should be:

	(i) It really describes the current protocol and how it
	is used.   If there are possible variations that can't
	be easily cataloged, it is perfectly reasonable for such
	an Informational document to say "don't know, but..." or
	"maybe someone is..."
	
	(ii) It contains Security Consideration and Privacy
	Consideration sections that document those issues to the
	extent experts in those areas consider appropriate.
	
	(iii) If there are suggestions for improvement, they
	could be described as suggestions, with no need to
	obtain community consensus on whether they are good
	ideas or would accomplish anything.

I believe there really is value in having good descriptions of
things that are in wide use (or even that claim to be), even if
we don't approve of them.   We can't prevent people from doing
bad things by declining to standardize them, or even by
declining to document them, but there may be real advantages of
getting a document out there that describes what is being done
and what the issues are with it.  And, if the community really
detests the idea (I have no reason to believe there is, or is
not, consensus for "detesting"), I'd note that we cannot produce
an Applicability Statement that says "Not Recommended" without
having a document that describes what we we are recommending
against.

   john

---

From: Graham Klyne <[email-masked]>
Date: Fri, 31 Aug 2012 17:39:51 +0100

Something similar had occurred to me about going for informational/experimental 
rather than standards-track publication, which does not preclude a later upgrade.

There's one further (small) consideration: registration of the defined header 
field.  Standards-track approval pretty much guarantees that it meets the 
criteria for permanent registration.  Informational is less clear cut, but in 
this case I would judge that there has been sufficient discussion to warrant 
such a registration if RFC publication is approved following discussion and 
consensus in this forum.

#g
--

---

From: SM <[email-masked]>
Date: Fri, 31 Aug 2012 12:23:41 -0700

Hi Hannes,
>The reverse proxy story is a way to make this look good and we know it

On Fridays we can pretend that we don't know. :-)

>and warm text does not make these concerns go away. I think we are

There has been some discussion about privacy concerns.  The simple 
path would have been to acknowledge that as it was clear that it 
would an issue.  You are looking at the implications of the IETF 
giving its imprimatur whereas the focus has been getting a 
specification.  If we ignore the implications it will end up looking 
bad one of these days.

Regards,
-sm

---

From: John C Klensin <[email-masked]>
Date: Fri, 31 Aug 2012 15:42:15 -0400

--On Friday, August 31, 2012 17:39 +0100 Graham Klyne
<[email-masked]> wrote:

> Something similar had occurred to me about going for
> informational/experimental rather than standards-track
> publication, which does not preclude a later upgrade.
> 
> There's one further (small) consideration: registration of the
> defined header field.  Standards-track approval pretty much
> guarantees that it meets the criteria for permanent
> registration.  Informational is less clear cut, but in this
> case I would judge that there has been sufficient discussion
> to warrant such a registration if RFC publication is approved
> following discussion and consensus in this forum.

Graham,

I think we are in agreement but, with the understanding that I'm
talking about a general principle rather than the procedures or
minimal criteria for any specific registry, let me try to
restate this to test that hypothesis:

Registrations are about documentation, avoidance of conflicting
uses, and other aids to interoperability, not seals of approval.
Given that, if we have a situation in which 

	-- there are a keyword and associated procedure that are
	in wide use, 
	
	-- the protocol and keywords are reflected in a stable
	and available document  (RFCs certainly qualify, perhaps
	by definition)
	
	-- those who are experts in the deployment situation
	generally agree that the document accurately reflects
	the actual use and describes significant known issues

Then I would contend that, if we can't register the thing, the
defect is in the registration model or procedures, not in the
nature of the spec or keyword.

    john

---

From: SM <[email-masked]>
Date: Fri, 31 Aug 2012 12:47:40 -0700

Hi Willy,
>might use the knife to kill their noisy neighbour. Everything which is

Some airlines now provide plastic knives to avoid such inconveniences.  :-)

One DISCUSS mentioned that:

   "This feels to me like when a draft was just recently floated to
    standardize TLS proxies (i.e., standardized MITM) - sure we
    could do that but is really a good idea?"

Embarrassment is waiting down the road when "bad things" (TM) happen 
in case the IETF decides to touch that.

Regards,
-sm