Re: [rtcweb] Consent alternative

Il giorno Fri, 22 Nov 2013 10:41:07 -0800
Martin Thomson <martin.thomson@gmail.com> ha scritto:

> Actually, this removes some of the complication.  At worst, it just
> moves it.
> 
> This concentrates all of the logic at the DTLS layer.  If you choose
> to treat it so, ICE no longer needs to play any role in determining
> consent.
> 

Apologies for this late comment, but I only now read the draft. I agree
with you that it makes more sense to handle content freshness in DTLS,
especially since, as the draft says, you wouldn't send data until the
DTLS handshake has completed anyway, and this would remove the need
for all those connectivity checks. The only doubt I have is sec.3: is
specifying an ALPN really necessary, if "any DTLS message is
sufficient to refresh consent"? are you envisaging a scenario where it's
the DTLS stack that filters unwanted incoming packets (e.g., SCTP where
you only want RTP), or would it be there for a different reason?

Thanks,
Lorenzo

> DTLS already has a consent mechanism in place (that's the function of
> the cookie in the handshake, a feature we don't tend to use when
> running ICE).   This expands that to include an ongoing process.  The
> only complications come from the interaction between DTLS and SRTP, a
> relationship that is already complicated somewhat on the keying layer.
> 
> I don't know whether anyone implementing DTLS-SRTP also implements
> DTLS renegotiation and EKT at the same time, but those are the areas
> where things get tricky.  Otherwise, you have a DTLS (or DTLS-SRTP)
> layer that manages consent.
> 
> On 22 November 2013 10:08, tim panton <tim@phonefromhere.com> wrote:
> >
> > On 22 Nov 2013, at 09:55, Martin Thomson <martin.thomson@gmail.com>
> > wrote:
> >
> >> I know that I've been a fan of consent via ICE, but with the
> >> decision in Berlin to move to DTLS only, several of us have
> >> observed that perhaps RFC 6520 might be a better alternative.
> >>
> >> We've put together an exploration of the idea here:
> >>
> >> http://tools.ietf.org/html/draft-thomson-rtcweb-consent-00
> >>
> >> The best part of this is that it changes the dynamics (for the
> >> better, I think).  You don't need to send extra packets if you are
> >> actively using the flow.  That means that 1:1 sessions won't need
> >> to spend extra cycles or bytes on keeping the session live.
> >>
> >> There are some gotchas for multiparty sessions, but I believe
> >> those to be manageable.
> >
> > I have misgivings about this - It feels to me to force a mixing of
> > layers in the packet handling - At the moment in the implementation
> > I’m familiar with, the ICE/DTLS/SRTP state machines are almost
> > completely isolated. This proposal seems (at first glance) to make
> > them intertwine in a quite complex way - consent is generated (if I
> > understand it correctly) by any of the layers. Likewise each of the
> > layers needs to know if the others have generated consent granting
> > packets.
> >
> > If we are to blur the boundaries like this, we should go the whole
> > hog and get some real benefits - like for example remove some
> > round-trips in session establishment by (say) carrying the DTLS
> > hello in the same STUN packet as has ICE USE-CANDIDATE set - for
> > example.
> >
> > I’m against including this sort of change at this stage in the
> > standards process.
> >
> > T.
> >
> >
> >> _______________________________________________
> >> 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