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

From: "Klaas Wierenga (kwiereng)" <[email-masked]>
Date: Fri, 13 Feb 2015 16:05:44 +0000

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

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Mon, 16 Feb 2015 15:15:11 +0000

Hi,

Thank you Klaas. We’ll look into this shortly.

Francois

> On 13 Feb 2015, at 17:05, Klaas Wierenga (kwiereng) <[email-masked]> wrote:
> 
> Hi,
>

---

From: Daryl Malas <[email-masked]>
Date: Tue, 17 Feb 2015 15:34:31 +0000

Question for clarity in-line.

On 2/16/15, 4:15 PM, "Francois Le Faucheur (flefauch)"
<[email-masked]> wrote:

>Hi,
>
>Thank you Klaas. We¹ll look into this shortly.
>
>Francois
>
>> 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.

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