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

RE: Do we actually need dynamic ports?



Markku, your rant from yesterday was *way* off base. I thought people had
successfully explained why, but apparently not.

Just as there is a distinction between a key management protocol and a key
agreement protocol, there is a difference between a policy management
protocol and a policy agreement protocol. IF, as it seems to be the case,
people want to create port/protocol constrained-SAs (I have argued against
this many times, but it seems that I am always outvoted), then there needs
to be a way to agree on the selectors that are being used.

When I say I want to add selector X to an existing SA, I am not asking you
to open up a security hole. I am saying something like "I believe that we
have opened up an FTP session on port X and I want to protect it." You
should be able to decide, based on local policy, whether you accept the
widening of the SA. And note that 'widening' does not necessarily imply a
range of ports; it could simply be a list of non-contiguous ports that does
not cover your precious RPC traffic.

So I am not asking you to add new rules to your SPD. I am asking you to
create an instantiation of a template rule which already existed in your
SPD, and which is subject to dynamic session data. I would argue that this
could be accomplished more cleanly by a non-interactive policy agreement
protocol (e.g. send a list of the rules you will enforce, rather than a TS),
but you can't ignore the issue altogether.

Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.



> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Markku Savela
> Sent: Wednesday, March 27, 2002 2:11 PM
> To: vilhuber@cisco.com
> Cc: paul.hoffman@vpnc.org; ipsec@lists.tislabs.com
> Subject: Re: Do we actually need dynamic ports?
>
>
> > From: Jan Vilhuber <vilhuber@cisco.com>
>
> > > Those aren't the options. The options are "FTP" or "all
> ports".  "All
> > > ports" is understandable.
> > >
> >
> > Yes, but may not be what the local security policy OUGHT to be. It's
> > too wide.
>
> But, the question is: how is this widening going to happen? If it is
> some message which IKE receives from the other side "add this port to
> this SA", then we effectively have "all ports open".
>
> Say I have policy
>
>   remote_port=21 -> FTP_SA
>   remote_port=111 -> RPC_SA
>
> now I connect to some site with FTP, and this hostile site "widens"
> the FTP SA to allow traffic with port=111. Now, this other random site
> suddently has full access to my RPC stuff... Not GOOD!
>
> If there is any widening, it must be happening under control of my
> host (and even then there is a difficulty of verifying that this
> automatic widening does not open up any other holes...).
>
> => I'm still of opinion that any automatic messing with policy
> selectors or policy specifications is dangerous.
>
> At least, if you do that, you have to convince that operation does not
> open any security holes in any situation.
>
>
>
>