Re: [dispatch] [tsvwg] Connection Identifier Flow Indicator (CIDFI)

On Aug 18, 2023, at 7:48 AM, Tom Herbert <[email protected]> wrote:
> On Thu, Aug 17, 2023, 10:45 AM Dan Wing <[email protected] <mailto:[email protected]>> wrote:
>> Reply-To: [email protected] <mailto:[email protected]>
>> 
>> We have a new proposal for using Connection Identifiers to signal host-to-network and network-to-host.  The CIDs can be QUIC CIDs or DTLS CIDs.
> 
>> 
>> The CIDFI proposal has commonality with the I-D's in the CC line, most of which were presented at IETF117 in TSVAREA, QUIC, DISCUSS, and V6OPS.  CIDFI takes a different approach.  CIDFI does not use UDP trailers, allows the client and server to choose their Connection IDs however they wish, works on IPv4 and IPv6 (including through NATs and IPv6/IPv4 translators), and avoids the network operator's equipment connecting to the content server (which would identify the server to the network operator).
> 
> 
> Hi Dan,
> 
> Thanks for the draft. Offhand it looks this solution provides signaling specifically for QUIC.

CIDFI supports both QUIC and DTLS's Connection ID (RFC9146, "Connection Identifier for DTLS 1.2").  CIDFI was first written for QUIC and I see there are several places where I missed editing the DTLS CID text to be equal with the QUIC CID text.


> Is there a route here for a general solution that could be used across different transport protocols or applications (TCP, SCTP, RTP, custom app protocols in UDP, etc.)?

Yes.

TCP: Short answer:  yes with two new TCP options:  one containing nonces and HMAC-output sent in the SYN, a second option containing Connection ID in each packet for the network to differentiate handling that packet.  Longer answer: It seems achievable with a new TCP option containing a Connection ID in each packet -- as long as sender is using (now ubiquitous) Dont Fragment so the TCP option appears in each TCP packet.  Proving ownership of that TCP 4-tuple would need to be re-worked from draft-wing-cidfi.  Currently the CIDFI specification proves ownership of the UDP 4-tuple by sending a UDP STUN Indication packet on the same UDP 4-tuple as the client/server connection that has a nonce and HMAC-output to proves knowledge of the network element's HMAC secret (reference https://www.ietf.org/archive/id/draft-wing-cidfi-00.html#section-6.2).  This creates the association between the client's connection to its (content) server and the client's connection to the CIDFI network element (e.g., its Wi-Fi access point or their ISP's edge router), so they are bound to each other. For TCP, this same proof could be accomplished by sending the HMAC-output in a new TCP option in the SYN which could be observed by the on-path CIDFI network elements and prove ownership of the TCP 4-tuple.  The SHA256 HMAC output is 32 bytes which consumes an inordinate amount of TCP option space, though, so we would have to truncate the SHA256 or, perhaps, send it in several TCP packets perhaps using option subtypes similar to what MPTCP define (e.g., the entire SHA256 HMAC sent across 4 TCP packets each containing the (shortened?) Nonce and 8 bytes of the SHA256-HMAC output in separate packets).  Afterall, the STUN Indication described in CIDFI's Section 6.2 is just a bunch of bits on the wire that can be easily observed by the CIDFI network element -- putting those same bits into the TCP handshake and the first ~4 TCP packets can prove socket ownership.  After that socket ownership is proven to the CIDFI-aware network element, the CIDFI treatment could confidently begin at the CIDFI-aware network element.  Truncation feels easier than this multi-packet idea, though.  Multiple CIDFI-aware network elements on the path would each need to see their own Nonce and HMAC, so it could be awhile before all of them see their Nonce and HMAC-output.

SCTP: Yes, using a technique similar to TCP, as SCTP has kinship to TCP with its connection establishment.  If SCTP is run over UDP, the CIDFI Nonce and HMAC-output could be sent over a STUN Indication (rather than over SCTP).  As SCTP-over-UDP still has SCTP headers in a known location, the CIDFI-aware network element could peek into SCTP-over-UDP as easily as SCTP-over-IP.

RTP: The RTP SSRC could be signaled in the same way as the QUIC (and DTLS) Connection ID described in draft-wing-cidfi, and the sender could use different SSRCs for different packet 'importance'.  The RTP SSRC is guaranteed unique within a UDP 4-tuple and is in the clear for RTP, SRTP (RFC3711), and avtcore-cryptex (RFC9355).  The complication with using SSRC, however, is RTP stacks handle SSRC with their own output buffer (jitter buffer); a sender switching SSRCs (in order to influence network delivery of those packets) will usually cause the RTP implementation to get confused that a new 'source' is sending.  The RTP stack could in theory be modified to handle this, such that it knew SSRC #A and SSRC #B were, in fact, the same sender and should all be handled as if those two SSRCs were the same.  Another approach for RTP is wait for deployment of RTP-over-QUIC (draft-ietf-avtcore-rtp-over-quic) which does QUIC encapsulation and thus has a QUIC Connection ID.  This would avoid confusing the RTP receiver with different SSRCs, and would only influence the network's packet scheduling.  The Media over QUIC working group (moq) includes interactive media in their requirements, https://www.ietf.org/archive/id/draft-ietf-moq-requirements-01.html#section-3.1 so there will be more RTP-over-QUIC.  My employer is hoping to move our existing proprietary UDP encapsulation to QUIC, for whatever that is worth.

Custom UDP apps:  it would work if they can send a STUN Indication (and discard it on the server) to prove the ownership of the UDP 4-tuple (https://www.ietf.org/archive/id/draft-wing-cidfi-00.html#section-6.2), and can extend their custom protocol so the first few bits can be mapped to their packet importance (high/medium/low priority or whatever mapping is needed).  Ideally those first few bits is a random mapping to preserve the privacy characteristics of QUIC CID's (and DTLS's CID) and CIDFI.  Alternatively, the custom protocol could be moved to run over DTLS-CID (RFC9146) or over QUIC.


> Could the host to network signaling part be a use case of FAST (draft-herbert-fast-06)?

Yes.  A lifetime ago I architected a system that was effectively FAST for multi-path firewalls, but it sent its permission tickets using UDP (rather than IPv6 HbH options).  Cisco shipped it but I don't recall the feature name.  The feature was too early then.

-d


> Tom
> 
>> 
>> Abstract:
>> 
>>   This document describes how clients and servers can cooperate with
>>   network elements so their QUIC and DTLS streams can be augmented with
>>   information about network conditions and packet importance.
>> 
>> As Matt's SADCDN was DISPATCH'd to ART area, I set reply-to to [email protected] <mailto:[email protected]>
>> 
>> editor's copy, https://danwing.github.io/cidfi/draft-wing-cidfi.html
>> published -00,  https://www.ietf.org/archive/id/draft-wing-cidfi-00.html
>> 
>> -d
>> 
> _______________________________________________
> dispatch mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________
art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/art