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

[Michael Tuexen <[e-mail]>]

On 12 Oct 2014, at 17:28, Harald Alvestrand <[e-mail]> wrote:

> On 10/12/2014 03:30 PM, Michael Tuexen wrote:
>> On 12 Oct 2014, at 12:18, Harald Alvestrand <[e-mail]> wrote:
>> 
>>> 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)
>>> - manage SCTP congestion control independently on the two legs (because
>>> that's how SCTP works)
>>> 
>>> I don't see the reshuffling of packets between channel numbers to be an
>>> excessive *additional* burden.
>> I agree CPU wise. But I have a question: Don't expect both endpoints of a
>> data channel to see the same "id" attribute? And isn't this attribute
>> the stream ID? So can conceptually a middlebox map the streams IDs?
> 
> The two ends don't see the same identity either, so the middle box is not transparent.
OK. So this means that the ID defined in 
http://w3c.github.io/webrtc-pc/#widl-RTCDataChannel-id
doesn't have to be the same on both ends, right? It would be useful
to make that clear in the document. I always assumed that they are the same
on both ends...

Best regards
Michael
> 
> The application has to know the middle box is there. So it has to be written to deal with differing numbers at the two ends too.
> 
> 
>