[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPsec and RTP crypto
Mike,
>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. I'd like
>to actually get some clarification on this because
>it seems like a pretty serious restriction for
>VoIP.
I am surprised to hear Jeff reported as saying what you cite above.
IPsec has facilities to allow selective protection of traffic between
two hosts or two sites, based on appropriate population of the SPDs
at each end. So long as one can specify the traffic to be protected
and not protected using the selectors employed in SPD entries, this
should work fine.
>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. A
>similar set of considerations (but not indentical)
>is true for MEGACO, and may be true for RTSP as
>well.
Traffic sent over dynamically selected ports are not readily
accommodated by the SPD selectors as currently defined. We had a
facility that would accommodate a range of ports, much as we
accommodate a range of addresses, but we had to drop it because IKE
could not negotiate the facility. However, discussions about
son-of-IKE capabilities have included adding back this facility. So,
if you can define a range of ports within which the RTP/RTCP
connections will be negotiated, then IPsec with son-of-IKE could
handle them.
>But... now I'm hearing that this is pressing my
>luck and that it's a questionable use of IPsec to
>desire such a pedestrian combination?
>
>Please tell me that this is not true, because if
>IPsec doesn't have the ability to be more
>discriminating in transport mode, it has really
>missed one of the key abilities needed to build
>end to end crypto systems *and* save a million and
>seven non-security working groups from having to
>constantly roll their own crypto schemes which
>they inevitably screw up.
The discussion above applies to both transport and tunnel mode.
Steve
Follow-Ups:
References: