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

IPSEC WG vs. IPSP/ISPRA WGs (Re: phase 2 and ports)



andrew.krywaniuk@alcatel.com wrote:
> The use of a policy payload isn't such a bad idea, since it appears that
> ISAKMP would be merely functioning as transport (opening up giant can of
> worms based on same argument re. XAuth). Negotiation isn't really the best
> word though (as one of the presenters at the last IPSP meeting pointed out,
> it is better to simply take the union of the two security policies instead
> of attempting to negotiate a common ground).
> 
> What concerns me is that if we created a policy payload, we would also have
> to define an encoding scheme, and to make the payload meaningful we would
> have to create such a behemoth that we would be duplicating a large
> percentage of the work that IPSP is already doing.

So, IPSEC WG doesn't wish to change anything in IKE because it doesn't want
to specify everything, and IPSP WG probably is not allowed to change anything
in IKE because it's IPSEC WG's job. Sounds a lot like IPSEC WG vs. IPSRA WG.

How about IPSEC WG does the following:
1) Specify *exactly* how the different identity types are used 
   in different phases of IKE. Write this in some standard RFC.
2) Specify a policy payload without specifying any of its contents.
   Specify exactly how/when the policy payload may be used. "The policy
   payload is passed to a policy module, the policy module responds
   OK, NOT OK... this affects IKE negotiation as follows.. blah.."
   Write this also in a standard RFC.

The IPSP WG would then
3) Write a standard RFC describing the contents of the policy payload,
   and what the contents mean.

Of course, this would apply only to a part of the things IPSP WG 
is attempting to do. Most of the things are probably served better
by another protocol, but some would be better served by changing IKE.
Currently IPSP WG cannot even consider if changing IKE would produce
a better result.

This same payload could also be used by IPSRA if it can be exchanged 
in phase 1. It could represent some of the following options: 
"after phase 1 client MUST initiate an IPSEC SA to a DHCP server
in order to get attributes", "I am the big nasty GW, I will initiate
an XAUTH towards you after phase 1", whatever. The point is that 
IPSEC WG doesn't need to decide on these issues. Let the proper
WGs decide them.

-- 
Ari Huttunen                   phone: +358 9 859 900
Senior Software Engineer       fax  : +358 9 8599 0452

F-Secure Corporation       http://www.F-Secure.com 

F-Secure products: Integrated Solutions for Enterprise Security


Follow-Ups: References: