[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 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.
>
I think there seems to be some confusion. This was discussed in
the context of piggybacking binding updates (IPv6 destination
option) instead of sending binding updates all by itself.
If it is the latter, there is no issue as you can have a policy
that says "Protect binding updates" (it is a different issue
that there is no selector for a specific destination option).
Piggybacking is an issue because binding update protected
using AH may not be accepted on a TCP connection that
accepts clear packets.
Assume you have a policy that says "Protect with AH all packets
from host A to host B destined to port 23". This means you
can't send clear packets once in a while for packets destined
to port 23. Similarly the converse is true. If there is no
policy at all, then you can't send a AH protected packet (binding
update) once in a while. It will be dropped.
-mohan
> 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
References: