[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IPsec and RTP crypto
Agree with Steve. I have seen many customers wanting to control which
applications (dest ports) are allowed to come in IPSec protected,
because if one IPSec peer is compromised, they don't want to receive all
traffic from the now malicious but authenticated peer.
Now you have to decide whether you propose the 5-tuple of the IPSec
policy filter or the particular packet 5-tuple in order to make the most
of the access policy on the responder. In Win2k we chose to propose the
filter 5-tuple so that we could get the best performance (aggregation of
connections across 1 SA pair) out of an all-traffic selector.
I've noticed interop issues where the responder has many overlapping
(various degrees of specificity) 5-tuple selectors. And of course the
configuration difficulty of choosing the right auth method in main mode
when you don't have access to the full selector of quick mode.
-----Original Message-----
From: Stephen Kent [mailto:kent@bbn.com]
Sent: Wednesday, April 04, 2001 4:36 PM
To: Henry Spencer
Cc: IP Security List
Subject: Re: IPsec and RTP crypto
At 7:09 PM -0400 4/4/01, Henry Spencer wrote:
>On Wed, 4 Apr 2001, Michael Thomas wrote:
>> 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...
>
>Correct on the FreeS/WAN part (can't answer for Sun!). This is being
>fixed, although as Sandy commented, we belong to the faction which says
>that you are usually better off just encrypting *everything* -- if only
>because it denies useful information to the bad guys -- unless there
>are truly compelling reasons not to.
>
Port-level SPD selectors, like all other SPD entry selectors, are
part of an access control mechanism, as described in 2401. So, even
if one does elect to "encrypt everything" to a destination, there is
good reason for complying with the standard in this regard.
Steve