[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: