Subject: Some IKEv2 issues

From: Tero Kivinen <[email-masked]>
Date: Tue, 17 Feb 2004 21:35:24 +0200

I reread most last couple of months ipsec-list traffic, just checking
if we have lost some issues about IKEv2. I did found some cases where
there was some change to IKEv2 document, which I still might be open.
Some of those haven't received much comments in the ipsec lists, in
some cases the discussion lead to another cases, which consumed and
hide the original issue (EAP and public key authentication).

I think people should check those issues out, and comment about them. 

----------------------------------------------------------------------

http://www.vpnc.org/ietf-ipsec/mail-archive/msg02719.html

Pasi Eronen's comment about the EAP and creation of the AUTH messages.
The current draft says that we send EAP AUTH payloads when we have
enough information to compute the key". Pasi says that in some EAP
methods it is not that simple (i.e. does not know which is the last
message, and the key depends on all messages etc).

His proposal is to basically add new round trip, i.e first finish the
EAP completely (i.e responder sends EAP(success), and the initiator
sends AUTH payload, and then responder finishes the IPsec SA creation
(AUTH, SAr2, TSi, TSr payloads). 

[I think the easiest way out from here is to add one round trip, then
it will work with any EAP library and method etc]

----------------------------------------------------------------------

http://www.vpnc.org/ietf-ipsec/mail-archive/msg02701.html

Some issues from Charles Lynn:

	1) Clarification of the ICMP type and code encoding in TS.
	2) Say how OPAQUE is encoded (start = max, end = min ???)
	3) Add text about unidirectional policies (i.e where packets
	   only go to one direction, like ICMP).
	4) Fragment only SA, and non-initial fragments

[Point 1 is simply clarification, in point 2, I think it should be
start = min, end = max, not other way around, point 3 might actually
need some clarifying text, and the point 4 should be left out, as
fragment only SAs (issue 81 and 49) in RFC 2401 was rejected, i.e.
there is no need to change anything in the IKEv2 document because of
that]

----------------------------------------------------------------------

http://www.vpnc.org/ietf-ipsec/mail-archive/msg02695.html

TFC padding in ESPv2, i.e. do we add notify in IKEv2, or simply state
that using IKEv2 indicate that TFC padding is ok.

[I think we should simply add new notify to IKEv2.]

----------------------------------------------------------------------

http://www.vpnc.org/ietf-ipsec/mail-archive/msg02607.html

My own note, that we need to have udp-encaps and nat-reqts drafts as
references to the IKEv2 (udp-encaps as normative, and nat-reqts as
non-normative).

[No comments, :-]

----------------------------------------------------------------------

http://www.vpnc.org/ietf-ipsec/mail-archive/msg02514.html

and

http://www.vpnc.org/ietf-ipsec/mail-archive/msg02538.html

Pasi Eronen's comment about the using of EAP without public key
authentication, when using EAP method which provides mutual
authentication and shared key.

[There was long discussion in the list, couple of people saying, yes
we should do this change, couple saying no, we must disallow
explicitly EAP without public key authentication. Current draft
explictly disallows EAP without public key authentication. This
discussion was lost when we started talking about the keys used to
generate those AUTH messages (another issue now still up).]
-- 
[email-masked]

---

From: Charles Lynn <[email-masked]>
Date: Tue, 17 Feb 2004 15:02:14 -0500 (EST)

Tero,

> in point 2, I think it should be start = min, end = max, not other
> way around

start = min, end = max is the encoding for ANY.  OPAQUE and ANY are
not the same.  OPAQUE means the value of a field cannot be determined,
either because the protocol does not have it, or it is hidden by
encryption or fragmentation.

Charlie

---

From: Yoav Nir <[email-masked]>
Date: Wed, 18 Feb 2004 10:45:25 +0200

Hi.

I have just re-read draft -12 and I have a question.

When clients connect to an IRAS using both EAP for authentication and 
CFG for configuration, section 2.19 says that they CFG_REQUEST is sent 
in message #3.  The CFG_REPLY is sent in message #4.

However, section 2.16 shows that the EAP exchange extends to at least 
message #6 or more.  Is it acceptable to delay the CFG_REQUEST until 
the message that contains the SAr payload?  If so, I think it should be 
explicitly stated.

Sorry if this has been brought up before.

Yoav

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 18 Feb 2004 15:39:56 +0200

> in message #3.  The CFG_REPLY is sent in message #4.

No, it says tat the CFG_* payloads are put in the messages containg
the SA payloads, not necessarely message 3 and 4. 

> the message that contains the SAr payload?  If so, I think it should be 

It is mandatory to delay, as the CFG_REPLY MUST be put in the message
containing the SA payload, which will be the last message from
responder to the initiator. 
-- 
[email-masked]

---

From: Charles Lynn <[email-masked]>
Date: Wed, 18 Feb 2004 11:14:36 -0500 (EST)

Tero,

> point 4 should be left out, as fragment only SAs (issue 81 and 49)
> in RFC 2401 was rejected, i.e. there is no need to change anything
> in the IKEv2 document because of that]

My understanding was that the WG rejected the proposal of creating a
special SA that *only* carried non-initial fragments, not that the
WG rejected affording fragments (other than IPv4 in transport mode)
IPsec protection.

The issue that has to be resolved is how fragments are identified (a
local issue) and communicated using IKEv2's Traffic Selector
mechanism.  Fragments can then be directed to *an appropriate SA* that
is, or may be, carrying other, not-fragmented, traffic.

Since the transport layer selectors are not available in fragments,
they are OPAQUE.  Thus fragments of TCP packets between A and B could
be specified as:

    TS {
	TSi { ...
	      {IP=A, Protocol=TCP, Port=OPAQUE(start=65535,end=0)}
	      ...
	    }
	TSr { ...
	      {IP=B, Protocol=TCP, Port=OPAQUE}
	      ...
	    }
       }

alternatively, one could use:

    TS {
	TSi { ...
	      {IP=A, Protocol=Fragment(61), Port=TCP}
	      ...
	    }
	TSr { ...
	      {IP=B, Protocol=Fragment(61), Port=TCP}
	      ...
	    }
       }

I think that the IKEv2 document needs to specify which encoding, one
of the above or something someone else suggests, MUST be used to
enable interoperability.

Charlie

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 18 Feb 2004 23:29:43 +0200

> WG rejected affording fragments (other than IPv4 in transport mode)

True, but there is no need to have any special handing for them, if
the IP addresses of fragment match the traffic selectors of the SA,
then the packet can be sent there. I.e the first fragments, non-first
fragments and full packets all share the same SA. 

> they are OPAQUE.  Thus fragments of TCP packets between A and B could

Or, it can be said that those packets can only be sent to the SA
having transport layer selectors of ANY (i.e. if it takes any port
range, then it should also accept fragments which match the protocol
even when they actual packet does not have the port numbers in it).

> of the above or something someone else suggests, MUST be used to

I think it should use:

    TS {
	TSi { ...
	      {IP=A, Protocol=TCP, Port=ANY(start=0,end=65535)}
	      ...
	    }
	TSr { ...
	      {IP=B, Protocol=TCP, Port=ANY}
	      ...
	    }
       }
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 18 Feb 2004 23:09:40 +0200

> encryption or fragmentation.

From the responder side of view, what is the actual implemenation
difference between OPAQUE and ANY? I think they will be processed
identically in the implementations. There are semantic differences in
some cases, but I do not think that any implementations actually need
to know the difference on the packet processing level, thus I think we
should simply have one format of expressing that instead of having
special case for OPAQUE.

The IKEv2 draft does not make difference between any and opaque, and I
think that is fine. 
-- 
[email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Thu, 19 Feb 2004 11:09:20 -0500

Tero,

In 2401, and so far in 2401bis, we have distinguished between ANY and 
OPAQUE. if we decide to continue to do that, then at a minimum, we 
would not consider a fragment with no port fields to match an SA that 
allowed traffic with ANY as the value for port fields.

Also, If an IPsec implementation has two SA between the same 
source/dest address pairs, and with the same protocol value(s), but 
distinguished traffic based on specific (vs. ANY) port fields, then a 
non-initial fragment cannot be mapped to either SA unambiguously. An 
analogous problem arises if there is just one, extant SA that matches 
the addresses and protocol, and we are forced to search the SPD to 
see if another SA might be appropriate. These observations motivate 
use of a separate SA to carry fragments, right?

Steve

---

From: Charles Lynn <[email-masked]>
Date: Thu, 19 Feb 2004 11:54:44 -0500 (EST)

Tero,

> 	      {IP=B, Protocol=TCP, Port=ANY}

Is the consequence of such an encoding, i.e., that the default "DROP"
rule at the end of the SPD, loses much of its usefulness intentional?

I.e., such a rule would let any TCP packets go through.  Thus if one
anted to only allow, say TCP to port 22, including any fragments, then
the admin would have to insert a rule explicitly saying that ports
0 to 21 and 23 to 65535 should be DROP'ed.  It gets a lot worse if
multiple ports are allowed.

I think that the encoding you propose will result in more SPD
configuration errors and make IPsec harder to manage.

Charlie

---

From: "Bora Akyol" <[email-masked]>
Date: Thu, 19 Feb 2004 10:41:38 -0800

Steve

How often do we see multiple IPSEC Sas between the same two peers
protecting different ports (or in general different selector sets)?

There are better and straightforward ways of getting around the
issue of fragmented packets in the implementation
without requiring a separate SA for fragments.

As a side-note, configuring even the most basic traffic selectors in
some host OS that are widely-deployed is a big chore (really
hit-and-miss).
The most deployed IPSEC scenarios supporting road warriors don't even
use a traffic
selector at the head-end.

Regards,

Bora

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stephen Kent
> Sent: Thursday, February 19, 2004 8:09 AM
> To: Tero Kivinen
> Cc: Charles Lynn; [email-masked]
> Subject: Re: SAs that carry fragments Was: Re: Some IKEv2 issues
> 
> 
> Tero,
>

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 19 Feb 2004 13:04:40 -0600

> protecting different ports (or in general different selector sets)?

Consider cases where one peer is a multi-user system and different
connections are protected by [likely transport-mode] SAs with different
IDs for different users.  I would not want such scenarios to be
precluded.

> without requiring a separate SA for fragments.

Delay policy evaluation until fragmented packets are reassembled?  This
might be fine for transport mode SAs [but not for tunnel mode SAs?].

Queue fragmented packets for reassembly remembering what SA protected
each fragment, then when the packet is reassembled, and if all fragments
were protected by the same or congruent SAs check SPD, otherwise drop.

Nico
--

---

From: "Bora Akyol" <[email-masked]>
Date: Thu, 19 Feb 2004 11:22:22 -0800

Thanks for the comments, please see inline.

> From: Nicolas Williams [mailto:[email-masked]] 
> Sent: Thursday, February 19, 2004 11:05 AM
> To: Bora Akyol
> Cc: 'Stephen Kent'; 'Tero Kivinen'; Barbara Fraser; 'Charles 
> Lynn'; [email-masked]
> Consider cases where one peer is a multi-user system and 
> different connections are protected by [likely 
> transport-mode] SAs with different IDs for different users.  
> I would not want such scenarios to be precluded.
> 

And they don't need to be, I just think that creating a separate SA
for the fragments is unnecessary. How to handle fragments is
a topic better left to the implementer. 
Current IKE semantics allow this granularity BTW.

OTOH, I think implementing the functionality you specify above in 
a multi-user kernel would be quite the challenge :-) Sounds like an
excellent project indeed.

Bora

---

From: Stephen Kent <[email-masked]>
Date: Thu, 19 Feb 2004 14:39:33 -0500

>protecting different ports (or in general different selector sets)?

I don't know, but I do know that we have mandated the ability to 
support this for over 5 years.

>without requiring a separate SA for fragments.

what are they and why are they better?

>selector at the head-end.

I am aware of at least one very poor, definitely non-conforming, 
management UI for a widely deployed IPsec implementation.  But I 
don't think that a vendor's failures in this area ought to dictate 
our standards going forward.

Steve

---

From: "Bora Akyol" <[email-masked]>
Date: Thu, 19 Feb 2004 12:07:17 -0800

Thank you for your comments, please see inline

> From: Stephen Kent [mailto:[email-masked]] 
> Sent: Thursday, February 19, 2004 11:40 AM
> To: Bora Akyol
> Cc: 'Tero Kivinen'; Barbara Fraser; 'Charles Lynn'; 
> [email-masked]
> Subject: RE: SAs that carry fragments Was: Re: Some IKEv2 issues
> 
> 

Yes, and people have figured ways of supporting this
without needing separate SAs for fragments.

> >There are better and straightforward ways of getting around 
> the issue 
> >of fragmented packets in the implementation without requiring a 
> >separate SA for fragments.
> 

I think in an earlier email Nicolas gave some examples of how this can
be achieved and it can achieved efficiently without actually 
doing copies etc. Oh, they are better because they don't double the
effective number 
of SAs that will be used for communication. 
For example, if I can currently support 1,000,000 IPSEC SA pairs
(tunnels),
then by having a separate SA pair for fragments is going to cut my
capacity
in half. This is a big loss.

> >hit-and-miss). The most deployed IPSEC scenarios supporting road 
> >warriors don't even use a traffic

No, but the standards should be simple, clear and easy to implement.
Adding
features that improve the protocol coverage by 0.01% while increasing
code
complexity by 1-3% is hardly worth the effort.

Speaking from an implementor's perspective,
I think we should aim to cut rarely used features off existing IPSEC
standards
as opposed to adding to the feature set. Generality is good but it comes
at
a cost of implementation complexity, interoperability problems and
deployment headaches.
I think the traffic selectors and their broad flexibility is one of
these features.
For example just by cutting port based selectors for TCP and UDP, 
cost of doing security policy checks goes down exponentially for most
software
and linearly for most HW. This has huge scalability benefits if ever
IPSEC is
going to get widely deployed.
I am sure at some point before the 2401bis and IKE V2 efforts were under
way,
there must have been a deployment survey performed. If that is the case,
then we should look at that and cut the features that are not used at
all,
cut features that are rarely used and agree on a core set of features
and
specify these clearly from both protocol and management perspectives.

Regards,

Bora

---

From: Charles Lynn <[email-masked]>
Date: Thu, 19 Feb 2004 15:38:58 -0500 (EST)

Hi Bora,

Maybe you missed some of the earlier emails...

> >There are better and straightforward ways of getting around the issue 

The WG rejected the idea of a *separate* SA for fragments.

We are now talking about how to indicate that an existing SA should be
used to carry fragments, that is interoperable (can be communicated
via IKEv2) so that the packets the sending implementation puts into
the SA will be consistent with the receiver's access control policy (SA).

How the sending implementation figures out that a packet is a fragment
is a local matter.

> I think in an earlier email Nicolas gave some examples of how this
> can be achieved ...

> might be fine for transport mode SAs [but not for tunnel mode SAs?].

It requires memory in, e.g., a security gateway, code to do
fragmentation and reassembly, and makes it harder to keep up with line
rate.

> were protected by the same or congruent SAs check SPD, otherwise drop.

Is this at the sending end of the IPsec channel or the receiving?
I.e., "what SA protected each fragment" sounds like the receiver.
If the fragments got that far, a solution that protects fragments
is assumed, but not identified.

> and it can achieved efficiently without actually doing copies etc.

> they are better because they don't double the effective number of
> SAs that will be used for communication.  For example, if I can
> currently support 1,000,000 IPSEC SA pairs (tunnels), then by having
> a separate SA pair for fragments is going to cut my capacity in
> half. This is a big loss.

The suggestion I made does not require any copies, and dos not double
the number of SAs.

> No, but the standards should be simple, clear and easy to

Agreed.

> Adding features that improve the protocol coverage by 0.01% while
> increasing code complexity by 1-3% is hardly worth the effort.

Where did you get these numbers?

> standards as opposed to adding to the feature set. Generality is
> good but it comes at a cost of implementation complexity,
> interoperability problems and deployment headaches.

Not always.

> these features.  For example just by cutting port based selectors
> for TCP and UDP, cost of doing security policy checks goes down
> exponentially for most software and linearly for most HW. This has
> huge scalability benefits if ever IPSEC is going to get widely
> deployed.

Well, not using port selectors might make sense for VPNs, but IPsec is
designed for more than just VPNs.

> I am sure at some point before the 2401bis and IKE V2 efforts were
> under way, there must have been a deployment survey performed. If
> that is the case, then we should look at that and cut the features
> that are not used at all, cut features that are rarely used and
> agree on a core set of features and specify these clearly from both
> protocol and management perspectives.

That sort of assumes that past usage is a good predictor of future use.
I think that the Internet has proven that not to be the case more than
once.

Charlie

---

From: "Bora Akyol" <[email-masked]>
Date: Thu, 19 Feb 2004 13:07:57 -0800

Thanks Charlie, please see in-line.

> We are now talking about how to indicate that an existing SA 
> should be used to carry fragments, that is interoperable (can 
> be communicated via IKEv2) so that the packets the sending 
> implementation puts into the SA will be consistent with the 
> receiver's access control policy (SA).

Just like the sender can handle the fragments
without requiring a separate SA, the receiver can also handle
the fragments without a flag that says this SA carries fragments,
please let them pass without checking SP. This IMHO, looks too much
like a hole that someone will eventually exploit for some reason.
Is this what the opaque stuff is about? And isn't all of this stuff
considered unnecessary with IPv6?

> fragmentation and reassembly, and makes it harder to keep up 
> with line rate.
> 

Yes, more buffers may be required, but not that much harder to keep
up with line rate at the sender or receiver. 
Especially in the scenarios that have been
given on this thread which are mostly host, this should not be an issue.

> > each fragment, then when the packet is reassembled, and if all 
> > fragments were protected by the same or congruent SAs check SPD, 
> > otherwise drop.
> 
> Is this at the sending end of the IPsec channel or the 
> receiving? I.e., "what SA protected each fragment" sounds 
> like the receiver. If the fragments got that far, a solution 
> that protects fragments is assumed, but not identified.
>

I noticed this too, the conversation that I am interested in is in the
sender.
 
>
> The suggestion I made does not require any copies, and dos 
> not double the number of SAs.
> 

Thanks.
> Where did you get these numbers?

The numbers were an example based on my software engineering expertise.
Most bugs that I have seen come from corner cases or rarely used
features
that one almost never sees in the field. In order to support these
features,
the code bloats, ... I can go on and on about this.

> > standards as opposed to adding to the feature set. 
> Generality is good 
> > but it comes at a cost of implementation complexity, 
> interoperability 
> > these features.  For example just by cutting port based 
> selectors for 
> > TCP and UDP, cost of doing security policy checks goes down 
> Well, not using port selectors might make sense for VPNs, but 
> IPsec is designed for more than just VPNs.
>

How does a policy maker (say an IT mgr) decides that port 8001 is more
valuable
than port 8002. And what happens to the renagade user that runs a web
server
on port 16032? This is precisely why the TCP/UDP port based selector
spefication
is more eye candy than anything. The kernels today allow so much
flexibility
on what application can bind to what ports that it does not make sense
to
secure one application in a different manner than another. They should
ALL 
be equally secure. Otherwise, this one clueless insider will find the
port
that is being secured by DES and set-up the most critical infrastructure
on that port.

> > under way, there must have been a deployment survey 
> performed. If that 
> > is the case, then we should look at that and cut the 
> features that are 
> > not used at all, cut features that are rarely used and 
> agree on a core 
> > set of features and specify these clearly from both protocol and 
> > management perspectives.
> 
> That sort of assumes that past usage is a good predictor of 
> future use. I think that the Internet has proven that not to 
> be the case more than once.
> 

OTOH, IETF requires a deployment study before an RFC becomes
an STD, if I remember correctly. I always find it worthwhile to look
at what's in the field and then prioritize work accordingly.

So if I were writing the traffic selector spefications, I would write
them in an extensible format based on the following:

IP DA, SA, IP proto are on by default for v4 and v6.
Then there are optional selectors defined by offset from the end of
a well known field (say IP version number) and field length. They
could mean anything. 

This way one can get as specific as they want, but most common
uses will get the simplest possible implementation.
This type of field selector specification is used frequently
in network processor designs where such a lookup would be a single 
instruction.

Bora

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 19 Feb 2004 15:18:38 -0500

> cost of doing security policy checks goes down exponentially for
> most software and linearly for most HW.

say what?   not in all implementations it doesn't..

						- Bill

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 19 Feb 2004 15:06:08 -0600

> fragmentation and reassembly, and makes it harder to keep up with line

Which is why I thought this would be fine for transport-mode scenarios
but maybe not for tunnel-mode.  Of course, in the case of SGs there's
likely to be very few live SAs per client, so this may be a non-issue.

I'm not up on the whole thread, so I'll go back to lurking now.  I just
wanted to make sure that multi-user peers w/ transport mode SAs remained
workable.

Nico
--

---

From: Stephen Kent <[email-masked]>
Date: Thu, 19 Feb 2004 17:16:51 -0500

>without needing separate SAs for fragments.

your said "ways" which is plural.  It's not enough for a vendor to 
decide how to map a fragment to an SA, since the receiver is supposed 
to check each received packet against the selectors for the SA via 
which it is received. So, if there is ONE way to do this, and 
everybody already does it, and if it accommodates all the possible SA 
configurations that a compliant implementation MUST support, then we 
should just describe that way in 2401bis.  But, what I fear you are 
indicating is that different vendors have different ways of 
accommodating fragments, and that these may not be common, which 
means that interoperability problems may (will) occur, OR that not 
all possible SA configurations will work.  if so, then we need to fix 
this situation.

>in half. This is a big loss.

your example seems a bit vague in some details, but I refer you to 
Charlie's message for this discussion.

>complexity by 1-3% is hardly worth the effort.

it's easy to make a contrast like that, but it's harder to justify the numbers.

>specify these clearly from both protocol and management perspectives.

Sorry, but I cannot agree with your suggested approach to deciding 
what is and is not important for any standard. What is and is not 
used in current deployments may be a good measure of what folks need, 
or is may be an artifact of limits imposed by current 
implementations, etc.

We have removed some features from IPsec that were complex and not 
widely used. in the selector area we have added support for ICMP 
because folks asked for it.  we added the ability to map multiple 
distinct protocols to an SA to reduce the number of SAs, without 
loosing security functionality.

Steve

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 20 Feb 2004 15:02:24 +0200

> multiple ports are allowed.

But any OPAQUE rule will allow attacks against the fragmentation code
for the host anyways, so what is the problem of sending any non-first
fragments in the same TCP 22 SA? Are you saying that TCP 22 rule does
not allow fragments of the TCP 22 packets to get through (see my
previous posting of how to match fragments to the SAs).

We have been earlier talking whether TCP 22 rule should also allow
PMTU ICMPs etc to go through, and now we are talking to whether to
allow framented packets go through.

I think the TCP 22 rule should allow all traffic directly related to
TCP streams to port 22 through, meaning normal packets, fragmented
packets (all fragments, including non-first fragments), ICMPs related
to the TCP stream (PMTU, host unreachable, etc).

Creating separate SA for each of those would be quite annoying (i.e.
you need to create separate SA for ICMP traffic (and you need to
filter out those ICMP traffic which do not correspond to the real TCP
sessions in active, like faked host unreachable messages etc), and
separate SA for non-first fragments etc. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 20 Feb 2004 14:55:26 +0200

> non-initial fragment cannot be mapped to either SA unambiguously. An 

Actually it can, but it requires little bit work. For example our code
does the following (I do know that this is much more than what is
required by the rfc2401):

	1) If it receives unknown non-first fragment, it will put it
           in the separate queue (queue length and number bytes
           consumed is limited).
	2) When it receives the first-fragment it will find the SA
           suitable for it, and send packet forward.
	3) Then it will search through the non-first fragments queue
           and find other fragments for the packet, and send those
           forward (verifying in the process that the fragments do not
           overwrite the fields used in selecting the SA).
	4) It will create known-fragment entry to database, marking
           that if we see other fragments to this packet, they can be
           sent forward to this SA if they start after this offset.
           This entry will timeout after some time.

This will allow selecting proper SA for each fragment (non-first or
first). Of course the other end needs to do the same processing when
packets are processed to verify the selectors, in this case it is
easier, as the other end has already waited for the first-fragment, so
it will most likely come first (not necessary, the order might have
changed during transit).

So it is not impossible, it simply requires some work. We do not need
to do full reassembly, we simply need to mark that fragment matching
this source/destination/protocol/id should be sent/received from this
SA. 

> use of a separate SA to carry fragments, right?

Or to do the fragment handling properly, i.e. put them to the same SA
which haves the non-first fragments. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 20 Feb 2004 15:41:42 +0200

> all possible SA configurations will work.  if so, then we need to fix 

I do not know what others do, or do they support port selectors at
all. For VPN style setups (== tunnel mode) port selectors are not that
usefull, I think the most used setup there is tunnel from one IP or
network to network, and no port selectors at all. They might have
additional firewall rules after that, checking that only allowed
protocols are used (smtp, www etc).

Port selectors are more usefull in the host to host case, i.e.
transport mode, as there you might have per TCP/IP flow SAs (or per
user SAs). In those cases the IPsec processing is done for the whole
packet, thus this is non-issue (there are no fragments to be processed
in the transport mode case).

So we are now only talking about tunnel mode. How often do people use
tunnel mode along with port selectors? Does anybody have example of
real world example where it is needed? How does other implemenations
process the fragmented tunnel mode packet along with SAs with port
selectors. 
-- 
[email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 Feb 2004 09:50:18 -0500

>process the fragmented tunnel mode packet along with SAs with port

We've had analogous debates on this before.  IPsec is NOT just a VPN 
technology and our specs ought not be VPN-specific. I have certainly 
advised folks to use port selectors for tunnels under certain 
instances, e.g., to restrict traffic to a server to be traffic of the 
sort appropriate to that server, based on the well known ports 
associated with the service.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 Feb 2004 09:47:15 -0500

>            This entry will timeout after some time.

this sounds like a reasonable mechanism, though perhaps not not a 
very high speed context, since receipt of an initial fragment could 
trigger transmission of delayed non-initial fragments, which implies 
possible further disruption to transmission. but, under the right 
circumstances I can certainly see how this could work.

>it will most likely come first (not necessary, the order might have

right. so there is some reassembly-like processing at the receiver, 
e.g., per SA state to remember initial fragment data plus queuing of 
non-initial fragments to accommodate out or order delivery, etc.

>this source/destination/protocol/id should be sent/received from this

you left put ports here, the crux of the problem, but I assume that 
was just a typo, right?

>which haves the non-first fragments.

What concerns me is that the processing you describe could be a 
significant burden, maybe even infeasible, for very high speed 
operation.  We have focused more on such operation in this round of 
revisions, e.g., support for 64-bit sequence numbers and explicit 
discussion of caches. Thus I would prefer a spec that works well in 
all cases.

Steve

---

From: Markku Savela <[email-masked]>
Date: Fri, 20 Feb 2004 17:39:23 +0200

IPSEC:ing fragments? First, I really don't like the idea. But, anyway
a comment to

> From: Tero Kivinen <[email-masked]>
> So we are now only talking about tunnel mode.

In theory one could apply IPSEC to IPv6 fragments in transport
mode. However, it's technically impossible to apply IPSEC to IPv4
fragments, except by tunneling (think, where do you put the fragment
offset and M-bit, and how the receiver would work?).

I would prefer, that if IPSEC tunneling fragments is a MUST, only the
support for address selectors would be required by IPSEC.

And I would still disallow applying transport mode IPSEC to IPv6
fragments, even if it technically might be possible (need to look into
this, it would be somewhat weird path in my implementation, probably
will not work at all).

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 Feb 2004 11:25:19 -0500

>IPSEC:ing fragments? First, I really don't like the idea. But, anyway

the need to support tunneling of fragments has been in IPsec for 5+ 
years. this is not a new issue. it is an issue that we are trying to 
address in a uniform way.

>support for address selectors would be required by IPSEC.

yes, it is a MUST. one can choose to configure SA so that only 
addresses (or addresses and protocol) are examined and the ports are 
OPAQUE.  2401 allows that already and it should work today. but that 
leaves an awkward gap when ports are not OPAQUE and fragmentation 
occurs. we were approached by a vendor who wanted to have a 
well-defined, standard way to accommodate this, over a year ago, and 
that motivated the "carry all fragments between two sites in one 
tunnel" model. the WG rejected that model, but that does not make the 
issue go away, and since a vendor asked for this, I think it is fair 
to say that at least some users want the combination to work.

>this, it would be somewhat weird path in my implementation, probably

I'll let Charlie Lynn  address the vagaries of v6 fragmentation.

Steve

---

From: "Bora Akyol" <[email-masked]>
Date: Fri, 20 Feb 2004 08:57:53 -0800

> associated with the service.

Thanks for your comments,

I have a few questions:

1) In the MPLS working group, there has been
a lot of input from users/producers of the technology that has
made critical contributions to the original set of specifications
and for the better. So I think if there is input from the field
and not just one vendor/person that port selectors are not widely used
then the IPSEC WG may want to keep an open mind/ear. Yes, the
implementation
must not direct proper protocol design, OTOH, the protocol designers
may benefit from the field experience. I have on a separate email
submitted a definition of traffic selectors that I hope is flexible
enough
to accommodate both schemes. 

2) Although it sounds really interesting to let applications decide
which ports
they want to use and how they want to secure them, there are a few
issues.
     a) The system admin that decides the security policy may be a
different person
     from the application author. Moreover, the application author may
in fact have
     a hidden agenda in passing the data over a less secure channel than
the system
     policy allows. In order to settle this difference of SP, a properly
designed
     socket layer API needs to exist. However, even though port
selectors have been
     in IKE/IPSEC for at least 5-6 years, is there a such a socket API?
If there is
     no such socket API, then does this mean that the proposed
application is not
     important enough to the field so that it should be specified as an
**optional**
     feature.
     b) Even if such a socket API existed, the user environment in most
OSs allows
     applications to be tunneled via a different port (like HTTP
proxies), so it is
     quite easy to circumvent the system policy for a malicious user if
the policy
     was specified for ports alone. In fact, I believe there is an
implementation of
     IP over DNS that exists.

I think based on these, one can argue that even for transport mode, the
safest security
configuration for hosts is one that specifies less and secures more.

Thank you for reading and your comments,

Regards

Bora
ps. As in all IETF lists, these are my opinions and not my employer's!

---

From: Francis Dupont <[email-masked]>
Date: Fri, 20 Feb 2004 18:03:09 +0100

In your previous mail you wrote:

   transport mode

=> I have a concern about this "host to host" == transport mode.

   So we are now only talking about tunnel mode. How often do people use
   tunnel mode along with port selectors?

=> host to host where for some reasons transport mode is not used.

Regards

[email-masked]

PS: I'd like the solution (if we'll get one :-) will work with IPv6 too.

---

From: Francis Dupont <[email-masked]>
Date: Fri, 20 Feb 2004 18:14:13 +0100

mode.

=> I disagree: IPv6 fragmentation is done by an extension header,
this is not a "upper layer protocol" so you can't select it.
So even in theory it is impossible.

Regards

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 20 Feb 2004 11:54:58 -0600

> circumstances I can certainly see how this could work.

Or just drop non-initial fragments arriving before their corresponding
initial fragments (or so much later that the corresponding initial
fragments have fallen off the cache).

IP can lose packets.  Sometimes it's good to excercise this feature.

In transport mode scenarios (IPv4) this doesn't apply either since the
sender won't fragment and any middle boxes would fragment protected
traffic between the transport mode peers so there's no fragment
protection issue.  (I should have noticed this earlier instead of piping
up about transport mode.)

In BITW scenarios with SPDs that use port selectors this issue comes up,
as it does in one side of SG/VPN scenarios, right?

[...]
> discussion of caches. Thus I would prefer a spec that works well in 

If you remove the store-and-forward aspect of the proposal and drop
non-initial fragments for which you can't find a matching initial
fragment entry in the cache, then the only burden is that of keeping a
small cache of initial fragment identifiers, which means:

 - a small computational hit on initial fragments: cache id
 - a small computational hit on non-initial fragments: lookup id
 - a fixed memory hit
 - plus the burden of any additional restransmitted traffic that may
   result from dropping some non-initial fragments; the cache should be
   sized accordingly

The cache is indexed by selectors visible in a fragmented packet
(protocol, addresses) and packet ID; collisions are irrelevant, as are
fragment offsets.  LRU, LFU, aging, can be used to deal with cache
pressure.

Cheers,

Nico
--

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 Feb 2004 14:20:01 -0500

>IP can lose packets.  Sometimes it's good to excercise this feature.

yes, sometimes taking advantage of this "feature" can make our lives 
easier as designers ;-)

>up about transport mode.)

In a BITS implementation the host could have fragmented prior to 
IPsec receiving the packet, but one would certainly expect that the 
first fragment would arrive at the BITS first in that case.

>as it does in one side of SG/VPN scenarios, right?

It used to be the case that transport mode was restricted to end 
systems, but due to popular demand we have removed that restriction. 
so, this used to be just a tunnel mode issue for SG scenarios, but it 
might arise for transport mode too,under our new paradigm.

>fragment offsets.  LRU, LFU, aging, can be used to deal with cache

I'm not sure how to size the cache, but otherwise I think your 
analysis is correct, based on dropping non-initial fragments. one 
also has to deal with housekeeping issues, e.g., timing out fragment 
IDs, to prevent possible mismatches, and one needs to specify the 
receiver-side algorithm too, e.g., remembering packet IDs for initial 
fragments so that the later fragments are treated as acceptable. but, 
is this easier than what Charlie Lynn described?

Steve

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 20 Feb 2004 14:03:36 -0600

> yes, sometimes taking advantage of this "feature" can make our lives 

:)

> first fragment would arrive at the BITS first in that case.

Good point.

> might arise for transport mode too,under our new paradigm.

I thought that SGs were allowed to use transport mode for administrative
traffic where the SG is an end-point.  Is this a misunderstanding of the
new paradigm?  If not then no issue here.

> I'm not sure how to size the cache, but otherwise I think your 

Probably according to the proportion of traffic that is fragmented and
which must be protected.

> IDs, to prevent possible mismatches, and one needs to specify the 

How bad would mismatches be?  They may get protected with an incorrect
SA, but the receiver should be the same either way (if not, that would
be a bigger deal) and should then simply drop them since they wouldn't
match a correct first fragment (and if they did the result would, in all
likelyhood, not match various checksums and the like, leading to the
full packet being dropped which, again, would be within spec).

> is this easier than what Charlie Lynn described?

I'd have to re-read that.  In any case, the receiver already has to
track packet IDs for reassembly, so now all it has to do in addition is
track the SA that was used to protect each fragment and drop any
fragments that don't use an acceptable SA.  Unlike an SG, the receiver
here probably wouldn't want to drop non-initial fragments received
before their intial counterparts, if it can avoid it, and should have
the necessary buffer space, usually, so the receiver here can behave as
Tero proposed -- it does not seem like this would impose much of a
burden on the receiver.

Nico
--

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 20 Feb 2004 23:46:00 +0200

> associated with the service.

How have they handled the fragmentation issue in those cases, or have
the simply assumed that the fragmentation will not happen, and ignored
all of those packets. 
-- 
[email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 Feb 2004 16:15:14 -0500

Nicolas,

	<SNIP>

>new paradigm?  If not then no issue here.

The old model allowed SGs to use transport mode for admin traffic. 
The new model allows SGs to use it for any traffic, e.g., so that an 
overlay net that does IP-in-IP tunneling can use transport mode for 
the already tunneled packets.

	<SNIP>

>Probably according to the proportion of traffic that is fragmented and

that's hard to do a priori, right? if I am designing a hardware Ipsec 
implementation and need to decide how much memory to include for this 
purpose, this isn't a good algorithm :-)

>full packet being dropped which, again, would be within spec).

i agree that they would be sent to the same destination, but since an 
SG receiver is not required to reassemble plain text fragments, the 
issue is what happens at the real destination. long ago when we 
started discussing this issue there was a suggestion to check the 
offset for non-initial fragments (pardon the redundancy) to make sure 
that someone did not try to circumvent the receiver access control 
mechanism by sending a fragment with a port field that would not have 
been acceptable in a whole packet. this seems to be an easy check for 
v4, but it's apparently not feasible for v6, and thus we do have a 
concern re fragment reassembly attacks.

I was uncomfortable with the notion that we might send over fragments 
that don't really belong to the same packet, but maybe that's not 
fatal.

>track packet IDs for reassembly,

an IPsec device such as an SG does not have to reassemble plain text 
fragments, at least not under the assumptions we have been using for 
the last 5+ years.

>so now all it has to do in addition is

a receiver that is an end system could plausibly do reassembly and 
then subject the result to an access control check.

Steve

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 20 Feb 2004 23:58:15 +0200

> circumstances I can certainly see how this could work.

In most(*) of all cases the packets are processed in order, thus the
only need is to store the information that allow other fragments of
this packet to go through.

(*) There used to be bug in the linux kernel where it sent all
fragments always in reverse order, i.e. the last fragment first and
the first fragment last. This bug was fixed some time ago, and all
decent implementations should send the packets in order anyways, and
because we are now talking about the connection from the end host to
the SGW (from the senders point of view) there are not that often
reordering happening in the internal network before the SGW. From the
responder's point of view the case is harder, as the connection
between SGW and SGW might more easily cause reordering of packets,
thus forcing the responder to store the fragments coming before
first-fragment.

If the current approach is to drop all fragments (or create new SA for
non-first fragments), I think this proposed solution have less impact
on the overall performance of the system (ok, dropping all fragments
would be faster, but not very workable solution). 

> non-initial fragments to accommodate out or order delivery, etc.

Yep. 

> you left put ports here, the crux of the problem, but I assume that 

No, there are no ports there in the responder side. The responder will
check the ports when processing the first fragment, from the rest of
the fragments of the same packet it simply needs to know that they
came from the same SA, and they do not overwrite the data already
checked (i.e. source-ip/destination-ip/protocol/fragment-id are used
to identify the fragments).

> discussion of caches. Thus I would prefer a spec that works well in 

I do not think it will cause that much more processing, it is much
less processing that will be required if reassembly method is used
instead. I.e. reassemble the packet when getting it in, then select
SA, fragment it again, send it out, reassemble the packet in the other
end again, check the security policy, fragment the packet again, and
send it out. The reassembly method and the method described in the
beginning of the email are interoperable.

Also as the fragmented packets are not used that much, and even if
they are used the packets are in most cases received in-order, and in
those cases the extra processing burden caused is quite small.
-- 
[email-masked]

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 20 Feb 2004 15:56:18 -0600

> the already tunneled packets.

But in that case the transport mode SAs would still be end-to-end and,
outside the end-point fragmentation in BITS implementations, the clear
packets would not be fragmented prior to application of transport-mode
protection.  Right?

> purpose, this isn't a good algorithm :-)

Right, but there is a limit: assume 100% of traffic to be protected is
fragmented.  :)

I know, assuming 100% IPv6 traffic, 100% of packets fragmented, avg.
fragment size on the order of 1-2KB and 4 fragments per-packet on avg.
that would make the cache size be on the order of 1GB (!) for 10Gb/s.

With more reasonable assumptions (and path MTUs :) I think an SG can get
by with a far smaller cache, but one fast small-MTU link could cause the
SG packet drop rates to make some users miserable.

But this is "just" a trade-off: if you want support for the use multiple
SAs for the same SA end-points plus port selectors in VPN/BITW SG SPDs
then you must configure your network with sane MTUs.

I'd better read Charlie Lynn's proposal now :)

> concern re fragment reassembly attacks.

If all necessary selectors are not visible in the initial fragment,
drop.

> that don't really belong to the same packet, but maybe that's not 

Right, it makes me queasy too, but seems to be within what one can
expect of IP anyways.  And since the fragmented packets are coming in on
a clear interface (red, black, whatever the terminology is nowadays) the
SG can't really vouch for their integrity; if the clear packets are
really protected with a nested SA there's going to be no issue anyways,
and if they're not, well, then presumably they can be trusted, else the
SG wouldn't apply IPsec to them.

> fragments, at least not under the assumptions we have been using for 

I meant an end-point receiver.  Presumably an SG wouldn't have to
reassemble packets it is tunnelling -- it would apply the fragment
selector/id caching approach to select an SA for fragments (and then
only if the SPD has entries that use selectors that can be obscured by
fragmentation) as discussed.

> then subject the result to an access control check.

Exactly.

Nico
--

---

From: Tero Kivinen <[email-masked]>
Date: Sat, 21 Feb 2004 00:16:14 +0200

> yes, sometimes taking advantage of this "feature" can make our lives 

Yes, but as vendors shipping code, it would be quite unacceptable to
tell that sorry, any linux n.y box you have in the network cannot get
any fragmented packets through your SGW. Some linux kernel versions
used to send all fragments in reverse order, meaning that for all
fragmented packets all the other fragments than the non-first would be
dropped. 

...
> first fragment would arrive at the BITS first in that case.

I think you have no other way than to reassemble the packet in those
cases. The rfc2401 and rfc2401bis both say that you cannot apply IPsec
using transport mode to IPv4 packets that are fragments. I.e. if the
BITS implementation receives a fragmented packet and the SA is in
transport mode, it must first reassemble the packet, then apply IPsec
and then fragment the packet again. 
-- 
[email-masked]

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 20 Feb 2004 16:29:11 -0600

> I'd better read Charlie Lynn's proposal now :)

IIUC Charlie Lynn's proposal is to assign one SA to protect all
fragments even though multiple SAs may be used for different ports, yes?

I think this defeats the notion of having SGs with SPD entries with port
selectors where the different SAs for the same SA end-points have
effectively different IDs (e.g., different userFqdn IDs), though this
can be mitigated.  Presumably such cases involve a multi-user end-point
and this multi-user end-point runs trusted code (i.e., its OS kernel)
and may even have a host cert/key; using an SA whose ID corresponds to
the host for protecting the fragments would be a fine mitigation, as
would multiply-authenticating[*] the SA for carrying fragments (as long
as the trusted code in the end-point protects its DH private numbers and
SA keys from its users).

As compared to Tero's proposal (and with my comments) this is a lighter
weight solution -- setting up an SA and adding an SPD entry may be a
burden, but that would be less than the burden of keeping initial
fragment selector/ID cache (see previous post).

[*]  Is it possible to run multiple AUTH exchanges for a single IKE_SA
     with different certs?  Obviously the IKE_SA can only have one
     IDi/IDr...

Nico
--

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 Feb 2004 17:44:10 -0500

>the simply assumed that the fragmentation will not happen, and ignored

I suggested that they work hard to ensure that there are no fragments 
emitted by hosts within their environments. This works for TCP 
services, which is what was of primary interest, but would not work 
for UDP. We recognized that the lack of detailed specs for how to 
deal with fragments was a problem.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 Feb 2004 18:38:04 -0500

>fragmented packets all the other fragments than the non-first would be

Well, I guess the ;-) should be a ;-( in that case.

>and then fragment the packet again.

yes, that's true. I forgot that we had imposed that constraint.

Steve

---

From: Joe Touch <[email-masked]>
Date: Fri, 20 Feb 2004 16:28:16 -0800

Nicolas Williams wrote:

>>>>>In BITW scenarios with SPDs that use port selectors this issue comes 
>>>
>>>up,
>>>

The transport-mode SAs could be at the SGs. In that case, the clear 
packets might be fragmented when tunneled (due to the additional 
header), which would be before transport-mode processing.

> fragmentation) as discussed.

I would expect that the IP tunnel dest. endpoint would reassemble, but 
that would happen after receive SG transport-mode processing if using 
transport + IPIP tunnels.

Joe

---

From: Markku Savela <[email-masked]>
Date: Tue, 24 Feb 2004 18:21:10 +0200

I'm still somewhat uneasy with this talk about doing IPSEC on
fragments. Say we have a following setup:

 H  <======> SG <-----> S

   H is my host
   SG is security gateway
   S is some server behind the SG

Normally my policy on H would express something like

  Use tunneled IPSEC via SG using ESP (3des, sha1) for all
  communication with server S.

There are cases

1. S replies with fragmented packets

  1.1 SG reassembles the packet, applies IPSEC as required, and the
    result gets fragmented again.

  1.2 SG does not reassemble packet, but applies IPSEC directly to the
    fragments coming from S.

2. S does not fragment packets, and sends them as whole.

  2.1 SG applies IPSEC to packet and sends it out without
    fragmentation (packet is still short enough to fit PMTU)

  2.2 SG applies IPSEC, but the resulting packet needs to be
    fragmented

---------

The bothering thing is:

The H must now be prepared to handle all combinations EQUALLY with
the same dataflow

  - full packets protected with IPSEC
  - full IPSEC:ed packets fragmented
  - fragments with IPSEC applied individually to them

because host H cannot know what type of impelementation SG has
(whether it reassembles packets from S before doing IPSEC or not).

If there are different SA's required for normal and fragment packets,
the implementation must in worst case negotiate 4 SA's for each
connection, to be prepared for all possible variants (fragment and
non-fragment SA for each direction).

If the possibility of the fragments needs to noticed in the policy,
all policies need to be duplicated: one for non-fragmented, and one
for fragmented case.

The fragments may not arrive in order. If the policy is dependent on
specific ports, the recever must remember each applied SA on each
fragment until the full packet is received and the policy can be
checked.

Some optimization is possible, like if two fragments belonging to the
same packet are protected with different SA's, the whole packet is
invalid, and receiver can stop processing the fragments of that
packet. [Note: if fragments are protected with some different SA, then
also the first fragment must use the same].

What if SA's expire between fragments? For example due to bytecount?
Long fragmented packets eat up the replay window fast (I still use 32
bits, need to upgrade I guess)?

I would just forbid doing IPSEC on fragments, and require SG in above
to do reassembly, if S fragmented the packet. The other option is to
disallow port selectors with tunnel mode policies [and thus the policy
could be checked on each fragment individually].

---

From: Markku Savela <[email-masked]>
Date: Tue, 24 Feb 2004 21:10:29 +0200

Answering to my own mail, and bringing the issue back to topic...

>   - fragments with IPSEC applied individually to them

My suggestion is:

  IPSEC SA negotiation is based on full packet, and the same SA
  is applied to both full packet and fragments.

This is logical, because fragmentation, whether it happens or not,
should not in any way affect the security of the protected connection.

Thus, it is no concern of IKEv2, whether IPSEC is applied to fragments
or not. It should be left to the IPSEC implementation how they deal
with the fragment issue. It is not an issue for key management.

For example, if your SG does not support (or does not currently have)
port selectors in policy, you can just process packets individually,
whether they are whole or fragments.

If your SG wants to support port selector, it must at minimum buffer
the fragments until the first is received. And if it prepares to do
this, it could also assemble the packet in full and not apply IPSEC
to fragments at all.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 25 Feb 2004 12:58:10 -0500

>     result gets fragmented again.

there has never been a requirement for an SG to do this, but it 
could, and the result would be indistinguishable from traffic from S 
that had not been fragmented.

>   1.2 SG does not reassemble packet, but applies IPSEC directly to the

and, these IPsec protected packets MIGHT be fragmented later along the path

>     fragmentation (packet is still short enough to fit PMTU)

you didn't say for 1.1 above where the packet is fragmented. if the 
SG fragments it after applying IPsec, this is indistinguishable from 
later fragmentation between SH and H, so I assume this is why you 
didn't need to say which of these two cases occurred.

>   2.2 SG applies IPSEC, but the resulting packet needs to be

really another example of 1.1

>   - fragments with IPSEC applied individually to them

but this has always been true.

>(whether it reassembles packets from S before doing IPSEC or not).

I think this is irrelevant, for the reasons I cited above.

>non-fragment SA for each direction).

this is true, in the worst case, but the way you said it makes it 
sound even  worse, since there would already be 2 SA for each 
"connection."

>all policies need to be duplicated: one for non-fragmented, and one

I don't understand you reasoning here. if we were to specify an SA to 
carry non-initial fragments are to be carried on a separate SA 
between two IPsec peers, then that would add another SPD entry on a 
per-peer basis, but that is not the same as doubling the number of 
SPD entries.

>fragment until the full packet is received and the policy can be

not true for v4. this is just one possible implementation option. 
others have suggested that its OK to accept non-initial fragments 
over an SA so long as minimum offset checks are verified, to prevent 
overlapping reassmebly attacks.

>also the first fragment must use the same].

sorry, but I can't quite parse the sentences above.

>could be checked on each fragment individually].

I think that the suggested solution to require reassembly by an SG is 
not viable, in general, e.g., because outbound fragments might arrive 
at two different SGs. In general, at the Ip layer, we discourage 
intermediate reassembly strategies because of this sort of potential 
problem.

Steve