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

[Yoav Nir <ynir@checkpoint.com>]

I'm one of those people who don't see the utility of having per-port 
SAs, so I vote for MAY for both #2 and #3.  I see port selection as 
firewall function rather than an encryption function.

#1 is IMO even better suited for high-speed implementations than #2.  
#2 means that fragments are easy to spot (the distribution of lengths 
and times for the special SA will be different from other SAs), and 
that reveals information that we don't want to reveal.

#3 can be done by many implementations, and I personally would not mind 
seeing it become a SHOULD.  For interoperability, though, I would 
hesitate to send fragments through a per-port SA when I don't know for 
sure that the other side knows how to do stateful inspection.

On May 24, 2004, at 8:15 AM, Theodore Ts'o wrote:

>
> 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


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