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

Re: Policy requirements in Son-Of-IKE



On Fri, 22 Mar 2002, Michael Richardson wrote:

>
> IKEv1 is a policy agreement protocol. It does not negotiate.
>
> There are two ways that we can do with this.
>       1) we can remove all policy from SOI.
>       2) we can improve policy so that we can negotiate in SOI.
>
> There are good arguments for both paths. I strongly believe that we must
> decide this very soon.
>
> If we go with path #1, then we must have a policy discovery and agreement
> protocol. This was supposed to be solved by IPSP WG, but IPSP got forced into
> doing this Policy Schema/PIB stuff. IPSP is only now starting on this. If the
> IPSEC WG wants to go route #1, then we MUST complete the IPSP WG on the same
> schedule. IPSRA work will have to be redone as well.
>
> (The PIB stuff doesn't help at all for inter-domain stuff, and I do not think
>  it even helps for road-warrior/gateway. Maybe I'm wrong. )
>
> If we go with path #2, then we need policy negotiation in SOI.

At the last IETF, Pyda Srisuresh presented a draft he wrote (and I
contributed to) in the IPSP working group. We tried to float this in
the IPsec WG as well, I believe. It seems neither group was
interested. I've placed the expired draft here, in case anyone's
interested:

http://www.employees.org/~vilhuber/draft-srisuresh-ike-policy-extensions-01.txt

I don't think it's QUITE what you're looking for, but maybe there's
some decent ideas there we can incorporate at some point.

jan



> I'm not
> convinced that this will be rich enough to do the kinds of things that SPP
> could do, but it MUST at least satisfy the VPN, remote access needs. It is
> likely that it will satisfy Opportunistic Encryption needs as well.
>
> A method to deal with protocols like FTP (i.e. IRC, H323, SIP/AVP, etc.)
> should be included in the requirements.
>
> (Some gateway discovery protocol like SPP, TED, etc. will still have
> value. A different form of OE can also be created with this kind of thing)
>
> Again, we have to decide on the path to take. This is not a debate about
> the proposals - it is clear to me that the protocol folks will cope.
>
> Cheryl's 01 draft suggests improving policy (#2).
>
> I think that most of the WG is siding with this. Not all.
> It would helpful if those who are in favour of #1 would:
>     1) write drafts (not emails) explaining their view of the world.
>
>     2) review the scenarios in the SOI requirements draft and explain how
>        these things can be done.
>
>     3) join and help review the IPSP work.
>
>
> ]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
> ] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [
>
>
>
> PS: I'm a bit upset that any time was spent on presentations on Thursday
>  morning. We should have spent the high bandwidth time in the small room
>  on discussion about these things.
>
>  I guess I should have read the agenda with more thought and objected to it.
>  I wonder if an official interim meeting in late April would have value.
>

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