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

From: "Theodore Ts'o" <[email-masked]>
Date: Mon, 24 May 2004 01:15:21 -0400

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Mon, 24 May 2004 12:01:58 +0300

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.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 24 May 2004 12:01:58 +0300

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 24 May 2004 15:55:48 +0300

Theodore Ts'o writes:
>    _X_ One or both of Methods #2 and #3 should be a SHOULD or a MUST
> 	   _X_ Method #3 (stateful fragment inspection) should be 
> 		SHOULD or MUST)
>
> 	_X_ MAY
> 	_X_ SHOULD

Or the proposal from Paul that implementations SHOULD support method
#2 or method #3 (or both). 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 24 May 2004 15:55:48 +0300

---

From: "Scott G. Kelly" <[email-masked]>
Date: Mon, 24 May 2004 09:35:40 -0700

> 	   ___ Both Method #2 and #3 should be SHOULD or MUST
For implementations supporting port/protocol SA differentials, Method #3 
should be a SHOULD or MUST.

> 	(you may pick more than one)
NONE of the above - why even mention this? I doubt there are many 100% 
compliant implementations for the first round of ipsec, and find it 
highly unlikely that this will change. Implementations that don't care 
about fragment security probably don't care about port/protocol 
differentiation. The two seem incompatible and unlikely. I can't believe 
we've wasted so much time/energy on this.

> 	(you may pick more than one)
SHOULD.

---

From: Mark Duffy <[email-masked]>
Date: Mon, 24 May 2004 17:42:03 -0400

>QUESTION 1:  Select one of the following
Yes -> ___ Both Methods #2 and Method #3 should be a MAY

>         (you may pick more than one)
Yes ->  ___ MAY

>         (you may pick more than one)
Yes ->  ___ MAY

My philosophy:
Method 1 is the required common ground for interoperability.
Some situations may call for port based policy and the ability to handle 
fragments.  Implementors may choose to support this via method 2, method 3, 
2 and 3, or not support it.

--Mark

---

From: Satoshi Inoue <[email-masked]>
Date: Tue, 25 May 2004 13:23:31 +0900

On Mon, 24 May 2004 01:15:21 -0400

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

I think both should be MAY, it's implementation to decide whether to
do these things or not. Especially method #3, which seems to be far
too hard to handle for small implementations.

BTW, is fragmented user traffic (i.e. forwarding packets that are
already fragmented, not the ones that are fragmented by IPsec tunnel
I/F MTU size) affected by this? or is it out of scope in this section?
How about fragmented user traffic that is too big for an outgoing
IPsec tunnel's MTU size?

> particularly difficult.

Just one clarification, could this implementation work out re-ordered/
non-ordered fragments OK?

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 25 May 2004 09:54:34 +0400

> QUESTION 1:  Select one of the following

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

___ MAY

___ SHOULD

Regards,
Valery Smyslov.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 25 May 2004 13:21:42 +0300

Satoshi Inoue writes:
> I/F MTU size) affected by this?

We are only talking about those packets. I.e packets that are already
fragmented when the arrive the SGW, and which should be put to the
tunnel, and the tunnel SAs have port selectors. 

> or is it out of scope in this section?

No it is the whole scope of the section.

> How about fragmented user traffic that is too big for an outgoing

There is who issues combined there. If user sends 3000 byte UDP packet
to port 1234, which is fragmented to two 1500 byte packets. The SGW
will get those two. It now needs to find the proper SA to send them.
If SGW have IPsec SA (SA1) with port selectors matching the packet to
port 1234, he will send the first of those fragments to that SA. The
question is what to do the second fragment. It does not have port
numbers, thus he cannot select the SA for it. The proposal #3 says,
that ok, we have seen the first fragment, thus we can put up
information that if we see other fragments to that packet, send them
to same SA1. The proposal #2 says that we need to have specific SA2
for non-first fragments, and we send all non-first fragments to there
regardless of their port numbers.

So if user then send another 3000 byte UDP packet to port 2345, then
the #3 system will drop both fragments, as they do not match the
policy. The #2 system will drop the first fragment, as it does not
match the policy, but it will pass the second fragment as it matches
the policy of the non-first fragment SA (SA2).

Now, when we have the SA selected, we can do the actual encryption. If
that cause the packet to be too big for the MTU, the resulting
encrypted IPsec packet can be then fragmented again. This
fragmentation is removed in the other ends SGW, when it needs to
reassemble the packet before it can decrypt the packet. This section
is NOT covering that at all, it is completely outside the of this
section. This is covered elsewhere in the architecture document. 

> non-ordered fragments OK?

Yes.

If the non-first fragment arrives first, then it is queued in separate
fixed length queue for waiting the first-fragment to arrive. When it
arrives and the SA is selected, an entry is put to the stateful
fragmentation code which will know that rest of the fragments to the
same packets should be sent to the same SA. After that entry is put to
the cache, the queue of non-first fragments is checked, and if there
are any fragments which are part of that pakcet, they are also sent
forward. 
-- 
[email-masked]

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 25 May 2004 08:52:21 -0400

At 1:15 AM -0400 5/24/04, Theodore Ts'o wrote:
>    _X__ Both Methods #2 and Method #3 should be a MAY

--Paul Hoffman, Director
--VPN Consortium

---

From: Bora Akyol <[email-masked]>
Date: Tue, 25 May 2004 08:57:41 -0700

On 5/23/04 10:15 PM, "Theodore Ts'o" <[email-masked]> wrote:

>  __X_ Both Methods #2 and Method #3 should be a MAY
>

---

From: Joseph Tardo <[email-masked]>
Date: Tue, 25 May 2004 09:35:37 -0700

At 01:15 AM 5/24/2004 -0400, Theodore Ts'o wrote:

>    _X__One or both of Methods #2 and #3 should be a SHOULD or a MUST
>
>            __X_ Method #3 (stateful fragment inspection) should be
>                 SHOULD or MUST)
>
>         __X_ MAY

          writein:  SHOULD NOT  (provide security caveat text)

>         _X__ SHOULD

---

From: Satoshi Inoue <[email-masked]>
Date: Wed, 26 May 2004 11:18:51 +0900

On Tue, 25 May 2004 13:21:42 +0300

> tunnel, and the tunnel SAs have port selectors. 

Thank you for your explanation.
I think I'm on the right track now :-)

---

From: Markku Savela <[email-masked]>
Date: Wed, 26 May 2004 16:36:38 +0300

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

But, I would prefer

    Method #3 should be a MAY (Method #2 MUST NOT)

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

I consider Method #2 "dirty hack". If your policy says that traffic
matching a selector must be protected by the specific security, then
it should apply to everything, including fragments (initial and
non-initial).

But, if people insist on having #2 as option, I don't object if it
stays as "MAY".

---

From: Joe Touch <[email-masked]>
Date: Fri, 28 May 2004 13:42:00 -0700

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

It makes sense to mix non-initial fragments where the initial frags are 
mixed (Method #1).

It makes no security sense to mix some non-initial traffic where the 
initial fragments are not so mixed.

I would consider Method 2 a MUST NOT in that regard.

If I have to vote for one of the above, then:

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

> 	(you may pick more than one)

Again, I would go MUST NOT. At best, if I have to pick from above,

__X__ MAY

_X_ MAY