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

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.

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.

On 10/11/2014 06:58 PM, Wyss, Felix wrote:
>>> Yes, it does. I think the worry is that the middle box may end up as DTLS server to both legs.
>> And why can't the middle box avoid this?
> How can it if it is the offerer on both legs?  From RFC#5763, section 5 (page 10): "The endpoint that is the offerer MUST use the setup attribute value of setup:actpass and be prepared to receive a client_hello before it receives the answer."
>
> The answerer thus gets to pick whether it is the client or server.  As mentioned in my original message, the answerer picking client is desirable as it can speed up the DTLS negotiation.  So almost invariably the middlebox will be DTLS server on both legs.
>
>
>>> That leaves both endpoints as DTLS clients. This then breaks the
>>> odd-even split and risks the endpoints allocating the same stream numbers.
>> I think "risks" is the wrong term here. I guess they will run into this almost always.
> Not necessarily if the endpoints draw their IDs at random.  That makes this particularly problematic as everything may appear to work fine but then fail intermittently in the field due to collisions.  
>
> --Felix
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Surveillance is pervasive. Go Dark.