Re: [rtcweb] What is consent?

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Martin Thomson
> Sent: Wednesday, September 12, 2012 8:57 AM
> To: Bernard Aboba
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] What is consent?
> 
> There are a number of things that concern me regarding this.
> 
> Firstly, USE-CANDIDATE can be sent on multiple pairs over time.
> Particularly if the first pair fails for some reason.  Blocking
> nominations after the first would prevent failover, as well as things
> like multipath or confusing cases where there are multiple components
> using the same set of local candidates (c.f., BUNDLE backward
> compatibility scenarios).
> 
> I don't think that USE-CANDIDATE is sufficient or necessary for
> consent.  Nomination is asymmetric in nature; only the controlling
> peer can send it.  The controlled peer has no way to know that the
> nomination check wasn't spoofed.  After all, that is the reason both
> peers send connectivity checks.  The controlled peer then can't attach
> any real significance to the nomination.  That isn't inherently a
> problem - the controlled peer is still making checks and it is those
> checks that verify that the controlling peer is willing to receive
> packets at those addresses.
> 
> However, the underlying concern Bernard alludes to is a real one.  Not
> only does consent indicate that I can send an arbitrary volume of data
> to the checked host, as a natural consequence of ICE checking, there
> is a decent chance that I get a large number of options, all of which
> accept that arbitrary volume of data.

The volume of data is separate from USE-CANDIDATE, though.  ICE does
not currently have a way to indicate bandwidth.  

There was a bandwidth extension for TURN, but it did not achieve
working group consensus and is not in the TURN RFC.  There is
a bandwidth extension to ICE that Microsoft documents and I believe
use in their products, http://msdn.microsoft.com/en-us/library/cc339480, 
MS-ICE2BWM and MS-TURNBWM.

-d

> --Martin
> 
> On 12 September 2012 05:17, Bernard Aboba <bernard_aboba@hotmail.com>
> wrote:
> > On Sep 12, 2012, at 1:51, "Lishitao" <lishitao@huawei.com> wrote:
> >
> > Dan Wing said:
> >
> >
> > For ICE Mobility (draft-wing-mmusic-ice-mobility), we might want to
> > keep other candidates available, but inactive.  Over those other
> > candidates we would not signal USE-CANDIDATE, but we would want to
> > be able to switch to the other candidate as quickly as possible
> > (ideally, switch over immediately).  Similar considerations might
> > apply to multipath RTP
> >
> > [BA] My question is whether the browser has a legitimate reason to
> send
> > media to a destination that is not part of a valid pair for which the
> > nominated flag is set to true, as per RFC 5245 Section 7.1.3.2.4.
> For
> > mobility you can still signal USE-CANDIDATE but not use the pair if
> another
> > pair had higher priority.
> >
> >
> >
> >
> >
> > I donot think rfc 5245 allows this, it only allow only one pair with
> the
> > USE-CANDIDATE attribute present.
> >
> >
> > [BA] But in that case you would want to use the pair, no?
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb