Subject: [CDNi] Ben Campbell's Discuss on draft-ietf-cdni-metadata-18: (with DISCUSS and COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Tue, 05 Jul 2016 16:23:21 -0700

Ben Campbell 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:
----------------------------------------------------------------------

I have two concerns that I would like to see discussed prior to
publication:

1) Section 6.2 cites a normative reference to RFC 5861. That's an ISE
stream informational RFC. The text as written seems to normatively
require implementation of that RFC to enable the "caching" feature. Did
the working group discuss the implications of that? (I also note that
this doesn't appear to have been called out at IETF last call. While
there has been some discussion about relaxing that requirement, I'm not
sure this is an appropriate place to do so.)

2) Section 8.5 contains the "In an environment where any such protection
is required" language that has been discussed for several CDNI drafts.
But in this particular case, the implication that there may be
environments where such protection is _not_ required seems to conflict
with the multiple occurrences of "MUST use strong encryption/mutual
authentication" in sections 8.1-8.4.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Substantive Comments:

- 4.1, example (applies to all examples of referenced objects): Given the
rather strong guidance to use TLS to move metadata around, shouldn't the
examples that show referenced objects use HTTPS URLs?

- 4.1.3, "paths" property: Am I correct to assume that _only_ the first
match is used?

- 7.4: If the Auth type registry is initially unpopulated, doesn't that
make the Auth property useless for the time being? Why even specify it
now?

- 8.1, 2nd bullet: Could this sort of attack be used to distribute
compromised content (e.g. malware) to  end users?

- 8.3: Couldn't lack of integrity protection enable theft-of-content, in
addition to DoS? For example, if a MiTM changes the ACLs for a piece of
content?

- 11.1, reference to 6706: This is another normative downref that does
not appear to have been called out in the IETF last call announcement. I
will leave it to the authors and AD to decide if that's okay.

Editorial Comments and Nits:

- General: I don't expect action on this in general, but this draft seems
to have a lot of repeated material, which makes it considerably longer
and harder to digest than necessary for the content. (Note that, for
_normative_ text, such redundancy makes future updates error prone, even
if the text is consistent now.)

- 3, first paragraph: I’m not sure what you mean by “aggregated” in this
context.

- 3.2, third paragraph, last sentence: The MUST seems unneeded. Please
consider simply saying " ... the dCDN processes the content request in
accordance with the rest of the metadata.

- 4, paragraph 5: The MUST seems unneeded. There's no choice to make
here;  this is simply the way CDNI metadata objects are encoded. (Recurs
in 6.4, which seems redundant to this section.)

- 4.1.2, "Note" in definition of Host property: I usually think of "Note"
to designate parenthetical or "sidebar" content. Please consider dropping
the "Note" prefix for text that contains 2119 keywords. (There are
multiple occurrences throughout.) 

- 7.1.x Do you expect IANA to do something with these subsections? I
don’t see this sort of detail in the IANA registry. Otherwise, they seems
to belong in the main body, not the IANA considerations.

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 05 Jul 2016 20:55:53 -0500

BTW, the shepherd's email address seems to be incorrect.

Thanks!

Ben.

On 5 Jul 2016, at 18:23, Ben Campbell wrote:

> Please refer to 
> https://www.ietf.org/iesg/statement/discuss-criteria.html

---

From: Kevin Ma J <[email-masked]>
Date: Wed, 6 Jul 2016 01:58:32 +0000

Hi Ben,

  Thanks for the review.

  Wrt your first discuss comment: I do not recall a discussion, but I think Ben (Niven-Jenkins) would be better equipped to speak about the RFC5861 reference.

  Wrt your second discuss comment: We have updated the security considerations text to match the other CDNI drafts; the following will be in the next revision:

        TLS MUST be used by the server-side (dCDN) and the
        client-side (uCDN) of the CDNI metadata interface, including
        authentication of the remote end, unless alternate methods are
        used for ensuring the security of the information in the CDNI
        metadata interface requests and responses (such as setting up
        an IPsec tunnel between the two CDNs or using a physically
        secured internal network between two CDNs that are owned by
        the same corporate entity).

  Responses to your other comments inline.

thanx!
   
--  Kevin J. Ma

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Tuesday, July 05, 2016 7:23 PM
> To: The IESG
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Ben Campbell's Discuss on draft-ietf-cdni-metadata-18: (with
> DISCUSS and COMMENT)
> 

fair point; will update the examples

> - 4.1.3, "paths" property: Am I correct to assume that _only_ the first

correct; will clarify the text

> make the Auth property useless for the time being? Why even specify it

The Auth type is used by the Source and DeliveryAuthorization metadata objects, and we wanted both of those to use the same set of Auth objects, so it seemed like a good idea to go ahead and add it to the data model.  The URI Signing draft is in WGLC and will register the URI Signing Auth type.  It seemed reasonable and more centralized to just let metadata create the registry, with URI Signing coming in close behind to register the first type.
 
> compromised content (e.g. malware) to  end users?

Yes.  I was thinking rickrolling, but malware is arguably worse.  ;)  We can expand on the specific types of threats.

> addition to DoS? For example, if a MiTM changes the ACLs for a piece of

Possibly.  Mirja posed this point as well.  We will expand the on those additional threats

> will leave it to the authors and AD to decide if that's okay.

Assuming you mean 6707: It was suggested by our former AD that draft-ietf-cdni-redirection should have a normative downref to 6707, because of the terminology reference.  Metadata has the same terminology reference, so we assumed the same downref would be applicable to this draft.

> - 3, first paragraph: I’m not sure what you mean by “aggregated” in this

"grouped" might be a better term?

> accordance with the rest of the metadata.

Assuming you mean second paragraph: would a "MAY" work better?

> in 6.4, which seems redundant to this section.)

I'll defer to Ben NJ on this one as well.

> multiple occurrences throughout.)

understood; will remove the "Note"

> to belong in the main body, not the IANA considerations.

RFC7736 asks that the designated expert verify the purpose/interface/encoding for each ptype registration.  We have just been putting that information in the IANA section to have it all in one place for the expert review.

thanx!

--  Kevin J. Ma

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 05 Jul 2016 21:16:06 -0500

Thanks for the response. Some response-responses inline. I removed stuff 
that seems to be resolved.

Thanks!

Ben.

On 5 Jul 2016, at 20:58, Kevin Ma J wrote:

> Hi Ben,
>
>   Thanks for the review.
>
>   Wrt your first discuss comment: I do not recall a discussion, but I 
> think Ben (Niven-Jenkins) would be better equipped to speak about the 
> RFC5861 reference.

Okay.

>
>   Wrt your second discuss comment: We have updated the security 
> considerations text to match the other CDNI drafts; the following will 
> be in the next revision:
>

That text would address my concern.

[...]

> The Auth type is used by the Source and DeliveryAuthorization metadata 
> objects, and we wanted both of those to use the same set of Auth 
> objects, so it seemed like a good idea to go ahead and add it to the 
> data model.  The URI Signing draft is in WGLC and will register the 
> URI Signing Auth type.  It seemed reasonable and more centralized to 
> just let metadata create the registry, with URI Signing coming in 
> close behind to register the first type.
>

Okay, that seems to make sense.

> Yes.  I was thinking rickrolling, but malware is arguably worse.  ;)  
> We can expand on the specific types of threats.
>

Hmm. Mass rickrolling might be a feature :-)

> Assuming you mean 6707:

Oops, yes.

> It was suggested by our former AD that draft-ietf-cdni-redirection 
> should have a normative downref to 6707, because of the terminology 
> reference.  Metadata has the same terminology reference, so we assumed 
> the same downref would be applicable to this draft.

I won't hold up things over this one--just do the right thing, whatever 
that is. :-)

> "grouped" might be a better term?

Okay.

> Assuming you mean second paragraph: would a "MAY" work better?

How about "processes" :-)  (It's up to you; this was not a blocking 
comment.)

> I'll defer to Ben NJ on this one as well.

Okay.

> RFC7736 asks that the designated expert verify the 
> purpose/interface/encoding for each ptype registration.  We have just 
> been putting that information in the IANA section to have it all in 
> one place for the expert review.

Okay.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 6 Jul 2016 07:29:43 +0100

Hi Ben,

> On 6 Jul 2016, at 00:23, Ben Campbell <[email-masked]> wrote:
> 

Sigh. I will need to re-LC the document to address any DownRefs.

---

From: Kevin Ma J <[email-masked]>
Date: Wed, 6 Jul 2016 17:56:03 +0000

Hi Ben,

  Wrt the RFC5861 reference, the authors agreed that the stale-if-error text is not needed, and propose the following text to just deny delivery if the metadata cannot be refreshed:

   In cases where a dCDN is not able to retrieve the entire set of CDNI
   metadata associated with a User Agent request, or it has retrieved
   that metadata but it is stale according to standard HTTP caching
   rules and cannot be revalidated, for example because
   the uCDN is unreachable or returns a HTTP 4xx or 5xx status in
   response to some or all of the dCDN's CDNI metadata requests, the
   dCDN MUST NOT serve the requested content.

> in 6.4, which seems redundant to this section.)

  We will remove the text from section 4 and just leave the reference to section 6.4

thanx!

--  Kevin J. Ma

> Sent: Tuesday, July 05, 2016 10:16 PM
> To: Kevin Ma J
> Cc: The IESG; Ben Niven-Jenkins; Francois Le Faucheur; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: Ben Campbell's Discuss on draft-ietf-cdni-metadata-18: (with
> DISCUSS and COMMENT)
>

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 06 Jul 2016 13:01:35 -0500

That all works for me, assuming the wg and AD is okay with it.

There's been enough discussion that I will clear my discuss on the 
assumption that people will do the right thing.

Thanks!

Ben.

On 6 Jul 2016, at 12:56, Kevin Ma J wrote:

> Hi Ben,
>
>   Wrt the RFC5861 reference, the authors agreed that the 
> stale-if-error text is not needed, and propose the following text to 
> just deny delivery if the metadata cannot be refreshed:
>
>>>> don’t see this sort of detail in the IANA registry. Otherwise, 
>>>> they
>>>> seems