[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [AVT] RE: KM approach using MIKEY and EKT
Hi Randell,
> >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
> authentication.
>
> 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
missing.
Regards
Steffen
>
> >> 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
> supporting
> >> 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).
> >
> >Ugh.
>
> 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
>
>