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

["Klaas Wierenga (kwiereng)" <[e-mail]>]

Hi Francois,


> On 04 Mar 2015, at 11:24, Francois Le Faucheur (flefauch) <[e-mail]> wrote:
> 
> Hello Klaas,
> 
> Thanks for your review. Proposed resolution of comments below:
> 
>> 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.
> 
> Yes, any two CDNs can be in a u-d relationship , and is independent for each direction.
> ie CDN1 and CDN2 can be in a  u—>d ,  d—>u , or   u/d<—>u/d  relationship.
> 
> This should be established by RFC6707 and RFC7336 (that refers to the concepts and terminology of RFC6707).
> Regarding the specific situation of “uCDN —> dCDN-2 —>dCDN-3” in Figure 1, this situation is discussed in RFC6707. For example, it says:
> "
> Note that in the case of successive redirections (e.g., CDN1-->CDN2-->CDN3), a given CDN
>   (e.g., CDN2) may act as the Downstream CDN for a redirection (e.g.,
>   CDN1-->CDN2) and as the Upstream CDN for the subsequent redirection
>   of the same request (e.g., CDN2-->CDN3).
> “
> 
> To make things very clear in cdni-logging I have done the following edits:
> 
> 
> OLD:
> "
> In turn, dCDN2 has a CDNI interconnection with dCDN3.
> "
> NEW:
> "
> In turn, dCDN2 has a CDNI interconnection with dCDN-3, where dCDN-2 is acting as an upstream CDN relative to dCDN-3".
> "
> 
> 
> OLD:
> “
> A dCDN (e.g., dCDN-2) integrates the relevant Logging information
>   obtained from its dCDNs (i.e., dCDN-3) in the Logging information
> "
> 
> 
> NEW:
> “
> A downstream CDN relative to uCDN (e.g., dCDN-2) integrates the relevant Logging information obtained from its own downstream CDNs (i.e., dCDN-3) in the Logging information
> “
> 

perfect, thanks

> 
>> 
>> * 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.
> 
> The W3C ELF specification, while commonly used, is somewhat underspecified and only a draft document. The document says:
> “
> This is a W3C Working Draft for review by W3C members and other interested parties. It is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress”.
> “
> So it does not seem appropriate to simply reuse that spec, or even to use it as a stable base to extend from.
> 
> 
> Besides, we’ve really started from ELF and diverged where necessary or useful.
> Several of the directives we needed do not have any equivalent in ELF. Quite a few fields we needed do not have an equivalent in ELF, and/or do not have a totally unambigous description.
> Also we needed to be able to carry logs for non-HTTP protocols.

ok, that is a convincing argument. How about including a statement to that extent, something along the lines of: “we took ELF as a starting point and reused where possible and expanded when necessary”

> 
>> 
>> * 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,
> 
> The description of each directive includes an “occurence” specification, that defines when, how many times, where that directive can be used.
> The “occurrence” text for “Integrity-Hash” directive says:
> "When present, the Integrity-Hash field MUST be the last line of the CDNI Logging File.”
> 
> So I think we are covered here.

yup, I missed that, sorry ;-)

> 
>> 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. 
> 
> 
> Good points. To address the two comments above, I have incorporated the following edits:
> 
> I see.
> 
> I did the following edits:
> 
> OLD:
> “
> 7.1.  Authentication, Confidentiality, Integrity Protection
> "
> NEW:
> “
> 7.1.  Authentication, Authorization, Confidentiality, Integrity Protection
> "
> 
> 
> OLD:
> “
> The use of TLS for transport of the CDNI Logging feed and CDNI
>   Logging File pull allows:
> 
>   o  the dCDN and uCDN to authenticate each other (to ensure they are
>      transmitting/receiving CDNI Logging File from an authenticated
>      CDN)
> 
>   o  the CDNI Logging information to be transmitted with
>      confidentiality
> 
>   o  the integrity of the CDNI Logging information to be protected
>      during the exchange
> “
> NEW:
> “
> The use of TLS for transport of the CDNI Logging feed and CDNI
>   Logging File pull allows:
> 
>   o  the dCDN and uCDN to authenticate each other 
> 
> and, once they have mutually authenticated each other, it allows:
> 
>   o the dCDN and uCDN to authorize each other (to ensure they are
>      transmitting/receiving CDNI Logging File to/from an authorized
>      CDN)
> 
>   o  the CDNI Logging information to be transmitted with
>      confidentiality
> 
>   o  the integrity of the CDNI Logging information to be protected
>      during the exchange
> “
> 

that works for me

> 
>> In the text “In an environment where any such protection is required….” TLS is a "SHOULD unless…..”, Why not “MUST unless….”
> 
> We have discussed this in teh Working Group, and it was felt that the definition of “SHOULD” as per RFC2119 matches what squarely what we want to say here: 
> "This word, or the adjective "RECOMMENDED", mean that there
>  may exist valid reasons in particular circumstances to ignore a
>  particular item, but the full implications must be understood and
>  carefully weighed before choosing a different course.”
> So this does say that you are really meant to use TLS, but if you want to do something different, you need to have a good reason and really understand what you’re doing.

ok, if that is the WG consensus

>> 
>> * 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.
> 
> 
> Good point. I corrected the text:
> 
> OLD:
> “
> This document does not define specific mechanism to protect against
>   Denial of Service (DoS) attacks on the Logging Interface.  However,
>   the CDNI Logging feed and CDNI Logging pull endpoints can be
>   protected against DoS attacks through the use of TLS transport and/or
>   via mechanisms outside the scope of the CDNI Logging interface such
>   as firewalling or use of Virtual Private Networks (VPNs).
> "
> NEW:
> “
> This document does not define specific mechanism to protect against Denial of Service (DoS) attacks on the Logging Interface. However, the CDNI Logging feed and CDNI Logging pull endpoints are typically to be accessed only by a very small number of valid remote endpoints and therefore can be easily protected against DoS attacks through the usual conventional DOS protection mechanisms such as firewalling or use of Virtual Private Networks (VPNs).
> “


yes, that makes much more sense to me!

Klaas

> 
> Thanks again.
> 
> Francois
> 
>> 
>> 
>> Klaas
>> 
>> 
>> --
>> Klaas Wierenga
>> Identity Architect
>> Cisco Cloud Services