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

"Klaas Wierenga (kwiereng)" <kwiereng@cisco.com> Fri, 13 February 2015 16:06 UTC

Return-Path: <kwiereng@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 9DBDC1A0358; Fri, 13 Feb 2015 08:06:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.911
X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id qRlT7R41fPbS; Fri, 13 Feb 2015 08:06:20 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACB8C1A875C; Fri, 13 Feb 2015 08:05:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4352; q=dns/txt; s=iport; t=1423843545; x=1425053145; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=IJb7xLdMVPS+HZqMs5ZDpBxMsn+BjMVupcbACGvvNx0=; b=hJNMHQBKqJBl8pvCC0Ukg2FBGLW1YBPgKfFxi8ObzKxMMYUxto6ygzUa fLsIGEQ15GvyiIUYg4X6KpqBXp6GHvmm/tJ839sRJZqW+pxxPFoO4/gww 0FkrO62ow95QLNmlmbZKWW6Kw4rOnszF8rx5t8l0hcXwF6ju5sxr6Y95w U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.09,571,1418083200"; d="scan'208";a="395885787"
Received: from rcdn-core-7.cisco.com ([]) by rcdn-iport-7.cisco.com with ESMTP; 13 Feb 2015 16:05:45 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com []) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t1DG5iFD018087 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Feb 2015 16:05:44 GMT
Received: from xmb-aln-x12.cisco.com ([]) by xhc-rcd-x05.cisco.com ([]) with mapi id 14.03.0195.001; Fri, 13 Feb 2015 10:05:44 -0600
From: "Klaas Wierenga (kwiereng)" <kwiereng@cisco.com>
To: "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-cdni-logging.all@tools.ietf.org" <draft-ietf-cdni-logging.all@tools.ietf.org>
Thread-Topic: review of draft-ietf-cdni-logging.15
Thread-Index: AQHQR6bsatwFQJOdLkuG1v9BlCIAFQ==
Date: Fri, 13 Feb 2015 16:05:44 +0000
Message-ID: <493249E6-FD3B-46F3-AA3E-79ED26B594E1@cisco.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <32FC4DC09A73B24685101E42C8A60C4C@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/uSPJGaLImO3B3H1Yo7EnU8GUnH4>
Subject: [secdir] review of draft-ietf-cdni-logging.15
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Feb 2015 16:06:25 -0000


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 Wierenga
Identity Architect
Cisco Cloud Services