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

Re: IPsec and RTP crypto



Bill Sommerfeld wrote:
> 
> > 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).

There's a reasonable argument, though, that the best way to protect a small
part of your traffic is to encrypt as much of the total traffic as possible,
not just the part you want to protect.

If you only encrypt "some traffic of a particular flow" you may give an
eavesdropper information useful in traffic analysis. Certainly you help him
target a cryptographic attack. He knows what packets are of interest; the
ones you've encrypted.

There are additional problems if you encrypt only control packets such as
mobile binding updates. For one thing, any enemy who reads the RFCs may
know quite a bit about their structure, which makes many cryptgraphic
attacks easier. Also, even without breaking the crypto, he may get enough
information from the pattern of these packets to make some denial of service
attacks easier.

In general, I think this argument holds. I see IPSEC's ability to select
packets for encryption by complex rules as an unnecessary complication in
most situations. The sensible thing is to encrypt everything passing
between two gateways.

Mobile devices may be an exception, since they have rather limited resources
in many cases. 

> > 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.
> 
> 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.
 
Or, if you have the resources, just encrypt everything.


References: