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

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Fri, 27 Jun 2014 09:08:15 +0000

All,

(as a document editor)

The resolution coming in the next revision is discussed below:

On 25 Apr 2014, at 18:53, Ben Niven-Jenkins <[email-masked]> wrote:

> Francois,
> 
> Rob, Grant and I chatted this over, our thoughts are inline below.
> 
> On 18 Apr 2014, at 18:07, Francois Le Faucheur (flefauch) <[email-masked]> wrote:
> 
>> 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?
> 
> 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.

I buy that argument. So I have kept the current wording.

> 
>> 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?
> 
> 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?

To me, the intention of the text is not to prevent a client from pulling the same file multiple times (if it fancies doing so). 
In fact we already have a statement saying "Note that a client-side implementation of the CDNI Logging interface MAY pull a CDNI Logging File that it has already pulled."
Rather, the intention was to say that, in case the client does not want to pull the same file twice across the two feeds, the client-side can rely on UUID as a way to establish that the same file is available on both feeds.
I now realise that the text is not crystal clear. 
In fact, I don't think there is any real RFC2119 requirements here. So I have replaced with:
"
If it supports redundant CDNI Logging feed, the client-side can use the UUID of the CDNI Logging File, presented in the atom:id element of the Atom feed, to avoid unnecessarily pulling and storing a given CDNI Logging File more than once.
"

> 
>> 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.
> 
> Sounds OK.

The client-side text has been updated to:
“
 o MUST implement HTTP/1.1 [RFC2616], MAY also support other HTTP versions (e.g., HTTP/2.0 [I-D.ietf-httpbis-http2]) and MAY negotiate which HTTP version is actually used. This allows 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 HTTP/1.1.
“

The server-side text has been updated to:
“
o MUST implement HTTP/1.1 to handle the client-side request and MAY also support other HTTP versions (e.g., HTTP/2.0);

> 
>> 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.
> 
> 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.

I think the argument above suggets that we may not want to mandate the use of gzip. But the requirement at stake here is not doing that. It is only mandating that the implementation MUST support exchange of file with gzip. Just like it already  mandates that teh implementation supports exchange of file with no content encoding. I think it is useful to ensure that server side and client side have at leats one compression scheme in common. The text already leaves it open as to whetehr content encoding is used, and when used which scheme is used.

So, the client-side and server-side text has been updated to mandate gzip support:
“
o MUST support exchange of CDNI Logging Files with no content encoding applied to the representation;
o MUST support exchange of CDNI Logging Files with "gzip" content encoding (as defined in [RFC2616]) applied to the representation.

> 
>> 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?
> 
> No.

The change above has been incorporated.

Francois

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

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Fri, 27 Jun 2014 13:49:00 +0000

All,

(as a document editor):

Resolution of item 2) below:

On 25 Apr 2014, at 19:28, ietfdbh <[email-masked]> wrote:

> 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.

Agreed.

The text was edited to:
“
The server-side implementation MUST be able to set HTTP cache control headers on the subscription feed to indicate the frequency at which the client-side is to poll for updates. The server-side SHOULD set HTTP cache control headers on the subscription feed to indicate the frequency at which the client-side is to poll for updates.

The client-side MAY use HTTP cache control headers (set by the server-side) on the subscription feed to determine the frequency at which to poll for updates. The client-side MAY instead, or in addition, use other information to determine when to poll for updates (e.g., a polling frequency that may have been between the uCDN and dCDN by mechanisms outside the scope of the present document and that is to override the indications provided in the HTTP cache control headers).
"

> 
> David Harrington
> [email-masked]
> +1-603-828-1401
> 
>> -----Original Message-----
>> 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,
>> 
>> On 19 Apr 2014, at 00:39, ietfdbh <[email-masked]> wrote:
>> 
>>> 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,
>>>> 
>>>> 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:
>>>> 
>>> [...]
>>>> 
>>>> 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 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.
>>>> "
>>>> 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?
>> 
>> 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).
>> 
>>> 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?
>> 
>> 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
>>> considerations?
>> 
>> 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)
>>>> 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: Kevin Ma J <[email-masked]>
Date: Fri, 27 Jun 2014 17:26:01 +0000

Hi Francois,

 one comment: "may have been between" -> "may have been negotiated between"?

thanx.

--  Kevin J. Ma

Sent from my iPhone

> On Jun 27, 2014, at 5:49 AM, "Francois Le Faucheur (flefauch)" <[email-masked]> wrote:
> 
> All,
> 
> (as a document editor):
>

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Mon, 30 Jun 2014 06:58:33 +0000

Thanks Kevin. Fixed now.