[secdir] Secdir review of draft-ietf-cdni-redirection-17

"Takeshi Takahashi" <takeshi_takahashi@nict.go.jp> Mon, 14 March 2016 01:04 UTC

Return-Path: <takeshi_takahashi@nict.go.jp>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398B612D893; Sun, 13 Mar 2016 18:04:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTB08dA8V2nh; Sun, 13 Mar 2016 18:04:55 -0700 (PDT)
Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id 547A712D6D8; Sun, 13 Mar 2016 18:04:54 -0700 (PDT)
Received: from gw1.nict.go.jp (gw1.nict.go.jp [133.243.18.250]) by ns1.nict.go.jp with ESMTP id u2E14qj2085230; Mon, 14 Mar 2016 10:04:52 +0900 (JST)
Received: from TakeVaioVJP13 (ssh1.nict.go.jp [133.243.3.49]) by gw1.nict.go.jp with ESMTP id u2E14ohJ085204; Mon, 14 Mar 2016 10:04:50 +0900 (JST)
From: Takeshi Takahashi <takeshi_takahashi@nict.go.jp>
To: draft-ietf-cdni-redirection@tools.ietf.org, cdni-chairs@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Date: Mon, 14 Mar 2016 10:05:13 +0900
Message-ID: <012401d17d8d$9176fc90$b464f5b0$@nict.go.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AdF9jXvJZLira36nRV2pgaEw0ZgSTg==
Content-Language: ja
X-Virus-Scanned: clamav-milter 0.98.7 at zenith1
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/EbKe7rxRH5yE-7IHWEKAPKj7Q60>
Subject: [secdir] Secdir review of draft-ietf-cdni-redirection-17
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 14 Mar 2016 01:04:57 -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.

[overall feeling on this draft]

ready.

[summary of this document]

This document talks about a necessary interface for CDN.
It defines the CDNI Request Routing Recirection interface, which is the
interface for the synchronous operation of an upstream CDN requesting
whether a downstream CDN is prepared to accept a user request and of a
downstream CDN responding with how to actually redirect the user request.
Specifically speaking, this document defines general message sequences of
the redirection as well as the protocol message syntax. It also elaborates
on how to handle the caches of the messages and how to handle errors.

[questions]

Here are some clarification questions.
I would appreciate if you could provide some answers to them.

1. Example jsons in P.25:

Do we need "description" in the json?
Since we already have "error-code" in the json, I am not sure whether we
need to embed the "description" in the json.
The description is written in the IANA table and is unique to each
error-code.
For this reason, I feel that we can omit the "description" from the json,
can't we?

2. error code of 503 in page 26 (3rd paragraph of the page).

I have got one question by reading two sentences: "If a dCDN receives an RI
request where the number of CDN Provider IDs in cdn-path is greater than
max-hops, the dCDN SHOULD send an RI response with an error code of
503."(3rd paragraph of page 26) and "transit CDNs MUST NOT propagate to any
downstream CDNs if the number of CDN Provider IDs in cdn-path is equal to or
greater than max-hops"(last sentence of page 25)

If "transit CDNs MUST NOT propagate to any downstream CDNs if the number of
CDN Provider IDs in cdn-path is equal to or greater than max-hops" is true,
no dCDN receives an RI request where the number of CDN Provider IDs in
cdn-path is greater than max-hops, is it correct?

Even if the answer is yes, I think it is wise to have the error code 503
(because some CDNs may be malfunctioning), but what types of actions should
the receivers of the error message take?


[typo]
In Table 1 in P.24:
"erred" -> "errored"?

Cheers,
Take