[secdir] review of draft-ietf-cdni-logging.15

["Klaas Wierenga (kwiereng)" <[e-mail]>]

Hi,

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the  security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

This document specifies the logging format and the exchange protocol for logging information between upstream and downstream CDNs that are interconnected using the CDN interconnection framework.

The document is well written and easy to read. I have few issues with the main text, but do have some concerns about the security and privacy considerations. I therefore consider the document “ready with issues”

Detailed comments:

* Introduction and Figure 1: What is not clear to me from the text is whether there is any functional difference between an uCDN and an dCDN,or that they just happen to be in a hierarchical relation to each other.  I could also find no reference to that in RFC7336. The fact that in Figure 1 dCDN-2 is not also labeled as uCDN-2 led me to believe that there is a functional difference. However from the text it appears that any two DCNs can be in an u-d relation to each other. Please clarify.

* Paragraph 3.2  CDNI Logging File Structure

You state that you chose a format as close as possible to the W3C ELF Format. I’d like to see a short explanation why you can not use that format, and whether it would be an option to extend that format rather than defining a new format that is slightly different but is essentially a form and could over time be significantly different.

* paragraph 3.3 Directives

For the Integrity-Hash you write: "hash function of all logging records and directives up to the hash-directive itself”. I have not seen that the directives are in a special order with the Integrity-hast as last one, so it appears that when the integrity-hash directive is the very first one there will be no sensible hash. Unless there is actual order in the directives (write that down) I suggest “has all logging information and directives with the exception of the Integrity-Hash directive itself”

* Paragraph 7.1 Authentication, Confidentiality, Integrity Protection

You leave out the 3d A, Authorization, but then you talk about mutual authentication to decide whether an entity is authorised to receive the logs, so I think you should insert it that one too.

You state that the use of TLS for transport allows for mutual authentication, confidentiality and integrity, that in itself is not true. You need TLS + mutual authentication to get confidentiality and integrity. 

In the text “In an environment where any such protection is required….” TLS is a "SHOULD unless…..”, Why not “MUST unless….”

* paragraph 7.2 DoS

I don’t understand how the use of TLS protects agains DoS, on the contrary I would say, trying to establish a TLS session is costly, so an evil entity could easily mount a DoS by trying to connect and exchange crypto material.


Klaas


--
Klaas Wierenga
Identity Architect
Cisco Cloud Services