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

Re: SOI: selector exclusion lists/ranges

A while ago P. Srisuresh and I proposed a new ID payload. We're still trying
to find a home for this draft (draft-srisuresh-ike-policy-extensions-01.txt,
which has expired). It has two features:

- A more cisco-acl-like syntax in the ID payload to better "express
  yourself".

- A mechanism by which you can dynamically add and remove policy from an SA,
  which is useful for things like voice traffic or even simple ftp, where you
  want to add certain ports (or IP addresses if you have need for this) to
  the SA which the application dynamically allocates.

The consensus by the Chairs was that this was changing IKE, and therefore
shouldn't be discussed (I think).

If there's interest, we can revive the draft or use bits and pieces of it to
incorporate into ikev2. I think Pyda is trying to the ipsp (policy) route
with this.

jan



On Tue, 27 Nov 2001, Michael Thomas wrote:

> 
> A while back I think we had a discussion about
> IKE's inability to express port ranges for
> selectors. I have an admittedly parochial desire
> for this feature because I'd like to have the
> ability to protect all traffic to a node except
> where I'm protecting things at application layer,
> ala SRTP. Currently, the only way to do that would
> be to enumerate every port that you want
> protected; with 65k ports, that's a bit hard to
> swallow. In reality, I really don't think this
> ability is all that unique when you think beyond
> IKE/IPsec as being a VPN establishment mechanism;
> other things are surely in this situation. Indeed,
> this may be one way to fix the current implicit
> meaning of an IKE selector which is "everything
> but port 500". Since KINK will also have a well
> known port for key management, this would give the
> implementation an unambiguous way to express
> whether it wants other key management protocols
> inside or outside of the selector.
> 
> Thus I think we should have a requirement which
> states:
> 
> "The protocol MUST have the ability to express
>  port ranges for flow selectors, as well as have
>  the ability to selectively enumerate ports which
>  fall outside of the flow selector."
> 
>       Mike
> 

 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847
References: