Last Call: <draft-ietf-httpbis-cdn-loop-01.txt> (CDN Loop Prevention) to Proposed Standard

Discussion:

Julian Reschke

2018-11-28 05:39:43 UTC

-------- Forwarded Message --------
Subject: Last Call: <draft-ietf-httpbis-cdn-loop-01.txt> (CDN Loop
Prevention) to Proposed Standard
Date: Tue, 27 Nov 2018 08:03:18 -0800
From: The IESG <iesg-***@ietf.org>
Reply-To: ***@ietf.org
To: IETF-Announce <ietf-***@ietf.org>
CC: draft-ietf-httpbis-cdn-***@ietf.org, httpbis-***@ietf.org,
ietf-http-***@w3.org, ***@isode.com

The IESG has received a request from the Hypertext Transfer Protocol WG
(httpbis) to consider the following document: - 'CDN Loop Prevention'
<draft-ietf-httpbis-cdn-loop-01.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
***@ietf.org mailing lists by 2018-12-11. Exceptionally, comments may be
sent to ***@ietf.org instead. In either case, please retain the
beginning of
the Subject line to allow automated sorting.

Abstract

This specification defines the CDN-Loop request header field for
HTTP.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-cdn-loop/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-cdn-loop/ballot/

No IPR declarations have been submitted directly on this I-D.

Julian Reschke

2018-12-02 14:51:03 UTC

Permalink

Hi there,

1. Introduction
...
This specification defines the CDN-Loop request header field for HTTP
to enable secure interoperability of forwarding CDNs. Having a
header that is guaranteed not to be modified by other CDNs that are
used by a shared customer helps give each CDN additional confidence
that any purpose (debugging, data gathering, enforcement) that they
use this header for is free from tampering due to how that customer
configured the other CDNs.

Please use "header field" consistently.

1.1. Relationship to Via
HTTP defines the Via header field in [RFC7230], Section 5.7.1 for

s/[RFC7230], Section 5.7.1/Section 5.7.1 of [RFC7230]/

"tracking message forwards, avoiding request loops, and identifying
the protocol capabilities of senders along the request/response
chain."
In theory, Via could be used to identify these loops. However, in
practice it is not used in this fashion, because some HTTP servers
use Via for other purposes - in particular, some implementations
disable some HTTP/1.1 features when the Via header is present.

It would be nice if this came with pointers to related bug reports so
the reader could have a glance.

2. The CDN-Loop Request Header Field
CDN-Loop: FooCDN, barcdn; host="foo123.bar.cdn"
CDN-Loop: baz-cdn; abc="123"; def="456", anotherCDN
Note that the token syntax does not allow whitespace, DQUOTE or any

s/. See [RFC7230], Section 3.2.6./([RFC7230], Section 3.2.6)./

Likewise, note the rules for when parameter values need to be quoted
in [RFC7231], Section 3.1.1.

s/[RFC7231], Section 3.1.1/Section 3.1.1 of [RFC7231]/

5.2. Informative References
[loop-attack]
Chen, J., Jiang, J., Zheng, X., Duan, H., Liang, J., Li,
K., Wan, T., and V. Paxson, "Forwarding-Loop Attacks in
Content Delivery Networks", ISBN 1-891562-41-X,
DOI 10.14722/ndss.2016.23442, February 2016,
<http://www.icir.org/vern/papers/cdn-loops.NDSS16.pdf>.

The thing being cited is not the same thing as ISBN 1-891562-41-X (which
appears to be the publication in which the paper appears). I believe it
would be best to drop the ISBN number.

Best regards, Julian

Mark Nottingham

2018-12-04 22:21:03 UTC

Permalink

Hi Julian,

Post by Julian Reschke
s/[RFC7230], Section 5.7.1/Section 5.7.1 of [RFC7230]/

It would be nice if this came with pointers to related bug reports so the reader could have a glance.

s/. See [RFC7230], Section 3.2.6./([RFC7230], Section 3.2.6)./

Likewise, note the rules for when parameter values need to be quoted
in [RFC7231], Section 3.1.1.

s/[RFC7231], Section 3.1.1/Section 3.1.1 of [RFC7231]/

Is this just personal preference, or is there a reason you suggest this form? I see nothing about it in RFC7322.

Cheers,

--
Mark Nottingham https://www.mnot.net/

Julian Reschke

2018-12-05 05:44:16 UTC

Permalink

Post by Mark Nottingham
Hi Julian,

Post by Julian Reschke
s/[RFC7230], Section 5.7.1/Section 5.7.1 of [RFC7230]/

It would be nice if this came with pointers to related bug reports so the reader could have a glance.

s/. See [RFC7230], Section 3.2.6./([RFC7230], Section 3.2.6)./

Likewise, note the rules for when parameter values need to be quoted
in [RFC7231], Section 3.1.1.

s/[RFC7231], Section 3.1.1/Section 3.1.1 of [RFC7231]/

Is this just personal preference, or is there a reason you suggest this form? I see nothing about it in RFC7322.

In this case it was a personal preference, but note that just because
multiple forms are blessed, they work equally well everywhere...

Best regards, Julian

Tommy Pauly

2018-12-04 22:25:08 UTC

Permalink

Post by Mark Nottingham
Hi Julian,

Post by Julian Reschke
s/[RFC7230], Section 5.7.1/Section 5.7.1 of [RFC7230]/

It would be nice if this came with pointers to related bug reports so the reader could have a glance.

s/. See [RFC7230], Section 3.2.6./([RFC7230], Section 3.2.6)./

Likewise, note the rules for when parameter values need to be quoted
in [RFC7231], Section 3.1.1.

s/[RFC7231], Section 3.1.1/Section 3.1.1 of [RFC7231]/

Is this just personal preference, or is there a reason you suggest this form? I see nothing about it in RFC7322.

In fact, RFC 7322 actually includes both styles of section reference:

Status of This Memo

... see Section 2 of RFC 5741.

4.8.4. Internationalization Considerations Section

... see "IETF Policy on Character Sets
and Languages" [BCP18], Section 6, for more information.

—Tommy

Post by Mark Nottingham
Cheers,
--
Mark Nottingham https://www.mnot.net/

Alexey Melnikov

2018-12-05 11:04:05 UTC

Permalink

Post by Tommy Pauly

Post by Mark Nottingham
Hi Julian,

Post by Julian Reschke
s/[RFC7230], Section 5.7.1/Section 5.7.1 of [RFC7230]/

It would be nice if this came with pointers to related bug reports so the reader could have a glance.

s/. See [RFC7230], Section 3.2.6./([RFC7230], Section 3.2.6)./

Likewise, note the rules for when parameter values need to be quoted
in [RFC7231], Section 3.1.1.

s/[RFC7231], Section 3.1.1/Section 3.1.1 of [RFC7231]/

Is this just personal preference, or is there a reason you suggest this form? I see nothing about it in RFC7322.

Status of This Memo
... see Section 2 of RFC 5741.
4.8.4. Internationalization Considerations Section
... see "IETF Policy on Character Sets
and Languages" [BCP18], Section 6, for more information.

I suggest we leave this document as-as and let RFC Editor to sort this
out. They are quite good at this.