Re: [Ipsec] FW: Remaining issues for IKEv2

[Paul Hoffman / VPNC <paul.hoffman@vpnc.org>]

At 4:02 PM -0700 5/10/04, Charlie Kaufman wrote:
>Not done, recommend reject:
>
>#95 involved having an optional variation of the EAP authentication
>exchange that is two messages shorter. There was limited discussion on
>the list, but most of that was negative.
>
>Proposal by Yoav Nir 4/14/04 to support periodic reauthentication. This
>proposal came after the end of IETF Last Call and would add complexity
>to the protocol. Recommend this be considered as an optional extension
>if anyone is motivated enough to pursue it.
>
>Apparent inconsistency pointed out by Peter Brubmair on 4/30/04 that
>Appendix B talks about five Diffie-Hellman groups but only defines four.
>The fifth was removed in revision -09 because it is defined in
>[ADDGROUP]. The wording could be clearer, but it wasn't obvious how (to
>me), and I don't believe it is technically wrong. Recommend no change.

Agree with you that we should not do any of those three. The first 
two are obvious candidates for extensions if people really care about 
them.

>Need Guidance:
>
>Proposal by Pasi.Eronen supported by Hugo Krawczyk on 3/30/04 to change
>the computation of the AUTH payload. This is yet another "gilding the
>lily" crypto modification. I am confident it adds no cryptographic
>strength to the protocol and it breaks compatibility with anyone who has
>implemented this stuff already, but it adds only trivial complexity to
>the protocol and a trivial computational overhead. In the past, it's
>been easier to just accept these proposals than to argue. One last
>time??

Yes, just accept the change from the CFRG. No one has even gotten 
close to deploying, so backwards compatibility is a complete 
non-issue.

>The question for IKEv2 is: what indication (if any) of fragment handling
>policies should be included in the IKEv2 negotiation. The choices are:
>
>1) None. If the sending endpoint forwards a fragment on an SA
>unacceptable to the receiving endpoint, the receiving endpoint discards
>it and the connection with fragmentation likely fails. This behavior can
>be avoided either by having the endpoints use the same scheme for
>directing fragments or by having the receiving endpoint generously
>accept fragments on any SA that accepts any ports of the protocol.
>
>2) Explicitly negotiate a fragment carrying SA. Add some syntax to
>traffic selectors that allows an SA to negotiate the ability to send and
>receive fragments with unknown port (OPAQUE). This might be supplemented
>with some ability to negotiate whether non-initial fragments can
>alternatively be sent on the same SA as the initial fragment. One
>proposed encoding is a (previously invalid) port range of 65535 - 0 as
>indicating acceptance of non-initial fragments.
>
>3) I'm sure there are other possibilities as well.
>
>My recommendation is (1), with a short explanation of the situation and
>a pointer to RFC2401bis, but I'm open to other options.

Agree with you on (1). It is way too late in the process for us to 
think about the security and design issues for (2), although someone 
can add an extension for it later if people really care about it.

--Paul Hoffman, Director
--VPN Consortium

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec