[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

IPsec and RTP crypto




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.

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.

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.

		Mike


Follow-Ups: