[Ipsec] STRAW POLL: Handling of fragments in RFC-2401bis (section 7)

["Theodore Ts'o" <tytso@mit.edu>]

There has been quite a bit of discussion on the ipsec wg mailing list
concerning how IPSEC (The Next Generation) should handle fragmentation
in tunnel mode.  The controversy has been over what sort of support
IPSEC implementations should have for supporting policies that require
the use of different SA's based on the TCP or UDP port of the packet in
question.  Now, to keep things in perspective, I should note here at
this point that it's not clear how many (if any) implementations
actually support per-port SA's in tunnel mode, and if any end-users
would actually find this useful in practice.

The text in question can be found in section 7 of
draft-ietf-rfc2401bis-02.txt.  Method #1 in section 7 describes how
fragmentation in tunnel mode should work in the case when the SA's have
been configured to pass without regard to port number, ICMP type/code,
or Mobility Header type.  This is a fairly simple case, and there is
working group consensus this a MUST implement.  (It also is what I
suspect 99.97% users are using today.)

Methods #2 and #3 describe different ways of supporting the fragments in
tunnel mode when there is a desire to have SA's that differentiate on
the basis of port number, ICMP type/code, etc.  Method #2 specifies that
non-initial fragments should be sent to a separate SA (which is
designated to receive packets with OPAQUE port numbers).   This method
is ideal for high-speed IPSEC implementations (that still want to
support per-port SA's as well as fragments). 

Method #3 specifies that implementation perform what is essentially
stateful fragment inspection so that fragments can be dispatched to the
correct SA.  This method is needed if it is a requirement to enforce
policies where all data sent to certain ports MUST be encrypted, while
all data sent to other ports MUST NOT be encrypt, but perhaps only
integrit protected.

The question before the IPSEC working group is then whether Methods #2
and #3 should be a MAY, SHOULD, or MUST implement.  Since there are
multiple choices before us, let me try to approach this question from a
different directions:


Some people have argued that both should be MAY; presumably these are
people who are not conviced of the utility of having per-port SA's in
tunnel mode.  Others have expressed the belief that at least one of
Method #2 or #3 should be mandatory to implement, so that there is some
way of interoperably way of supporting per-port SA's and fragmentation
at the same time.

QUESTION 1:  Select one of the following

   ____ Both Methods #2 and Method #3 should be a MAY

   ____ One or both of Methods #2 and #3 should be a SHOULD or a MUST

	   ___ Method #2 (non-initial fragments get sent to an OPAQUE
		SA) should be be SHOULD or MUST

	   ___ Method #3 (stateful fragment inspection) should be 
		SHOULD or MUST)

	   ___ Both Method #2 and #3 should be SHOULD or MUST


Another point which has been discussed is how difficult it is to
implement stateful fragment inspection.  Tero has pointed out that his
implementation has supported this for quite some time, and it isn't
particularly difficult.  Steve Kent has expressed a concern that
requiring stateful packet inspection might be too much of a burden for
high speed implementation.  Steve was willing to compromise with a
Method #3 being a SHOULD, since that would still give wiggle room for
implementations to not implement #3.  Others have been concerned that
many other implementations have not implemented stateful fragment
inspection, and it might be too burdensome even to strongly encourage
implementation of Method #3 by making it a SHOULD.

(In contrast, method #2 is very easy to implement, although it is
admittedly less featureful than #3.)

QUESTION 2:  Should Method #2 (non-initial fragments) be: 

	(you may pick more than one)

	___ MUST

	___ SHOULD

	___ MAY


QUESTION 3:  Should Method #3 (stateful fragment inspection) be: 

	(you may pick more than one)

	___ MUST

	___ SHOULD

	___ MAY


Please respond to this straw poll by the end of this week (May 28th).

						- Ted

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