Dan,
Hi Alper,
In that case there is no standard way for the AAA server to inform
the
IKEv2 responder of this policy that it needs to enforce. So that
sounds
unworkable.
I guess it can be specified.
The IKEv2 responder already has the mechanisms in place to enforce a
policy
On Wed, Feb 10, 2010 at 3:44 PM, Alper Yegin alper.ye...@yegin.org wrote:
Dan,
Hi Alper,
In that case there is no standard way for the AAA server to inform
the
IKEv2 responder of this policy that it needs to enforce. So that
sounds
unworkable.
I guess it can be specified.
At 12:14 PM +0200 2/10/10, Alper Yegin wrote:
Dan,
Hi Alper,
In that case there is no standard way for the AAA server to inform
the
IKEv2 responder of this policy that it needs to enforce. So that
sounds
unworkable.
I guess it can be specified.
The IKEv2 responder already has
Hi all.
Again we have some more issues:
Issue #147 - Allowing limited retransmission of one-way IKE messages
Either in 2.1 or in 1.5 we should say something about allowing limited
retransmission of the rare one-way IKE
Hi Alper,
On Wed, February 10, 2010 2:14 am, Alper Yegin wrote:
Dan,
Hi Alper,
In that case there is no standard way for the AAA server to inform
the
IKEv2 responder of this policy that it needs to enforce. So that
sounds
unworkable.
I guess it can be specified.
Well yes it
Hi.
This is an interesting subject, and perhaps could be a good candidate for
discussion at Anaheim. However, from the narrow perspective of a VPN vendor, I
don't think this issue is very complicated:
- In the first IKE_AUTH request the initiator provides *an* identity. This
could be