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

Daryl Malas <> Tue, 17 February 2015 15:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 255011A8A51; Tue, 17 Feb 2015 07:34:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.226
X-Spam-Status: No, score=0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jhoOvMd9XBLT; Tue, 17 Feb 2015 07:34:36 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 429A91A8A49; Tue, 17 Feb 2015 07:34:35 -0800 (PST)
Received: from (kyzyl []) by (8.14.7/8.14.7) with ESMTP id t1HFYYXe026454; Tue, 17 Feb 2015 08:34:34 -0700
Received: from ( by (F-Secure/fsigk_smtp/407/; Tue, 17 Feb 2015 08:34:33 -0700 (MST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/407/
Received: from ([::1]) by ([::1]) with mapi id 14.03.0224.002; Tue, 17 Feb 2015 08:34:32 -0700
From: Daryl Malas <>
To: "Francois Le Faucheur (flefauch)" <>, "Klaas Wierenga (kwiereng)" <>
Thread-Topic: review of draft-ietf-cdni-logging.15
Thread-Index: AQHQR6bsatwFQJOdLkuG1v9BlCIAFZzzy/wAgAG5RQA=
Date: Tue, 17 Feb 2015 15:34:31 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
X-Mailman-Approved-At: Tue, 17 Feb 2015 10:44:37 -0800
Cc: "" <>, "" <>, "" <>
Subject: Re: [secdir] review of draft-ietf-cdni-logging.15
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 17 Feb 2015 15:34:42 -0000

Question for clarity in-line.

On 2/16/15, 4:15 PM, "Francois Le Faucheur (flefauch)"
<> wrote:

>Thank you Klaas. We¹ll look into this shortly.
>> On 13 Feb 2015, at 17:05, Klaas Wierenga (kwiereng)
>><> wrote:
>> 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.

In Figure 1 of RFC 7336, you will notice the interfaces are indicated as
bi-directional.  I believe the spirit of this is to provide a hierarchal
perspective.  In any case, can you please clarify your ³security² related
concerns relative to this scenario?  So far, you have only indicated a
question of whether a downstream CDN can also be an upstream CDN.  What is
your related security question if the function changes relative to
exchanges via the logging interfaces?  If this is a terminology question,
I think it should have been addressed with regards to 7336.

To be clear, I¹m just asking for more clarity for the authors to properly
address this question.

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