Minutes IETF119: tsvwg
minutes-119-tsvwg-00

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 -