Some IKEv2 issues

[Tero Kivinen <kivinen@iki.fi>]

I reread most last couple of months ipsec-list traffic, just checking
if we have lost some issues about IKEv2. I did found some cases where
there was some change to IKEv2 document, which I still might be open.
Some of those haven't received much comments in the ipsec lists, in
some cases the discussion lead to another cases, which consumed and
hide the original issue (EAP and public key authentication).

I think people should check those issues out, and comment about them. 

----------------------------------------------------------------------

http://www.vpnc.org/ietf-ipsec/mail-archive/msg02719.html

Pasi Eronen's comment about the EAP and creation of the AUTH messages.
The current draft says that we send EAP AUTH payloads when we have
enough information to compute the key". Pasi says that in some EAP
methods it is not that simple (i.e. does not know which is the last
message, and the key depends on all messages etc).

His proposal is to basically add new round trip, i.e first finish the
EAP completely (i.e responder sends EAP(success), and the initiator
sends AUTH payload, and then responder finishes the IPsec SA creation
(AUTH, SAr2, TSi, TSr payloads). 

[I think the easiest way out from here is to add one round trip, then
it will work with any EAP library and method etc]

----------------------------------------------------------------------

http://www.vpnc.org/ietf-ipsec/mail-archive/msg02701.html

Some issues from Charles Lynn:

	1) Clarification of the ICMP type and code encoding in TS.
	2) Say how OPAQUE is encoded (start = max, end = min ???)
	3) Add text about unidirectional policies (i.e where packets
	   only go to one direction, like ICMP).
	4) Fragment only SA, and non-initial fragments

[Point 1 is simply clarification, in point 2, I think it should be
start = min, end = max, not other way around, point 3 might actually
need some clarifying text, and the point 4 should be left out, as
fragment only SAs (issue 81 and 49) in RFC 2401 was rejected, i.e.
there is no need to change anything in the IKEv2 document because of
that]

----------------------------------------------------------------------

http://www.vpnc.org/ietf-ipsec/mail-archive/msg02695.html

TFC padding in ESPv2, i.e. do we add notify in IKEv2, or simply state
that using IKEv2 indicate that TFC padding is ok.

[I think we should simply add new notify to IKEv2.]

----------------------------------------------------------------------

http://www.vpnc.org/ietf-ipsec/mail-archive/msg02607.html

My own note, that we need to have udp-encaps and nat-reqts drafts as
references to the IKEv2 (udp-encaps as normative, and nat-reqts as
non-normative).

[No comments, :-]

----------------------------------------------------------------------

http://www.vpnc.org/ietf-ipsec/mail-archive/msg02514.html

and

http://www.vpnc.org/ietf-ipsec/mail-archive/msg02538.html

Pasi Eronen's comment about the using of EAP without public key
authentication, when using EAP method which provides mutual
authentication and shared key.

[There was long discussion in the list, couple of people saying, yes
we should do this change, couple saying no, we must disallow
explicitly EAP without public key authentication. Current draft
explictly disallows EAP without public key authentication. This
discussion was lost when we started talking about the keys used to
generate those AUTH messages (another issue now still up).]
-- 
kivinen@safenet-inc.com