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

Re: IPsec and RTP crypto

Stephen Kent writes:
 > 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.

   Just as a note, this was the minutes. I don't 
   recall Jeff putting it in those exact terms,
   but my memory isn't perfect either.

 > >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. 

   If, say, I had an SPD entry which was specific to
   port 5060 with a wildcarded source address, this
   should work in theory, right? The RTP and other
   stuff that you don't care about would just pass
   through to the IP stack, right?

   I seem to recall Bill Sommerfeld making similar
   remarks as Jeff about Sun's stack and I think
   I remember that Freeswan doesn't have the ability
   to filter off of ports yet... So part of my
   question is really whether reality is anywhere
   close to theory too.

> 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.

   Yes, port ranges would be a very nice feature,
   though a sufficiently giant SPD could express
   the same thing though, right?

	    Mike
Follow-Ups: References: