Subject: [CDNi] cdni-logging : Proposed adjustments on MUST/SHOULD/MAY

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Fri, 18 Apr 2014 17:07:22 +0000

Folks,

(as a cdni-logging author)

David kindly conducted an early OPSDIR review of cdni-logging (and a very thorough one, I may add). 

This message discusses the proposed resolutions that affect MUST/SHOULD/MAY statements. Please review/comment:

1)
Current text:
"
 The fields names listed in the "Fields" directive MAY be listed in
   the order in which they are listed in Section 3.4.1 or MAY be listed
   in any other order.
“
The proposal is to replace by:
"
 The fields names listed in the "Fields" directive MUST be listed in
   the order in which they are listed in Section 3.4.1.
“
This would simplify implementation a bit and facilitates interoperability.
Can anyone see a good use case for exchanging fields in a different order?

2)
Current text:
“
The server-side implementation SHOULD use HTTP cache control headers
   on the subscription feed to indicate the frequency at which the
   client-side is to poll for updates.
“
The proposal is to replace by:
“
The server-side implementation MUST set HTTP cache control headers
   on the subscription feed to indicate the frequency at which the
   client-side is to poll for updates.
“
This would simplify implementation a bit and facilitates interoperability.
Can anyone see a good use case for not setting cache control headers (note that the other side may decide to poll independently of those, but at least it knowd those are always valid) ?

3)
Current text:
"
If it supports redundant CDNI Logging feed, the client-side
   SHOULD use the UUID of the CDNI Logging File, presented in the
   atom:id element of the Atom feed, to avoid unnecessarily pulling and
   storing each CDNI Logging File more than once.
“
The proposal is to replace by:
“
If it supports redundant CDNI Logging feed, the client-side
   MUST use the UUID of the CDNI Logging File, presented in the
   atom:id element of the Atom feed, to avoid unnecessarily pulling and
   storing each CDNI Logging File more than once.
"
This would simplify implementation a bit and facilitates interoperability.
Can anyone see a good use case for not using the UUID? 

4) 
In section 4.2 , current text
“
To do so, the client-side:
   o  MUST use HTTP v1.1 [RFC2616];
"
The proposal is to edit the text to say that the client-side MUST implement HTTP v1.1 and MAY also support other HTTP versions and MAY negotiate which HTTP version is actually used.  THis woudl allow to move to HTTP v2 while still complying with the spec.
The server-side text probably needs the corresponding adjustments.

5)
Current text:
“
   o  SHOULD support exchange of CDNI Logging Files with "gzip" content
      encoding (as defined in [RFC2616]) applied to the representation.
"
The proposal is to replace by:
“
   o  MUST support exchange of CDNI Logging Files with "gzip" content
      encoding (as defined in [RFC2616]) applied to the representation.
“
Given the concern about size of logging file it feel useful to have at least one common compression scheme.

6)
Current text:
“
 In an environment where any such protection is required, TLS SHOULD
   be used for transport of the CDNI Logging feed and the CDNI Logging
   File pull unless alternate methods are used for ensuring the
   confidentiality of the information in the logging files (such as
   setting up an IPsec tunnel between the two CDNs or using a physically
   secured internal network between two CDNs that are owned by the same
   corporate entity).  Both parties of the transaction (uCDN and dCDN)
   SHOULD use mutual authentication.
“
The proposal is to update to:
“
In an environment where any such protection is required, TLS SHOULD
  be used (including authentication of the remote end) by the server-side and the client-side of the CDNI Logging feed and of the CDNI Logging pull mechanism unless alternate methods are used for ensuring the
  confidentiality of the information in the logging files (such as
  setting up an IPsec tunnel between the two CDNs or using a physically
  secured internal network between two CDNs that are owned by the same
  corporate entity).
“
This is because it does not really make sense to say that “both ends use mutual authentication”, rather both ends need to authenticate the remote end (which collectively achieves mutual authentication).  
Any concern with that?

Francois

---

From: "ietfdbh" <[email-masked]>
Date: Fri, 18 Apr 2014 19:39:55 -0400

Hi,

Inline.

David Harrington
[email-masked]
+1-603-828-1401

