Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)

[Iñaki Baz Castillo <[e-mail]>]

2014-08-01 3:06 GMT+02:00 Justin Uberti <[e-mail]>:
> On Thu, Jul 31, 2014 at 5:34 PM, Martin Thomson <[e-mail]>
> wrote:
>>
>> On 31 July 2014 15:40, Iñaki Baz Castillo <[e-mail]> wrote:
>> > - For DTLS it means complexity in the sense that a separate DTLS
>> > session/context is required for each "transport".
>>
>> Not really.  DTLS "says" that, but it doesn't functionally rely on a
>> stable 5-tuple in any real fashion.
>>
>> Other protocols that rely on UDP are likely to be similar.  Reliance
>> in name only.
>
>
> Think of ICE as a virtual socket.

I assume you mean "DTLS" rather than "ICE".


> At higher layers, you don't know the
> address of the remote endpoint or exactly how it will be contacted, but you
> know if you send something on the virtual socket it will make it to the
> remote endpoint. That's all DTLS needs to know.

Sure. But for that, in case of UDP, you need a *separate* DTLS
"virtual socket" for each different UDP remote address from which you
receive DTLS packets (you don't want to pass two different ClientHello
to the same DTLS virtual socket, assuming that each DTLS virtual
socket handles a single DTLS session/context, right?).

Well, I will try to explain my concern better:

- Let's assume that peerA is a full ICE agent and announces two host
candidates (due to two interfaces eth0 and eth1 connected to
Internet).

- peerB is also full ICE agent which announces a single host candidate.

- To simplify, both agree on rtcp-mux and so on.

- peerA is the controlling and uses aggressive nomination.

- At some point peerB receives a ICE USE-CANDIDATE in its socket
coming from peerA's eth0 and another ICE USE-CANDIDATE in its same
socket coming from peerA's eth1. Let's name those paths "pair1" and
"pair2", both of them are "valid" (regardless which is the
"selected"/"nominated" one).

- And since it is being said in this thread that "ICE is not supposed
to find a *single* transport path" then peerA sends two different DTLS
ClientHello, one over pair1 and the other over pair2.

- Both ClientHello reach the *same* socket on peerB. If peerB holds a
single DTLS "virtual socket" (this is: a single DTLS session/context)
then the second ClientHello will be discarded by the DTLS session (as
it has already received a previous ClientHello with different seq
number and so on). And it would be difficult for peerB to know whether
it must send back its DTLS generated response packets to peerA's eth0
or eth1.

Is it clear now what I mean?


There are two ways to handle this "issue":

1) Ignore any DTLS packet received over a non selected/nominated ICE
pair (so both peers must compute the same selected pair after ICE
procedures and just use *that* for sending DTLS).

2) Allow DTLS packets received over any valid ICE pair (those from
which the remote peer has sent valid and authenticated Binding
requests with USE-CANDIDATE). For this a separate DTLS
session/context/virtual-socket is needed for each valid ICE pair.



PS: In the text above I'm assuming that peerA initiates two different
DTLS handshakes over pair1 and pair2. In case bullet 2) is the way to
go, may we assume/mandate at least that peerA MUST perform a *single*
DTLS handshake (regardless packets are sent and received via pair1 or
pair2 or via both of them)?



Thanks a lot.





-- 
Iñaki Baz Castillo
<[e-mail]>