[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPsec and RTP crypto
Bill Sommerfeld writes:
> > Jeff Schiller according to Basavaraj Patil's
> > minutes (mobile IP WG chair) quotes Jeff as saying
> > that IPsec is not really a good fit in situations
> > where you want to protect some of the traffic, but
> > not all of the traffic to another host.
>
> IPsec is a poor fit when you only want to protect some traffic of a
> particular flow (e.g., only packets which contain passwords, or only
> the packets with a mobile ip binding update).
Thank you (and Mohan). I thought I remembered a
subtlety to this that wasn't captured correctly
in the MIP minutes.
> > Consider a simple SIP VoIP client. It exchanges
> > UDP SIP traffic on a well known port and RTP/RTCP
> > traffic on a dynamic set of ports. You would like
> > both to be secure, but you'd really, really like
> > the RTP traffic to do payload crypto so that it's
> > friendly to header compression schemes. You can't
> > use TLS because you'd like to use UDP. So what's
> > left of the usual suspects? IPsec for the SIP.
>
> All of the IPsec implementations I'm familiar with can handle that.
Great. This was, as they say, a sanity check.
> If both source and destination ports are dynamic, the best way to
> approach this is to have the RTP/RTCP implementations on each end
> specify per-socket policy on their endpoints.
That is the case with RTP. Each side decides
which ports it wants to receive on and is
typically transmitted in SDP (or h.245, I
'spose).
Mike
References: