Re: [rtcweb] Last Call: <draft-ietf-rtcweb-data-channel-12.txt> (WebRTC Data Channels) to Proposed Standard

["Wyss, Felix" <[e-mail]>]

> Given that the middle box has to:
> 
> - decrypt and encrypt all packets (because the keys are different)
> - assert its own identity towards both endpoints (because otherwise DTLS doesn't work)
> - be trusted by both endpoints (otherwise it's a MITM attack by definition)
All these are not relevant with respect to how the SCTP packets get from one WebRTC endpoint to the other.  That's really all the data channels care about.  The rest is opaque to them, assumed a given and the concern of other layers in the WebRTC stack.

> - manage SCTP congestion control independently on the two legs (because that's how SCTP works)
Can you please elaborate on why you believe that's required?  As I understand it, from SCTP's perspective in WebRTC DTLS represents the IP layer.  Doesn't that mean congestion control is strictly above DTLS and SCTP should not care about how many hops its packets go through and whether any of these hops decrypt/re-encrypt the packets or pass them on as-is? 

> I don't see the reshuffling of packets between channel numbers to be an excessive *additional* burden.
I respectfully disagree as it adds unnecessary complexity.  Michael furthermore has made a good argument on why it's not that simple.  To add to his concerns: are we certain that none of the application protocols using the data channels will ever reference stream IDs of one SCTP stream in the data of another SCTP stream?  If that ever were the case, the middlebox would have to understand these application protocols and rewrite the stream data, not just the SCTP packets. 

I furthermore have still not seen a convincing argument for requiring this abstraction leak from the lower level by using the DTLS role for something unrelated to DTLS' purpose.  Whether an endpoint started as server or client is completely irrelevant to the payload data transported over it.  While it may be a seemingly convenient hack to avoid explicit conflict resolution, abstraction leaks like that invariably have unintended consequences--as we can see here.  

> The kind of "middle box" that "just shuffles bits" while doing something to them or with them in addition doesn't exist in the WebRTC context.
Well, then it should.  I presented a use-case of a middlebox that records and/or performs analytics of the WebRTC session media.  That is a common application in VoIP. 

--Felix