[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Move TS to optional (RE: Don't remove TS from IKEv2)
- To: ipsec@xxxxxxxxxxxxxxxxx
- Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2)
- From: "The Purple Streak (Hilarie Orman)" <ho@xxxxxxxxxxxx>
- Date: Tue, 26 Mar 2002 16:47:36 -0700
- References: <> <> <>
- Sender: owner-ipsec@xxxxxxxxxxxxxxxxx
- User-agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
Scott G. Kelly wrote:
When people have referred to changing or updating policy within this
thread, what (I think) they refer to is the ability to dynamically
update the selectors associated with a given SA based upon current
protocol state (which might better be referred to as changing the SAD
rather than the SPD). For example, it would be nice to have a rule which
permits FTP explicitly, without opening all TCP ports. Such a rule would
have to allow for dynamically updating the SA selectors based on the
content of the PORT command within FTP, i.e. it would have to rely on
stateful protocol monitoring. Currently, no such support is
standardized.
The question is, should we be trying to solve this here, and if so, how
can it be done? Obviously, any solution has implications for the SPD
first (as we need a way to represent such dynamic selectors there), and
in IKE second, as there would be some associated TS payload(s).
Scott
I've found this use of the term "policy" confusing as well, but
I've become accustomed to using a generalized notion. In the generic
meaning of policy, an SA represents a piece of policy, a rule,
and changing anything about an SA constitutes a policy change.
IKE is a key exchange protocol, not a policy manipulation protocol.
I.e., if it doesn't involve the key, don't use IKE.
What I'd suggest instead is to define the requirements for SA, SAD, and
SPD manipulation and use that as the start of a security policy
protocol. That is one of the goals of the IPSP group, and help with
the requirements is definitely needed. We have evidence from user
protocols and routing showing the difficulty of the current IPsec
methods. It seems time to divide and conquer.
Hilarie