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

[Daryl Malas <[e-mail]>]

Question for clarity in-line.

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

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