Re: [Ipsec] FW: Remaining issues for IKEv2

["Theodore Ts'o" <tytso@MIT.EDU>]

On Mon, May 10, 2004 at 04:02:13PM -0700, Charlie Kaufman wrote:
> 
> 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??
> 

I've looked through both archives and the VPNC mailing list, and I
can't find this proposal.  Was it actually sent to the entire ipsec
mailing list?  In any case, I tend to agree with previously expressed
sentiments that absent a very strong, compelling need to make changes
in the crypto core of IKEv2, it is long past time to shoot the
engineers and ship the product.

> Handling of OPAQUE. (#96 and #98). An agreement has been reached on the
> handling of fragments in RFC2401bis, but it's not obvious how to reflect
> that agreement in IKEv2. My (perhaps oversimplified) understanding is as
> follows:

What consensus we have for fragment handling is described in section 7
of draft-ietf-ipsec-rfc2401bis-02.txt, which describes multiple
approaches, some of which will be mandatory and some which will be
optional (although we do not consensus on whether the optional
approaches should be "MUST", "MAY" or "SHOULD").  Since one of the
approaches requires the use of the OPAQUE encoding, my suggestion is
that we define OPAQUE in ikev2, possibly using the reversed 65535-0
range as you mentioned earlier, and then include a pointer to
RFC2401-bis.

Before anyone points this out, I agree that it's unfortunate that we
have had to settle for documenting multiple approaches to handling
fragmentation, since this represents an unfortunate complication of
the standard.  The problem fundamentally is that different potential
users of IPSEC have expressed different constraints.  Some folks,
exemplified by Steve Kent, have talked about a desire to use
high-speed IPSEC engines, where mandatory stateful inspection of
fragments would be a major performance problem.  Others, such as Tero
Kivinen, want to be able to enforce policies where some all data sent
to certain ports MUST be encrypted, while all data sent to other ports
MUST NOT be encrypted, but perhaps only integrity protected.

Unfortunately, we aren't quite done with the fragmentation issue, as
the area where we do not have conensus js whether the various
approaches should be tagged MUST, MAY or SHOUD.  We seem to all agree
that Approach #1 should be a MUST, but there was at best very rough
consensus of #2 being MAY and #3 being SHOULD.

So what I propose to do to move this forward is to hold a straw poll.
Of course, 75% of the work of holding a straw poll is to determine the
correct questions to ask.  So what do people think of the following
formulation:

	Which of the following requirements woudl you be willing to live with?
	(You may select more than one):

	A)  Method #2 (fragments to a separate SA) is a MUST
	B)  Method #3 (stateful fragment inspection) is a MUST
	C)  Both #2 and #3 is a SHOULD
	D)  Method #2 is a MAY, Method #3 is a SHOULD
	E)  Method #3 is a SHOULD, May #2 is a MAY

As I mentioned, there seemed to be someone rough consensus over D: #2
as MAY, #3 as SHOULD, but it was by no means unanimous.

						- Ted


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