Transport and Services Working Group (tsvwg) WG https://datatracker.ietf.org/wg/tsvwg/documents/ 17:30 - 18:30 Monday Session IV (1 hour) Room Name: M3 WG Status and draft updates - chairs RFCs in Ed Queue: draft-ietf-tsvwg-ecn-encap-guidelines Document Shepherd: Gorry draft-ietf-tsvwg-rfc6040update-shim Document Shepherd: Gorry RFCs with IESG: draft-ietf-tsvwg-sctp-zero-checksum Document Shepherd: Marten (writeup) Drafts beyond WGLC: draft-ietf-tsvwg-multipath-dccp Document Shepherd: Gorry (writeup) WGLC expected: draft-ietf-tsvwg-udp-options Document Shepherd: Gorry draft-ietf-tsvwg-udp-options-dplpmtud Document Shepherd: Marten Chairs: Milestone updates - see tracker. The chairs presented the Note Well, Meeting Tips and Agenda. There was no bashing of the agenda. Notices and Related Drafts Liaison notices, if any: 3GPP Liaison Request - (SCTP & DTLS) Gorry GSMA Liaison Request - (MultiPath DCCP) Gorry Chairs: Announcements and Heads-Up Gorry Fairhurst (University of Aberdeen) asked for feedback on MP-DCCP from any people who had previously reviewed an earlier version to confirm the latest revision addresses their technical comments. Greg White (CableLabs) said we are expecting WGLC soon on NQB draft Martin Duke (Google) commented that the sconepro (Secure Communication of Network Properties) BoF on Thursday morning may be of interest to this group. UDP Options 3.1 Joe Touch / Mike Heard (proxy Chairs): UDP Options draft-ietf-tsvwg-udp-options draft-ietf-tsvwg-udp-options-dplpmtud Gorry Fairhurst (WG Chair) asked for volunteers to review the UDp Options documents. Martin Duke (Google) offered to review the draft. C. Heard (via the chat) will also review. A WGLC for this will be announced after the current IETF meeting. WG Differentiated Services & AQM Drafts 4.1 Jason Livingood: Comcast’s L4S & NQB Field Trials Jason Livingood (Comcast) presented a report on the state of LLD and L4S in Comcast’s network. Testing continues; they are expecting to scale to millions of customers by the end of 2024. See MAPRG for a more detailed presentation at this meeting. 4.2 Greg White: L4S Operational Guidance draft-ietf-tsvwg-l4sops Greg White (CableLabs) presented information about how L4S coexists with classic ECN queues Martin Duke (Google): Are the initial L4S deployment experiments done? Greg White: Comcast is the only live network currently running L4S. Martin Duke: We need more operational experience before publishing this as RFC. Stuart Cheshire (Apple): The first success is that Comcast has turned this on without anything breaking. This paves the way for clients to start using it. Apple is working on this. We should reach out to the Linux network maintainers to support Accurate ECN and the Prague congestion controller. Martin Duke: It will be easier to get that done after Accurate ECN is published as an RFC. Ingemar (via chat): I think that it could be good to keep it open. I may have some extra info to share from experiment, just need to see what I can make public. Gorry (as WG Chair): We planned to submit this in November, it seems that we have not seen signs that this needs to be published urgently, and more experience may yet arrive. I think November seems feasible still. Please do comment on the list. 4.2.1 Greg White: L4S Interops 4.3 Greg White: NQB draft-ietf-tsvwg-nqb NQB is now at revision -22, which incorporates the results from detailed review by Bob Briscoe. This draft will require reviewers in WGLC, please contact the editors/WG Chairs if you are willing to review now, or in a future WGLC. 13:00 - 15:00 Tuesday Session II Room Name: Plaza Terrace Room Agenda Recap and Notices Michael Tuexen: Auth Chunks for SCTP draft-ietf-tsvwg-rfc4895-bis Michael presents the scope and status of the draft. Describes the auth handshake and updated key management. Discusses backwards compatibility. John Preuss Mattsson - I think that there should be replay protection. If you do not support it the draft should explain this clearly. Michael - I think the draft does describe this already, please propose wording if not sufficient. Gorry Fairhurst: How long do you think you need to finish this? Michael: The change of formula and HMAC to MAC generalization can be for next IETF. Algorithm updates require suggestions. Or we could go for the algorithms proposed in TCP AO. DTLS over SCTP Design Group Report Magnus presents the design team report. There are three proposals that the DT has examined. All the solutions meet design team technical requirements, the differences have to do with IPR status and completion times etc. Projected ending times: A will bw ready by end of 2024, B will be ready by end of 2024, requires adoption and work in TLS WG . TSVWG will be ready by end of 2024. TLS key update can take up to two years. John Mattsson - People liked the idea of doing this in the TLS WG, they do not like the changes from 00 to 01; especially doing things on the application layer. The consensus was that this needs more work. Discussions on formal verification in TLS WG, probably takes a year by itself. Michael Tuxen: The suggested change from 00 to 01 was due to mailing list feedback, that feedback was different in the WG session. Magnus presents IPR aspects. A has two RAND disclosures, B has defensive declaration with option of RAND, no IPR declaration on C. Martin Duke: No hats, you do your own rekeying thing here, does this require formal analysis? John Matsson - Rekeying in solution B is just DTLS session resumption, nothing new at all. Magnus presents details of the three proposals. Martin Duke: Are there any open source implementations of the legacy DTLS over SCTP implementations. Michael: Yes, openSSL. Martin: So this would impact OpenSSL or whoever implements this? Magnus: B could be implemented in the kernel, but it could be personal preference not to do this. Martin: The effect is on OpenSSL and whoever decides to venture into this. Gorry Fairhurst wants to check that the people in the room agrees with the summary table that Magnus shows on the slide. Magnus: End of 2025 in TLS is very aspirational at this moment. Martin Duke: Has anyone contacted OpenSSL and got their feelings on this? Magnus: No. Martin: I would feel good about A or B if the IPR issue is purely theoretical. It would be an interesting question to answer. Zaheddumann Sarker: We have not talked directly to OpenSSL. The IPR is not purely theoretical. For anyone to implement it they need a licence, there is no way around it. But from open source part, they can implement it, but cannot ship a test client to test it - so therefore we will not do that. Martin: So you cannot deploy this in kernel, because the test client issue? Magnus: There are potential ways to do this. Martin: If we hear that OpenSSL feels that this is not a big deal or if only Ericsson will implement this it would be good. Magnus:The IETF specifies a solution or solutions, 3GPP selects an option, vendors need to implement. Martin: Are your competitors using openSSL then? Magnus: Some. John: Time aspects are the most crucial, 3GPP stresses time requirements. We need to ship this soon. Gorry asks two questions: How important is it to have a non-IPR solution, is it important to have a solution tha does not have IPR? Do people agree with 3GPP time requirements, or can you wait longer? Charles Eckel: Not so much personal opinion. When we talked about timing in 3GPP coordination meeting, the sooner the better is the sense. 3GPP people do not want to talk about IPR. No real sense that it is a concern. Magnus presents the preferences of the design team participants. Martin: Seems like no one will speak up for A as a preferred solution. Magnus: No. Martin: This makes things easier. Gorry asks the room if anyone prefers A to be on the table still. Michael T. If we have a choice between B and C. A and C are similar in the SCTP parts. Whether you see support for B in open source, I interpret that from readhat the answer is no. With defensive IPR this can be implemented in FreeBSD, but I’m reluctant to implement this for single use case if I cant build a solution that can be properly used or tested. Magnus: It is the rekeying. Michael: The rekeying and key management is the interesting part. Martin: Can you implement the kernel part of A? Michael: A and C have identical kernel parts. B can be implemented, but unsure if it is worth it since this is for a single use case that cannot be tested. Martin: I would you prefer A to B. Michael: Maybe… I would implement the kernel part of A. This is my problem with B, I cannot test that it works for the use case, that’s why I would prefer A over B. Hang Shi: Only solution: B can do a single crypto pass. Option B has the performance, and integrating SCTP and DTLS makes it more like QUIC, and QUIC is good. Martin: Who is the TLS implementer on the slide? Magnus: Hannes. Martin: What is he implenting? Magnus: NOTE TAKER missed name of implementation. Johh: Doing security on two layers is more complex and difficult to analyze than doing it on a single layer. Solution B is a single layer. RFC 6083 likely has undetected issues due to the double layers. Show of hands: Could TSVWG go ahead without A? Yes 8, no 1, no opinion 8. 7.1 Chairs: Working Group Discussion of Next Steps Question: Does the wg agree with the requirements from the DT? Yes: 16 No: 0 No opinion: 13 The WG therefore concludes these requirements will be used as the basis. Martin Duke, no hats: Regarding option A, I am still struggling with this, it seems problemetic with IPR constraints in the kernel. I would have voted “no” if I had voted. Magnus: It is implementable, but perhaps not desirable. Martin: Is this not possible to automate tests, etc. MAgnus: You can test, but just not ship. Michael: The code I test with, is the code I publish, that is why I am reluctant. What bothers me is that I cannot test the implementation with an upper layer, since there is a single use case. If there were many UCs it would be different. Tirumaleswar Reddy: For option C the only contention is the TLS implementation. It is a very minimal change to TLS. Two layers of security is anyway happening. John: It is the right decision to move it back to TLS layer. This will impact the key schedule, my expectation is that this will require formal verification before TLS publishes this. Tiru: It will require some verification, but the new keys are derived after the existing are derived, I don not see a change in how formal verification is done. Poll: Are there additional topics for this DT? Yes: 1 No: 12 no opinion: 3 Gorry states that DT has done a good job and that it can be closed. If you thought there was extra work, please contact the chairs. Poll: Is there an appetite to work on more than one solution to this requirement? Yes: 5 No: 12 John: The assumption is that A is scrapped and the assumption is that we go forward with B and C. Gorry: Yes, take this question in the context of progressing B and C. Zahed: we have a hard time to get reviews for SCTP. I would be cautious to go forward with two solutions. Martin: Agree with the concern on group bandwidth. The real issue is in-interoperable specs. If Ericsson boxes do one thing and everyone else does something else we have failed. Magnus: We do this work for a solution to 3GPP. Martin: The hypothesis is that one important player does A and other do C. What happens if we publish two solutions. Magnus: 3GPP picks one. Tiru: We should focus on picking one. We can do interop at hackathon as well. John: Answer to Martin, in the room there was also support from Huawei for B. 3GPP went for B in its answer. Zahed: When 3GPP gave their answer solution C did not exist. Chair (Marten Seeman): I would like to stress that moving forward with two documents now does not mean we must publish two RFCs. John: As long as we have not heard anything new from 3GPP we can only go by what they have said. And the indication we got is that the timelines are the most critical aspect from 3GPP. Martin: Clearly we can continue working on both drafts, I hope we can develop some criteria. Maybe someone can come up with a list of questions that needs to be answered. I would nominate OpenSSL to provide this list. Magnus: Involving OpenSSL, isn’t it already very clear what their anwer is? That they won’t do anything with IPR. Martin: If you are confident that they do not do B, the only way there will be two implementations from this is that someone implements this from scratch. Tiru: It would be good to involve openSSL to get their view. It is not clear how 3GPP would review these documents, we cannot do prioritization here, how could we rely on some other group to do techical evaluation. Magnus: An alternative is to tell 3GPP to do this themselves. Martin: 3GPP has many stakeholders and customers. So we could ask them, do you want this now or later with more options? We should ask our customer that is 3GPP. Gorry: Chair hat, let’s tidy this up quickly. Tiru: I am not sure how option B is technically superior, have not seen any such analysis. All three options meet requirements, no clear winner. Magnus: That was Marin’s personal view, I agree. Tiru: That analysis still needs to be done. Martin: this was not a strong view. John: B is simpler. I’m surprised that htere is so much discussion on IPR. We’ve seen that our main customer does not seem concerned about this. Gorry: We could be clear that these specs are for 3GPP only, the WG needs to think on whether that is important - or whether there is a need for DTLS for other usage of SCTP in the Internet. This could motivate progressing two specifications, we need to decide. In summary, we have made significant progress with lots of input. 7.2 SCTP Drafts (next steps and plans) 7.3 Magnus Westerlund: DTLS protection for SCTP draft-ietf-tsvwg-dtls-over-sctp-bis draft-westerlund-tsvwg-sctp-crypto-chunk draft-westerlund-tsvwg-sctp-crypto-dtls 7.4 Michael Tuexen: DTLS protection for SCTP draft-tuexen-tsvwg-rfc6083-bis draft-tuexen-tsvwg-sctp-ppid-frag No presentations Other Transport Drafts 8.1 Nicolas Kuhn/Gorry Fairhurst: Careful Resumption of CC draft-ietf-tsvwg-careful-resume Gorry presents updates between -05 and -06. Displays QLOG definition, likely the first QLOG spec outside the main QUIC specs. The QLOG part of the spec will likely change. Presents changes between -06 and -07. Expect ready for WGLC at next meeting: Lucas Pardue: Regarding QLOG, we have been working on the issue about extensibility and how documents like this can extend the QLOG schemas. We’ll be talking about this at QUIC. We would like to clarify issues around this before a document goes to WGLC. Marten: Excited to see QLOG here. Did you use Cloudflare or Google Quiche. Gorry: It’s a fork of Lucas’ implementation. Lucas: That’d be Cloudflare Quiche. Individual Drafts WG Chairs requested the authors if these individual IDs to focus on the requirements, and whether the IETF can provide guidance for host to network signalling for this set of scenarios. 9.1 John Kaippallimalil: Requirements for Metadata draft-kaippallimalil-tsvwg-media-hdr-wireless Magnus: You say that you get random drops. The link layer can repair loss. Isn’t the most likely issue that you cannot deliver in time? John K: Yes, this is a simplification. Abishek: About the server conveying burst size to network, how does that work with live video? You might not know about the complexity of the video that’s ingested. John K: If it is providable it’s good, very useful for scheduler, but if it cannot be provided, we should not do it. Zahed: How much of this has been discussed with Media folks, like MOPS? John: This is something we would like help on, we would need feedback on this. There have been many discussions between SA2 and SA4 in 3GPP on this. Zahed: We need input from Media experts here in IETF, MOPS and AVTCORE and so on. Ingemar J: I have a question on slide 3. Do you talk about fast fading and try to keep the queue low? I think it’s a tall order to cope with millisecond issues, do you intend to drop packets? John: The idea is not to drop packets, this is to give information to scheduler to make better decisions. Ingemar: I am not sure how this fits to 3GPP specifications. John: This should be useful for more accesses than 3GPP. Specner: Answering Zahed about where else this has been talked about. People in MoQ are shooting at a longer timeframe for feedback than what this draft is talking about. In 3GPP they’re mostly talking about RTP. Tianji: I have been working with the same thing from the both IETF and 3GPP side. This is important work, I hope for a fast track to adopt this. 9.2 Mohamed Boucadair: Signalling Use Cases ietf draft-rwbr-tsvwg-signaling-use-cases.html Med provided a very quick summary of the draft and analysis of the signalling for another use case. Gorry: We’ve seen many presentations like this over many meetings. It’s important to understand the requirements and what the scope should be if we were to take on things like this. You and John might wish to work on a common document? John K: These use cases are complementary. This is client to network, our is application to network. The requirements are different. Gorry: Sorry, to be clear: I am not asking for one set of requirements or solutions. But, a common document to talk about various scenarios, concerning trust, transport. This would also be useful to guide what sorts of metadata is needed or useful. - End of meeting -