[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [AVT] RE: KM approach using MIKEY and EKT
> >Well, when there is an attacker who blocks the SIP answer
> (because it
> >would reveal that there is a man-in-the-middle), then the time in
> >which the session would be unauthenticated is probably
> determined by
> >the SIP timer expiration. Of course, if that would take too
> long, we
> >could add in a new timer just for the purpose of bounding
> the amount
> >of time that we'd allow a session to go on without any
> That assumes auth-via-SIP as opposed to media channel. By
> "ACKed by the other side" I meant media-channel-ack, not SIP
> ACK. In either case, though, an optional (user-configured)
> separate timer makes sense.
[stf] I'm not sure if I understand the usecase here. I thought as long
as early media is sent the caller cannot send media back as he does not
have the right address information as long as the signaling answer is
> >> m=audio 1234 RTP/AVP 96 97
> >> a=rtpmap:96 PCMU/8000
> >> a=ftmp:96 in-media-keying:true
> >> a=rtpmap:97 PCMU/8000
> >> RTCP is conceptually simpler. Older implementations not
> >> it isn't an issue (you're not going to negotiate
> encryption with them
> >> anyways).
> >That's a good point.
> You can also combine RTCP with RTP headers - if RTCP doesn't
> get through, send in RTP headers (maybe do both anyways). If
> that doesn't get through, then fall back on
> signalling-channel (SIP) or give up (depending on how much
> you trust signalling channel security).
> >> The biggest issue would be with NATs, relays and B2BUAs that might
> >> block or modify RTCP, and SIP servers that might remove
> a=rtcp SDP
> >> lines (or not correctly update them in an SBC).
> BTW, I speak from experience here.... And Ugh is right. :-(
> A major VoIP carrier doesn't support RTCP at all, and others
> have 'issues'.
> Randell Jesup, Worldgate (developers of the Ojo videophone),
> ex-Amiga OS team rjesup@xxxxxxxxx