Re: [CDNi] Stephen Farrell's Discuss on draft-ietf-cdni-metadata-18: (with DISCUSS and COMMENT)

Kevin Ma J <kevin.j.ma@ericsson.com> Wed, 06 July 2016 18:48 UTC

Return-Path: <kevin.j.ma@ericsson.com>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CF812D51A; Wed, 6 Jul 2016 11:48:58 -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, RCVD_IN_MSPIKE_H2=-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 igO4FrMDsr3i; Wed, 6 Jul 2016 11:48:55 -0700 (PDT)
Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96A4712D50A; Wed, 6 Jul 2016 11:48:55 -0700 (PDT)
X-AuditID: c618062d-f79886d000002334-fa-577d47f44548
Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 40.36.09012.4F74D775; Wed, 6 Jul 2016 20:03:32 +0200 (CEST)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0294.000; Wed, 6 Jul 2016 14:48:54 -0400
From: Kevin Ma J <kevin.j.ma@ericsson.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, The IESG <iesg@ietf.org>
Thread-Topic: Stephen Farrell's Discuss on draft-ietf-cdni-metadata-18: (with DISCUSS and COMMENT)
Thread-Index: AQHR139lstjFAGLneEa3x33O9pLNMKALsdQQ
Date: Wed, 06 Jul 2016 18:48:50 +0000
Message-ID: <A419F67F880AB2468214E154CB8A556206E486EC@eusaamb103.ericsson.se>
References: <20160706121028.7876.62515.idtracker@ietfa.amsl.com>
In-Reply-To: <20160706121028.7876.62515.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.10]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyuXRPgu4X99pwg5YFphZHWn8xWjyd/YfV 4vKZiYwW/xacZrKY8Wcis8X0vdfYHdg8pvzeyOqxtvsqm8eSJT+ZApijuGxSUnMyy1KL9O0S uDI+ft3JWnAqpGLb0hbmBsYtQV2MnBwSAiYS9y7PYYKwxSQu3FvP1sXIxSEkcJRR4kpDLzuE s4xR4t7Mw2BVbAJaEo+//gWzRQQ8JR72nWIBKWIWOMUo0dFxkh0kISyQLPHvw0JmiKIUicPz ZjFC2EYSvfdmg8VZBFQknt18zgZi8wr4Sky98pYFxBYScJCY+ewkWD2ngKPE9B+XwWYyAp33 /dQasMXMAuISt57MhzpbQGLJnvPMELaoxMvH/1ghbCWJSUvPAdkcQPWaEut36UO0KkpM6X7I DrFWUOLkzCcsExjFZiGZOguhYxaSjllIOhYwsqxi5CgtLsjJTTcy2MQIjKtjEmy6OxjvT/c8 xCjAwajEw7vga3W4EGtiWXFl7iFGCQ5mJRFeL//acCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8 Yo8Uw4UE0hNLUrNTUwtSi2CyTBycUg2MIY+S7klUngxX4X/A5Pk+99+lG2sLuX/YVPkdTvzP wiD9L1bwq/6HnJJqy3sbbvY25zTa1H4oEGgWOSLbUadzJ/zlvLbt6mwGf2cqNl/gbvnPduu7 AYvjbwmWpK5VHEw+57/7dE9ZkSA8rUetX+J7s+z10qzZEjyia87tyv7bk7P94IIHO/SUWIoz Eg21mIuKEwHPx30IpwIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/cdni/Da2dXu_9olFm7umOi4jFuTzZ91o>
Cc: "flefauch@cisco.com" <flefauch@cisco.com>, "cdni@ietf.org" <cdni@ietf.org>, "draft-ietf-cdni-metadata@ietf.org" <draft-ietf-cdni-metadata@ietf.org>, "cdni-chairs@ietf.org" <cdni-chairs@ietf.org>
Subject: Re: [CDNi] Stephen Farrell's Discuss on draft-ietf-cdni-metadata-18: (with DISCUSS and COMMENT)
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" <cdni.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cdni>, <mailto:cdni-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cdni/>
List-Post: <mailto:cdni@ietf.org>
List-Help: <mailto:cdni-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cdni>, <mailto:cdni-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jul 2016 18:48:58 -0000

Hi Stephen,

  Thanks for the review.

  Wrt your first discuss comment, the intended auth is URI Signing, which is defined in 	
draft-ietf-cdni-uri-signing, and is currently in WGLC.  The idea is that if the content owner or uCDN signed the URI and delivery is delegated to a dCDN, then the dCDN should validate the signing token in the request before responding with the content.  In that case, the dCDN needs to know that it needs to check for a signing token, and what the parameters are for validating the token; this is conveyed in the metadata, along with how to acquire the content.  This task was split into separate documents for various reasons, but we kept the parts that are not URI Signing specific in the metadata draft, so that it's in a centralized place if/when a new auth type is added.

  Wrt your second discuss comment, you make a good point.  I agree that we would (at least) want documentation/justificatio of any intentional security/privacy violating metadata.  We will add the point in the next revision.

  Responses to your other comments inline.

thanx!

--  Kevin J. Ma

> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
> Sent: Wednesday, July 06, 2016 8:10 AM
> To: The IESG
> Cc: draft-ietf-cdni-metadata@ietf.org; cdni-chairs@ietf.org;
> flefauch@cisco.com; cdni@ietf.org
> Subject: Stephen Farrell's Discuss on draft-ietf-cdni-metadata-18: (with
> DISCUSS and COMMENT)
> 
> Stephen Farrell has entered the following ballot position for
> draft-ietf-cdni-metadata-18: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-cdni-metadata/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> 
> (1) I don't get the model for telling a dCDN that the user
> agent has to have authenticated or that some authorization
> is needed before content is to be delivered. Can you
> explain?  For example, neither 4.2.5 nor 4.2.7 tell me how
> to do anything but allow open-access, and the relevant IANA
> registry (section 7.4) is empty, so I'm puzzled.
> 
> (2) 6.5: I think you're missing a MUST in the list here.
> I'd suggest something like: "5. Describe the security and
> privacy (for the person/user-agent, not only xCDN)
> consequences of the extension." I'm assuming that we agree
> that it'd be a bad idea if e.g. some extension were defined
> that allowed a uCDN tell a dCDN to try to track and report
> on all of a user's activities. (Or at least, that'd need to
> be documented/justified.)
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> - general: I agree with Ben's discuss about use of TLS. I
> also wonder if IPsec is really going to be used here. And
> even if so, you might be better off to say that TLS with
> mutual-auth SHOULD be used in all cases.

Yes.  The next revision will have text in line with triggers and logging.

> - general: Don't you need some guidance for the dCDN to say
> when to stop following (what might be circular) links?

Good point.  We will review the link text and add loop prevention.

> - general: I think it'd be better if the examples given used
> https in all cases, assuming we do think that'd be better.
> And if it'd not be better, saying why would I think be good.

Yes.  Ben made the same comment.  This will be updated in the next revision.

> - 1.2, last para: I don't get what this is saying. What
> additional things need specifying? If all you mean is that
> the dCDN and uCDN need to be able to setup TLS sessions, and
> hence need to agree on what CAs and ciphersuites to use,
> then maybe just say that. (You do already refer to RFC7525
> so most of that is covered there I think.)

Yes, CAs and ciphersuites, but there was also the question of keys.  (I suppose if we went with the dCDNs generating their own keys it would be doable?  Or if we left key sharing up to the CDNs to do offline, similar to URI Signing?)
At the time, way back when, some folks looked at it and determined it to be too messy to tackle.
More recently, though I believe you've expressed some skepticism as to the applicability of LURK to CDNI, it seemed like a better option to see what the security experts could come up with, rather than us trying to define a metadata object.

> - 4.1.1: I don't think I-JSON requires that order be
> preserved, but you seem to need that here, e.g. if a tCDN
> decodes and re-encodes, or if a uCDN round-trips a data
> structure. Is there a missing "MUST preserve order"
> somewhere?

We probably should've used the word "array" (which is an ordered list), rather than the word "list"; we will update the text in the next revision.

> - 4.1.x, 4.2.x, 4.3.x: I wonder if the specification is a
> bit too loose in places here, e.g. what does "$$" mean in
> 4.1.5 and why is that special?  In the same section I also
> wasn't clear if "/movies/" is the same as "/movies/*" or
> not, nor if you consider that "/movies/*" does or doesn't
> match "/movies/1/2/3". Isn't a reference needed in 4.3.4?
> I'd guess that a lot of this is close enough that
> implementations will likely get a lot, but not all, of this
> right, and that that might lead to corner-cases where
> interop isn't so good.  Improving that would seem like a
> good idea, but perhaps it's better to wait and see what
> deployments do and then tidy this up? Not sure.  In reading
> I spotted a number of places where such things occurred to
> me (but didn't write them all down, sorry;-).

The GenArt reviewer also noted the escaped dollar sign "$$" question.  The next revision will try to clarify that text.

> - 6.8: I didn't follow this, sorry;-) I assume it's
> considered clear enough for implementers, so feel free to
> ignore me, but I didn't get how to know whether or not e.g.
> ".v2.2.2" is newer than ".v2" or ".fixed-v1".

We were thinking ".v" + NUM, where comparison is based on NUM, but it probably doesn't actually matter, because the ptype is really opaque to the implementation.  It was more of a suggested convention.

MI.URISigning.v1 will have an RFC associated with it, and has a set of properties defined, and MI.URISigning.v2 will have a different RFC with a whole other set of properties defined (though it may include all of MI.URISigning.v1 by reference).  I don't think it was ever intended that a CDN would need to compare MI.URISigning.v1 and MI.URISigning.v2 for any reason; only that a unique identifier is needed for each (version of a) metadata object, so that one can determine what exactly is supported.  We can try to clean up that text as well.

> - 8.3: did the WG consider (possibly future) uses of JOSE to
> provide e2e security from uCDN to dCDN even via tCDN? I'm ok
> that you don't define that now, but wondered, as it seems
> like a fairly obvious thing to want. (To this security nerd
> anyway:-) I also wondered the same for 8.4, but I get that
> that'd be less likely of widespread utility. If using IPsec
> to security inter-CDN links, something like JOSE would seem
> to me to add quite a bit of value, if the CDNs insist on not
> using TLS.

I do not recall a discussion of JOSE.  It's probably less obvious for us less security-wise.

thanx!

--  Kevin J. Ma