Last Call Review of draft-ietf-cdni-logging-15
review-ietf-cdni-logging-15-secdir-lc-wierenga-2015-03-02-00

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