> -----Original Message-----
> From: Francois Le Faucheur (flefauch) [mailto:[email-masked]]
> Sent: Friday, April 18, 2014 1:07 PM
> To: [email-masked]
> Cc: Francois Le Faucheur (flefauch); ietfdbh
> Subject: cdni-logging : Proposed adjustments on MUST/SHOULD/MAY
> 
> Folks,
> 
> This message discusses the proposed resolutions that affect
> MUST/SHOULD/MAY statements. Please review/comment:
> 
[...]
> Can anyone see a good use case for not setting cache control headers (note
> that the other side may decide to poll independently of those, but at
least it
> knowd those are always valid) ?
> 
Forgive me if I should already know this.

Section 4 talks about managing the ATOM feed, but only once does it mention
HTTP, and that is the sentence you are discussing.
Is HTTP the only way to control the frequency of polling? Or does it just
make the most sense since this document focuses on HTTP?

If, for whatever reason, an implementer or operator chose not to support
HTTP cache control headers,
Could an implementer/operator choose another protocol to specify the polling
frequency?
Are cache control headers at all controversial, say for security
considerations?

[...]
> The proposal is to edit the text to say that the client-side MUST
implement
> HTTP v1.1 and MAY also support other HTTP versions and MAY negotiate
> which HTTP version is actually used.  THis woudl allow to move to HTTP v2
> while still complying with the spec.

s/ THis woudl allow to move to HTTP v2 while still complying with the
spec./This would allow operators and implementers to choose to use later
versions of HTTP to take advantage of new features, while still ensuring
interoperability with systems that only support v.1.1./

[...]

> Francois=

dbh

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 22 Apr 2014 07:46:59 +0000

> [email-masked]

<…>

> interoperability with systems that only support v.1.1./

Agreed. Thanks.

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 22 Apr 2014 07:48:20 +0000

Rob, Ben, 

Any thoughts on the ATOM feed polling control question below?

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 25 Apr 2014 17:53:06 +0100

Francois,

Rob, Grant and I chatted this over, our thoughts are inline below.

> Can anyone see a good use case for exchanging fields in a different order?

We’re not convinced such a change does actually simplify implementation. Each implementation (CDN) will have its own internal log format. In order to transfer logs across the CDNI logging interface, each CDN may have to transform from its internal format to the CDNI logging interface format. However if a CDN uses a similar log format (e.g. w3c but with fields in a different order to section 3.4.1) then under the old text it would’t have to transform, whereas the new text would force it to, actually making the implementation harder (and changing from a MAY to a MUST does’t make the work of CDN that have to transform any easier either/simpler either).

The log format is based on a well known de-facto standard format (w3c), interoperability is achieved by parsing the Fields directives to determine the log field ordering. All the change does is allow implementations to be lazier (rather than parse the fields directive, assume that log fields are in a certain order). That may appear to aid interop but we don’t think it does really, as it may cause other issues, e.g. if a dCDN includes optional log fields and implementations are being lazy, will they fail to properly parse such valid CDNI log files? If everyone has to parse the fields directive, then initial implementation bugs may be more prevalent but long term interoperability is higher as implementations are less likely to barf when presented log files with additional optional log fields.

> Can anyone see a good use case for not setting cache control headers (note that the other side may decide to poll independently of those, but at least it knowd those are always valid) ?

Saying the server-side MUST set HTTP cache control headers seems OK. But (if the document does;t already), it should mention that a client may have out of band configuration/information that overrides the polling frequency hinted at through the HTTP cache control headers. Also the document would need to specify what a cache control of no-store/max-age=0 etc. means. Presumably it means “poll as often as you like” but that should be stated explicitly (if it isn;t already).

> Can anyone see a good use case for not using the UUID?

We don;t see how this simplifies implementation or facilitates interop. What it does is reduce the amount of log download traffic, as a client will only retrieve a log file once, but that does’t make implementation or interop simpler/easier.

Also it seems quite a draconian rule. If a client wants to download a log twice, why should’t it be able to?

> The server-side text probably needs the corresponding adjustments.

Sounds OK.

> Given the concern about size of logging file it feel useful to have at least one common compression scheme.

