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

Re: IPsec and RTP crypto

At 8:45 AM -0700 4/4/01, Michael Thomas wrote:
>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?

You have not said anything about the other selectors, so this is not 
a completely well-formed question. is the protocol selector is set to 
UDP? if so, a compliant implementation would use such an SPD entry to 
match all traffic to that port from any port on any source host to 
any destination host (assuming the dest address is also wild carded.

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

I can't say what non-complaint implementations do. I have seen 
implementations that do support port-level selectors, e.g., 
Checkpoint and Microsoft come to mind.

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

right. One could create individual SPD entries covering all the 
relevant ports, but with wild card entries for other selectors, as 
appropriate.

Steve
References: