CDNI Working Group Minutes IETF-94, Yokohama, Japan - Chaired by Francois Le Faucheur, Daryl Malas and Kevin Ma - Meeting notes captured by Rob Murray and Daryl Malas, edited by Francois Le Faucheur - Audio Recording at: https://www.ietf.org/audio/ietf94/ietf94-rooms411_412-20151104-0900.mp3 - Slides accessible at: http://www.ietf.org/proceedings/93/cdni.html Wednesday, November 4, 2015, 09:00-11:30, Rooms 411/412 ======================================================= - about 60 people in the room, plus 5 on MeetEcho Introduction and Agenda (WG chairs) --------------------------------------------------------------- - Introduction by the WG chairs, and Note Well statement. - Change in WG personnel: * Daryl Malas will step down as co-chair after the Yokohama meeting due to change in in job responsibilities * Kevin MA has been appointed as co-chair - Agenda review, no request to change agenda - No new RFC published since previous IETF meeting - Handling of draft-ietf-cdni-media-type has been expedited as agreed and is now in RFC Editor queue. Thanks to Kevin Ma for editing and revving very fast and Barry Leiba for expediting the process. - Document Update and progress against the charter milestones * cdni-logging: still in “IESG Review.” Design Team worked out a solution for Privacy. Expect that document will be able to progress. * cdni-metadata: Ready for WG Last Call? * cdni-redirection: IPR disclosed. Ready to move to IESG review ? * cdni-control-triggers: Submitted to IESG review * cdni-footprint-capabilities-semantics: IPR disclosed. Ready for WG Last Call? * cdni-uri-signing: All HAs related material taken out. Ready for WG Last Call? - Documents beyond the charter: * CDNI handling of HTTPS Delegation: 2 earlier Internet-Drafts merged into one. CDNI Media Type, draft-ietf-media-type: Kevin Ma ------------------------------------------------ - IESG review done, it's in the Editor queue - single media type registered, with a new registry for payload type - MI/RI/LI/FCI docs all updated to use the new media type CDNI Logging, draft-ietf-cdni-logging-21: Francois Le Faucheur --------------------------------------------------------------- - Remaining ABNF corrections included (with help from Pete Resnik) - incorporated the conclusions of the CDNI Logging Privacy Design Team: * Problem: large volumes of detailed information about content delivery to users, potentially traceable back to indvidual users, may be collected in CDNI Logging files. These CDNI Logging files represent high-value targets at risk of potential data exfiltration. This is a Privacy concern that needs protection. * Solution: o Use c-groupid as an opaque identifier instead of c-ip and c-port. o Each aggregate must contain more than one client. * Fall back mode for special situations – Sometimes the upstream CDN needs o Potentially ensure a specific client was delivered to. o In those scenarios a mapping exists to a specific client. o Client IP address can be hashed/encrypted, so it can be decrypted to the IP address of a specific client o Associated risks were made clear in the text * The editorial issues and cdni-media-type alignment issues reported by Kevin were also addressed in the latest revision * Next Steps o Need to update the text related to choice of algorithm for mapping the IP addresses; Need to ensure text reflects which approach is “mandatory to implement” to ensure interoperability. This was discussed on the list. Please raise concerns on the list asap, if any. o Resolve comment from Kevin about what approach to take for extending logging o get IESG DISCUSSes cleared - Kent Leung * There are similar Privacy issues for exporting IP address in URI signing * Is the cdni-logging solution a general solution that can be recommended for other drafts, such as URI signing? - Francois: I think special case of being able to re-construct IP address applies to URI signing. Best to re-use the same "mandatory to implement" algorithm if appropriate. - Kevin : I agree we need to encrypt IP addresses in URI signing – a little different because we don’t have the expiry issue we have in logging. The refresh of the keys will be different. CDNI Metadata, draft-ietf-cdni-metadata-12: Kevin Ma ------------------------------------------------------------ - General clean-up and alignment to cdni-media-type - Removed “sid” o Any concerns with these being removed? – No comments from the working group. - Removed “CredentialAuth” o Any concerns with these being removed? – No comments from the working group. - Next Steps o Fix some typos o Check references o Update security considerations on privacy to make sure it’s clear what should be considered o Authors believe it is ready for Last Call - Kent Leung: Can DeliveryAuth be null? - Kevin Ma: Yes, it’s not required. - Francois Le Faucheur: Suggestion to complete the update, have a WG chair review , after that, go to WG Last Call. Should be able to complete before Buenos Aires. Any concern with this approach ? No concerns or comments from the Working Group on this approach. FCI Semantics : Kevin MA draft-ietf-cdni-footprint-capabilities-semantics-08 ------------------------------------------------------------------------------- - Resolved the Media Type vs. Registry questions – resulted in cdni-media-type - IPR disclosure from Juniper Networks - this was announced on the mailing list: * without taking a position - these look like usual purely-defensive terms, can be used freely in the interface, but the IPR owner will use to defend themselves if attacked * Does this IPR disclosure change anything with regards to the draft? * Reminder this draft is intended for Informational? o Option 1 – licensing terms are acceptable, continue with current plan o Option 2 – Change our plan somehow o Francois and Kevin, as individuals, agree with Option 1. Observe that this is a late disclosure though. o Francois: does anyone want to add any comment or object to Option 1? No objections for Option 1. - Next Steps: * Need to remove c-ip-anonimizing, because it was removed from logging * Need to update security considerations * After that, need to resume work on the FCI interfaces I-Ds. - Francois Le Faucheur: Any concerns with making these changes in cdni-footprint-capabilities-semantics and then going to working group last call? No comments from the group. Routing Request Redirection for CDN Interconnection, draft-ietf-cdni-redirection-10: Francois Le Faucheur (on behalf of authors) -------------------------------------------------------------------------------------------------- - Aligned draft to the new media-type draft - Added section regarding security concerns - Updated text to address concerns brought up by Jon Peterson - New text added to address DNSSEC - Jon Peterson: * text is not incorrect * If we use DNSSEC, then it should resolve the DNS concerns * Was really asking for the problem to be described (not for a solution), and this was not done. - Francois Le Faucheur: Jon, can you suggest on the list the text you’d like to see about the problem? - Jon Peterson: Yes - Kevin Ma: Fine with text Jon just proposed, and fine with existing text. - IPR disclosure from Juniper Networks - this was announced on the mailing list: * without taking a position - these look like usual purely-defensive terms, can be used freely in the interface, but the IPR owner will use to defend themselves if attacked * Does this IPR disclosure change anything with regards to the draft? o Option 1 – licensing terms are acceptable, continue with current plan o Option 2 – Change our plan somehow o Francois and Kevin, as individuals, and Ray van Brandenburg (as announced on the list) agree with Option 1. Observe that this is a late disclosure though. o Francois: does anyone want to add any comment or object to Option 1? No objections for Option 1. - Next Steps: * add the DNS text Jon will provide on the list (or equivalent) - Francois Le Faucheur: Does anyone have concerns, once the DNS text is included from Jon, for this to be submitted to IESG review? No concerns. CDNI Control Interface, draft-ietf-cdni-triggers-09: Rob Murray ------------------------------------------------------- - Aligned media types to cdni-media-type - Addressed minor editorial updates - Submitted to IESG review CDNI URI Signing, draft-ietf-cdni-uri-signing-05: Kent Leung ------------------------------------------------------------- - All content related to HAs has been removed, as agreed at previous IETF meeting in relation to IPR. - WG review * Document has been reviewed by Lief Hedstrom and Phil Sorber * Support path selection? Doesn't need to be discussed right now, authors will take it forward. * Allow a flexible prefix length for c-ip? Seems like a good idea, will take it forward. * Will also cover DoS protection use-case. * Attributes can normally be added to the URI, but will add an option to say that's not allowed for all/part of the URI * Will use a similar method to Logging to anonymise c-ip - needs further discussion * Will add a nonce to improve entropy (as there aren't many other properties in the URI that will change) - Next Steps: * Brian Weis will do an early security review o Kevin Ma: should review be conducted on current version, or after these updates? o Kent Leung: Next version would be better 0 Kevin Ma: We need to notify Brian Weis 0 Francois Le Faucheur: I will notify Brian * Also need to update Media Types and IANA considerations * Aim for WGLC after these updates - Kevin Ma : are the changes significant enough to require another WG review? - Kent Leung: Not major changes, but they affect a few sections, it'd be good to have a review of the delta - Francois and Daryl: it probably needs expert review before WG Last Call HTTPS and delegation of encrypted traffic, draft-fieau-https-delivery-delegation-01: Frederic Fieau --------------------------------------------------------------------------------------------------- * This document merged the two earlier drafts on the topic * Clarified the security requirements with regards to HTTPS and DNS delegation issues * Added a section on Third-party API for delegation (Keyless SSL) * Jon Peterson: In HTTPS redirection is there a practical use case where the seamless security scheme is not ensured? No comment from Frederic. * Jon Peterson: Just want to ensure we are properly describing the use case. Is there any case where this cannot be seamless? Why does the slide say it is not ensured? It should say that it is ALWAYS ensured. What am I not understanding? * Iuniana Oprescu: You might have misalignment with the URL you are redirected to. You might get an error when you are negotiating your second TLS connection. * Jon Peterson: This is simply trying to say that some server on the internet may not have the right certificate for negotiation. * Iuniana: Yes * Jon: This is not a problem for CDNI to resolve. It's a hard problem, covered by other WGs, need to make sure there's a good certificate architecture. This is not a problem for HTTPS, this is a DNS problem * Bill Manning: Concerned with certificate authorities that are compromised and the client will end up in the wrong place. Not a problem to be solved by this working group. * Kevin Ma: Do we need to more clearly describe what the HTTP redirection problem is? Is it when both CDNs are behind the same domain? * Jon: It might be worth articulating potential known problems. * Bill Manning: Nice to have a more full discussion how DNSSEC may mitigate these problems. * Jon: Want the problem to be very clear, to ensure we create the right solution. * Iuniana: the original goal was indeed to identify there is a real-life problem with CDNI redirection, not to solve it yet. Looking for help on that. * Iuniana: keep in-mind that we started with HTTP-only, but now we're finding it's not extensible to HTTPS * Jon: - perpass came along and said the world is going HTTPS, so we decided to reconsider it - but without actually re-evaluating the redirection interface, this document is an academic exercise - it's good to have this discussion to raise the issues for implementers & service providers, but... - concerned about progressing documents with known problems - we need to be clear that this works for HTTPS redirection and the problem is only with DNS request routing * Gihan Dias: looking for a really solid solution for HTTPS * Francois: we are aiming to address that in CDNI, but we'll do HTTP first and carry on looking at HTTPS * Francois: a question to Frederic: lots of comments raised in this discussion, will they be addressed in the draft? * Frederic - yes Open Discussion --------------- * Kent Leung: need to discuss MEPG-DASH Liaison statement related to cdni-uri-signing * Francois Le Faucheur: one liaison received from MPEG-DASH before Prague about URI-signing, they've just reissued another liaison statement for url-signing for segmented content, any comments? * Kent: Ben has responded on the list, we need to find out more detail about what MPEG are asking for, and we need to decide on our plan - will we use Ray's draft cover it? * Francois: our Working Group cdni-uri-signing draft is no longer applicable to segmented content because of the IPR issue, we need to tell MPEG about that. The CDNI WG charter doesn't explicitly cover segmented content so it's not obvious that we need a WG solution. We could continue to progress Ray's doc but we decided we don't want it to be a WG item. Another option is for Ray to progress his draft on uri-signing for HAS as an individual document, or he could work-around the IPR (but that doesn't seem to be possible), it's up to Ray. * Kevin Ma: how much closer does the “path-match” contained in draft-ietf-cdni-uri-signing get us to a solution for MPEG? * Kent Leung: we should carry on looking at path scoping for our own purposes, then look at whether it covers the MPEG case * Francois: it is a good point that path-match might help; will the document say that path match helps with segmented content? * Kent: not at the moment, don't want to slow things down and hit more IPR issues * Kevin: agreed, focus on the plan-of-record for uri-signing and let MPEG know where we're at * Francois: chairs will arrange to respond to MPEG liaison and requirements in more detail Meeting closes --------------