IETF 92 - AVTCORE WG meeting minutes 13:00 Tuesday March 24, 2015 Chairs: Roni Even, Magnus Westerlund Note takers: Mo Zanaty, Varun Singh WG Status Update ---------------- Chairs Slides: http://tools.ietf.org/agenda/92/slides/slides-92-avtcore-2.pdf David Benham raised a question if a minor editorial change to clarify SFM behavior could be done on draft-ietf-avtcore-rtp-topologies-update-06. This was agreed to resolve this before going to IESG. Kevin Igoe reported that test vectors are being added to draft-ietf-avtcore-srtp-aes-gcm, which takes time to verify. Other changes (removing AES-CCM) will be done quickly. The chairs raised that the WG have a milestone: "Submit Real-Time Transport Control Protocol (RTCP) in Overlay Multicast for Proposed Standard". There has been no activity on this milestone for almost three years. Therefore the chairs proposed to remove the milestone. No objections in the room, and this will be confirmed on the mailing list. Circuit Breakers for Unicast RTP Sessions ----------------------------------------- Colin Perkins draft-ietf-avtcore-rtp-circuit-breakers-09 Slides: http://tools.ietf.org/agenda/92/slides/slides-92-avtcore-5.pdf Colin Perkins presented the updates of the document. Jonathan Lennox asked if there was any assumption of the group size, as that affects the possibility to keep within a fixed reporting interval. Colin responded that the minimal 5 seconds interval should be sufficient. Michael Ramalho on the average loss rate calculation: Consider using an inverse metric like interval between loss events rather than loss rate. Colin Perkins responded that we must use only current RTCP RR feedback without relying on XR or other metrics. Regarding the minimum sending rate and the open issue if a minimum RTT or other bounds. Cullen Jennings stated that we should not need to specify a minimum RTT or packet rate. Magnus Westerlund commented that loss rate becomes meaningless at very low RTTs, so we need bounds on this. Cullen responded that it is hard to choose a number that works. Harald Alvestrand noted that we currently don't have RTCP feedback per RTT. Varun Singh asked, is the worst case with low RTT (1ms) with low packet rate (1 per RTT). Colin responded yes, but unbounded. The conclusion was to add some text about the limitations at low RTTs. The authors will run simulations to verify that it works as expected and will try to have a version ready for WGLC before IETF93. Multiple Media Streams in a Single RTP Session ---------------------------------------------- Magnus Westerlund draft-ietf-avtcore-rtp-multi-stream-07 Slides: http://tools.ietf.org/agenda/92/slides/slides-92-avtcore-0.pdf Mo Zanaty commented for bundled RTP streams with many sources that need to convey MID, a limit of 4 initial RTCP packets may delay transmission. Colin Perkins responded that WebRTC is sending lots of initial packets (STUN/ICE, DTLS, etc.), so we should not easily allow more initial RTCP. Cullen Jennings commented that we have enough WebRTC implementations to test this and see what happens. Jonathan Lennox remarked that even with many sources, all may not need to send immediately, so prioritize the immediate senders. Multiplexing Scheme Updates for SRTP Extension DTLS --------------------------------------------------- Marc Petit-Huguenin draft-petithuguenin-avtcore-rfc5764-mux-fixes-02 Slides: http://tools.ietf.org/agenda/92/slides/slides-92-avtcore-1.pdf Eric Rescorla asked why do you need STUN over SCTP? Marc responded for big (>MTU) STUN messages, it is proposed to use SCTP for handling fragmentation of the STUN messages. Cullen Jennings commented that STUN over SCTP is not the right solution, TRAM should reconsider this. Justin Uberti asked if STUN fingerprints can be used to separate STUN/TURN from other traffic. Marc responded that it doesn't solve multiplexing of DTLS and RTP. Chairs noted that this draft clarifies the mux code points, the STUN over SCTP issue is for TRAM. Simon Perrault noted that that the TRAM chairs are very aware of this work. Eric commented that Multiple registries need to reflect the overlap/conflicting ranges of each other. There was discussion around what should happen in the registries. The proposal is to reserve them and include a pointer to the document explaining the potential issues of allocating in the ranges used by other protocols. Jonathan Lennox commented that it would be unlikely but bad if new TLS content types that never need to mux with RTP use up the remaining mux space. Conclusion, support for continue work on proposal except for STUN over SCTP over UDP that is to be excluded for now. Requirements for Private Media ------------------------------ Paul Jones draft-jones-avtcore-private-media-reqts-01 http://tools.ietf.org/agenda/92/slides/slides-92-avtcore-3.pdf Topology and usage: Stephen Botzko asked if the conference server can send its own RTP streams like IVR into the conference session? Paul responded No. Randell Jesup remarked that IVR can be handled via IVR or other mechanism end-to-end. IVR type services can be handled by WebRTC data channels. Chairs remarked that one need to consider any RTP applications, not only WebRTC. Colin Perkins noted that it should clarify this is only for RTP, not other protocols. This as SRTP may not be the only solution. For example, RTP over other security layers like VPN. Paul noted that the draft explicitly excludes data channels. Colin Perkins commented that this assumes centralized switch model, which should be stated explicitly in the draft. David Benham noted that Section 6 specifies this. Some discussion on the name of the central device is called. Some clarification of terminology needed. Trust Model Discussions: Jonathan Lennox asked if you trust the server from making replay attacks? Mo Zananty commented that the trust here means the end-to-end model, but there is also a transport model. Adam Roach asked if we can relay identities through the central device without making assertions through the device? Eric Rescorla noted that if you had infinite bandwidth then you'd not need this system. However, that is not true, so you need these conferencing servers. Therefore the trust is different. Emil Ivov noted that Section 7.3 specifies the central switch assumption. Discussion of Requirement 10: Magnus Westerlund (as Individual) noted that one thing to consider is if a participant can access the media after leaving a conference? Which is what requirement PM-10 covers. Colin Perkins noted that there are two problems: one does the participant have access after they have left and the other is if knows the rooster and deals with reuse of SSRCs (avoid collisions). Slide 10 (selective encryption): Bernard Aboba noted that some RTCP RR, SR, XR would need to be end-to-middle or things will break. RTP header extensions may also need confidentiality. Colin Perkins noted that SDES should not be available for example. Also this information is available in RTP header extensions. Jonathan Lennox noted that middle boxes must be able to add RTP header extensions. There are several requirements for these. Where work will happen: The chairs noted that with the scope this work appears to need AVTCORE WG is not a suitable WG. The chairs have discussed with ADs and propose that efforts are made to create a new WG for this problem and its solution. Charter and scope will be further discussed on the DISPATCH WG mailing list. That work is ongoing on this will be presented in SAAG meeting (Security Area). Eric Rescorla asked if one can we go faster than next dispatch meeting? Cullen Jennings commented that one can propose charter on the dispatch list, approve it on the list. Solution Framework for Private Media ------------------------------------ Paul Jones draft-jones-avtcore-private-media-framework-01 Slides: http://tools.ietf.org/agenda/92/slides/slides-92-avtcore-4.pdf Skipped due to time. Encrypted Key Transport for Secure RTP -------------------------------------- John Mattsson draft-ietf-avtcore-srtp-ekt-03 Slides: http://tools.ietf.org/agenda/92/slides/slides-92-avtcore-6.pdf John asked the WG if there are any objection to including E2E private media in EKT scope? Jonathan Lennox remarked that EKT has been in the progress a long time and not thrilled about delaying EKT further. Dan Wing added that some people are using EKT. Thus, we need to ask clearly on the list. Cullen asked if anyone waiting on the EKT draft to progress to implement it? No response in the meeting. Decision: Will ask the list about adding E2E privacy in EKT scope. --- End of Minutes ----