The goal is laudable. However there have recently been various exploits/attacks (e.g. BREACH) where an attacker can utilise information she knows that is reflected back in HTTP bodies to probe the compression context when compression is used in combination with encrypted transport such as TLS. The scenario is slightly different to the CDNI Logging interface but I think a similar sort of attack could possibly be constructed for CDNI Logging and folks are starting to take a general approach of not doing ‘blind’ content compression over secure channels (e.g. over TLS) as there is the risk of information leakage that BREACH/CRIME/etc attacks expose. That isn’t to say that compression isn’t suitable when using a secure channel, just that it needs more thought than applying a single compression context across the entire content being transferred (e.g. separate compression contexts for sensitive/non-sensitive data).

I’m not expert enough on security/BREACH/etc to say whether CDNI logging would avoid such issues and ‘blind’ compression is ‘safe’ but we should be cautious about introducing mandatory support for something that could be a security hole. Someone more qualified should probably analyse/comment.

A easy/safe option would be to leave it as a SHOULD rather than change to a MUST.

> This is because it does not really make sense to say that “both ends use mutual authentication”, rather both ends need to authenticate the remote end (which collectively achieves mutual authenticat…

No.

HTH
Ben

> 
> Francois
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 25 Apr 2014 17:59:12 +0100

David,

See inline,

> [email-masked]

Atom specifies no way to control the frequency of polling. Using HTTP cache control headers is the ‘de facto’/‘best practice’ according to various internet sources (e.g. stack overflow)

http://stackoverflow.com/questions/939642/policy-for-polling-rss

I would expect some deployments to control the frequency via out of band mechanisms (e.g. agreed configuration between uCDN & dCDN).

> Could an implementer/operator choose another protocol to specify the polling

I don’t see why not. HTTP cache control headers are only ever a hint anyway, there is nothing in HTTP that mandates a client actually caches something that is marked as cacheable.

> Are cache control headers at all controversial, say for security

I don’t think so. They’re widely used for content on the web and within HTTP-based APIs. I can’t think of any additional security considerations related to caching the atom feed itself that would’t apply to any other cacheable content transferred over HTTP.

Regards
Ben

---

From: "ietfdbh" <[email-masked]>
Date: Fri, 25 Apr 2014 13:28:58 -0400

Hi,

So it sounds to me like using HTTP cache control headers should be a SHOULD
use, not a MUST use.

This could be a MUST-implement for baseline interoperability reasons, just
like HTTPv1.1
"the server-side implementation MUST be able to set ..." would be correct.

Then whether to USE the cache headers, or another mechanism, is an
operational runtime decision.
"the server-side implement SHOULD set ..." would be a runtime decision, not
an implementation decision.

I think your best approach is to clearly separate implementation
requirements from use requirements.

David Harrington
[email-masked]
+1-603-828-1401

> From: Ben Niven-Jenkins [mailto:[email-masked]]
> Sent: Friday, April 25, 2014 12:59 PM
> To: ietfdbh
> Cc: Francois Le Faucher; [email-masked]
> Subject: Re: [CDNi] cdni-logging : Proposed adjustments on
> MUST/SHOULD/MAY
> 
> David,
> 
> See inline,
> 
> >> David kindly conducted an early OPSDIR review of cdni-logging (and a
very
> >> thorough one, I may add).
> >>
> Atom specifies no way to control the frequency of polling. Using HTTP
cache
> control headers is the 'de facto'/'best practice' according to various
internet
> sources (e.g. stack overflow)
> 
> I would expect some deployments to control the frequency via out of band
> mechanisms (e.g. agreed configuration between uCDN & dCDN).
> 
> I don't see why not. HTTP cache control headers are only ever a hint
anyway,
> there is nothing in HTTP that mandates a client actually caches something
> that is marked as cacheable.
> 
> 
> I don't think so. They're widely used for content on the web and within
> HTTP-based APIs. I can't think of any additional security considerations
> related to caching the atom feed itself that would't apply to any other
> cacheable content transferred over HTTP.
> 
> Regards
> Ben
> 
> 
> > [...]
> >>
> >> 4)