Subject: 2nd try

From: Stephen Kent <[email-masked]>
Date: Mon, 22 Mar 2004 21:05:54 -0500

This is my second attempt to get this memo out to the list.  The 
first try was late last week. Hopefully this one will be more 
successful

I'm writing this note in an effort to better organize our discussion 
about handling fragments on the protected side of the IPsec barrier. 
(This discussion does not address the existing mechanism in IPsec for 
fragmenting an outbound packet after IPsec processing has been 
applied and reassembling it at the receiver. These are well 
understood mechanisms that work, modulo one's ability to get 
fragments through any firewalls that may be fragment-averse.) We've 
discussed a number of scenarios and delved into considerable detail, 
and its easy to lose track of what we are doing and why. I apologize 
for taking longer than anticipated to complete this note, and for the 
fact that it has grown to double the size I originally estimated.

Steve
-----

The Requirement

There are three issues that must be resolved re processing of 
(plaintext) fragments in IPsec:
	- mapping a non-initial, outbound fragment to the right SA 
(or finding the right SPD entry)
	- verifying that a received, non-initial fragment is 
authorized for the SA via which it is received
	- mapping outbound and inbound non-initial fragments to the 
right SPD/cache entry, for bypass/drop traffic.

The first and third issues arise because we need a deterministic 
algorithm for mapping traffic to SAs (and SPD/cache entries). All 
three issues are important because we want to make sure that 
non-initial fragments that cross the IPsec boundary do not cause the 
access control policies in place at the receiver (or transmitter) to 
be violated.

Transport Mode and Fragments

First, we note that transport mode SAs have been defined (in 2401bis) 
to not carry fragments. This is a carryover from 2401, where 
transport mode SAs always terminated at end points. This is a 
fundamental requirement because, in the worst case, an IPv4 fragment 
to which IPsec was applied, might then be fragmented (as a ciphertext 
packet), en route to the destination. IP fragment reassembly 
procedures at the IPsec receiver would not be able to distinguish 
between pre-IPsec fragments and fragments created after IPsec 
processing.

For IPv6, only the sender is allowed to fragment a packet. As for 
IPv4, an IPsec implementation is allowed to fragment tunnel mode 
packets after IPsec processing, because it is the sender relative to 
the (outer) tunnel header. However, unlike IPv4, it would be feasible 
to carry a plaintext fragment on a transport mode SA, because the 
fragment header in IPv6 would appear after the AH or ESP header, and 
thus would not cause confusion at the receiver re reassembly. 
Specifically, the receiver would not attempt reassembly for the 
fragment until after IPsec processing.

Thus a possible question for the WG is whether 2401bis should relax 
the prohibition on carriage of fragments on transport mode SAs for 
IPv6 traffic? I suggest NOT allowing this, as it only adds to our 
problems, but I thought I would mention it in the name of 
completeness.

When only end systems used transport mode SAs, the prohibition on 
carriage of fragments was not a problem, since we assumed that the 
end system could be configured to not offer a fragment to IPsec. For 
a native host implementation this seems reasonable, and, as someone 
already noted, 2401 warned that a BITS implementation might have to 
reassemble fragments before performing an SA lookup. (It would then 
apply AH or ESP and could re-fragment the packet after IPsec 
processing.) Because a BITS implementation is assumed to be able to 
have access to all traffic emanating from its host, even if the host 
has multiple interfaces, this was deemed a reasonable mandate.

In 2401bis, we have explicitly said that it's OK to use transport 
mode in cases where the IPsec implementation is not the ultimate 
destination, e.g., between two SGs. In principle, this creates a new 
opportunity for outbound, plaintext fragments to be mapped to a 
transport mode SA for IPsec processing. However, in these new 
contexts in which a transport mode SA is now approved for use, it 
seems likely that we can continue to prohibit transmission of 
fragments, as seen by IPsec. For example, in an IP overlay network, 
packets being sent over transport mode SAs are IP-in-IP tunneled and 
thus have the necessary inner header to accommodate fragmentation 
prior to IPsec processing. When carried via a transport mode SA, 
IPsec would not examine the inner IP header for such traffic, and 
thus would not consider the packet to be a fragment. Thus it seems 
reasonable to retain the prohibition on carrying IPv4 fragments on 
transport mode SAs, even when the source or destination is an SG.

Tunnel Mode and Fragments

For tunnel mode SAs, it has always been the case that outbound 
fragments might arrive for processing at an IPsec implementation, 
although we have not defined a fool-proof mechanism for doing so in 
all contexts. The need to accommodate fragmented outbound packets can 
pose a problem because a non-initial fragment generally will not 
contain the port fields associated with a next layer protocol such as 
TCP, UDP, or SCTP. Thus, depending on the SPD configuration for a 
given IPsec implementation, plaintext fragments might or might not 
pose a problem.

For example, if the SPD requires that all traffic between two address 
ranges is offered IPsec protection (no bypass or drop SPD entries 
apply to this address range), then it should be easy to carry 
non-initial fragments on the SA defined for this address range, since 
the SPD entry implies an intent to carry ALL traffic between the 
address ranges. But, if there are multiple SPD entries that could 
match a fragment, and if these entries reference different subsets of 
port fields (vs. ANY), then it is not possible to map an outbound 
non-initial fragment to the right entry, unambiguously. (If we choose 
to allow carriage of fragments on transport mode SAs for IPv6, the 
problems arises in that context as well.)

This problem largely, though not exclusively, motivated the 
definition of OPAQUE as a selector value for port fields in RFC 2401. 
The other motivation for OPAQUE is the observation that port fields 
might not be accessible due to the prior application of IPsec. For 
example, if a host applied IPsec to its traffic and that traffic 
arrived at an SG, these fields would be encrypted. The algorithm 
specified for locating the "next layer protocol" described in 2401 
also motivated use of OPAQUE to accommodate an encrypted next layer 
protocol field in such circumstances. Nonetheless, the primary use of 
the OPAQUE value was to match traffic selector fields in packets that 
did not contain port fields (non-initial fragments), or packets in 
which the port fields were already encrypted (as a result of nested 
application of IPsec). 2401 was ambiguous in discussing the use of 
OPAQUE vs. ANY, suggesting in some places that ANY might be an 
alternative to OPAQUE.

We gain additional access control capability by defining both ANY and 
OPAQUE values. OPAQUE can be defined to match only fields that are 
not accessible. We could define ANY as the complement of OPAQUE, 
i.e., it would match all values but only for accessible port fields. 
If we simplify the procedure employed to locate the next layer 
protocol in 2401bis, so that we treat ESP and AH as next layer 
protocols, then the notion of an encrypted next layer protocol field 
has vanished, and there is also no need to worry about encrypted port 
fields either.  (We probably need to clarify the notion that ESP is 
not an "extension header" re IPv6, despite the fact that the IPv6 
spec calls it that.  The same is true for AH.) In that case, OPAQUE 
will be applicable only to non-initial fragments.

If we adopt the definitions above for ANY and OPAQUE, we need to 
clarify how these values work when the specified protocol does not 
have port fields, and when ANY is used for the protocol selector. I 
suggest that if a specific protocol value is used as a selector, and 
if that protocol has no port fields, then the port field selectors 
are to be ignored and ANY MUST be specified as the value for the port 
fields. (In this context, ICMP TYPE and CODE values are lumped 
together as a single port field (for IKEv2 negotiation), as is the 
IPv6 Mobility Header TYPE value.) If the protocol selector is ANY, 
then this should be treated as equivalent to specifying a protocol 
for which no port fields are defined, and thus the port selectors 
should be ignored, and MUST be set to ANY.

The Problem of Non-Initial Fragments

For an SG implementation, it is obvious that fragments might arrive 
from end systems behind the SG. A BITW implementation also may 
encounter fragments from a host or gateway behind it. (As noted 
earlier, native host implementations and BITS implementations 
probably can avoid the problems described below.) In the worst case, 
fragments from a packet might arrive at distinct BITW or SG 
instantiations and thus preclude reassembly as a solution option. 
Hence, in 2401 we adopted a general requirement that fragments must 
be accommodated in tunnel mode for all implementations. However, 2401 
did not provide a perfect solution. The use of OPAQUE as a selector 
value for port fields (a SHOULD in 2401) allowed an SA to carry 
non-initial fragments.

Using the features defined in 2401, if one defined an SA between two 
IPsec (SG or BITW) implementations using the OPAQUE value for both 
port fields, then all non-initial fragments matching the S/D address 
and protocol values for the SA would be mapped to that SA. Initial 
fragments would NOT map to this SA, if we adopt a strict definition 
of OPAQUE. However, 2401 did not provide detailed guidance on this 
and thus it may not have been apparent that use of this feature would 
essentially create a "non-initial fragment only" SA, precisely the 
solution that the WG recently rejected.

In the course of rejecting the "fragment-only" SA approach, it was 
noted that some subtle problems, problems not considered in 2401, 
would have to be avoided. For example, an SA of this sort must be 
configured to offer the "highest quality" security services for any 
traffic between the indicated S/D addresses (for the specified 
protocol). This is necessary to ensure that any traffic captured by 
the fragment-only SA is not offered degraded security relative to 
what it would have been offered if the packet were not fragmented. A 
possible problem here is that we may not be able to identify the 
"highest quality" security services defined for use between two IPsec 
implementation, since the choice of security protocols, options, and 
algorithms is a lattice (remember that from algebra?), not a totally 
ordered set. (We might safely say that BYPASS < AH < ESP w/integrity, 
but it gets messy if we have multiple ESP encryption or integrity 
algorithm options.) So, one has to impose a total ordering on these 
security parameters to make this work, but this can be done locally.

However, this conservative strategy has a possible performance down 
side; if most traffic traversing an IPsec implementation for a given 
S/D address pair (and specified protocol) is bypassed, then a 
fragment-only SA for that address pair might cause a dramatic 
increase in the volume of traffic afforded crypto processing. If the 
crypto implementation cannot support high traffic rates, this could 
cause problems. (An IPsec implementation that is capable of line rate 
or near line rate crypto performance would not be adversely affected 
by this SA configuration approach, so the performance impact is a 
potential concern, specific to implementation capabilities.)

Another concern is that non-initial fragments sent over a dedicated 
SA might be used to effect overlapping reassembly attacks, when 
combined with an apparently acceptable initial fragment. (This sort 
of attack assumes creation of bogus fragments, and is not a side 
effect of normal fragmentation.) This concern is easily addressed in 
IPv4, by checking the fragment offset value to ensure that no 
non-initial fragments have a small enough offset to overlap port 
fields that should be contained in the initial fragment. Recall that 
the IPv4 MTU minimum is 576 bytes, and the max IP header length is 60 
bytes, so any ports should be present in the initial fragment. If we 
require all non-initial fragments to have an offset of say 128 or 
greater, just to be on the safe side, this should prevent successful 
attacks of this sort. If the intent is only to protect against this 
sort of reassembly attack, this check need be implemented only by a 
receiver.

Another possible concern is that in some topologies and SPD 
configurations this approach might result in an access control 
surprise. The notion is that if we create an SA to carry ALL 
(non-initial) fragments then that SA would carry some traffic that 
might otherwise arrive as plaintext via a separate path, e.g., a path 
monitored by a proxy firewall. But, this concern arises only if the 
other path allows initial fragments to traverse it without requiring 
reassembly, presumably a bad idea for a proxy firewall. Nonetheless, 
this does represent a potential problem in some topologies and under 
certain assumptions re SPD and (other) firewall rule sets, and 
administrators need to be warned of this possibility.

IPv6 also has a fragment offset, carried in the fragmentation 
extension header. However, IPv6 extension headers are variable in 
length and there is no analogous max header length value that we can 
use to check non-initial fragments, to reject ones that might be used 
for an attack of the sort noted above. A receiver would need to 
maintain state analogous to reassembly state, to provide equivalent 
protection. So, only for IPv4 it is feasible to impose a fragment 
offset check that would reject attacks designed to circumvent port 
field checks by IPsec (or firewalls) when passing non-initial 
fragments.

A less serious concern is that non-initial fragments sent over a 
non-initial fragment-only SA might represent a DoS opportunity, in 
that they could be sent when no valid, initial fragment will ever 
arrive. This might be used to attack hosts behind an SG or BITW 
device. However, the incremental risk posed by this sort of attack, 
which can be mounted only by hosts behind an SG or BITW device, seems 
small.

If we interpret the ANY selector value as encompassing OPAQUE, then a 
single SA with ANY values for both port fields would be able to 
accommodate all traffic matching the S/D address and protocol traffic 
selectors, an alternative to using the OPAQUE value. But, using ANY 
here precludes multiple, distinct SAs between the same IPsec 
implementations for the same address pairs and protocol. So, it is 
not an exactly equivalent alternative.
Fundamentally, fragment handling problems arise only when more than 
one SA is defined with the same S/D address and protocol selector 
values, but with different port field selector values.

Bypass/Drop Traffic

We also have to address the non-initial fragment processing issue for 
bypass/drop entries, independent of SA processing. This is largely a 
local matter for two reasons: 1) we have no means for coordinating 
SPD entries for such traffic between IPsec implementations since IKE 
is not invoked; 2) many of these entries refer to traffic that is NOT 
directed to or received from a location that is using IPsec, so there 
is no peer IPsec implementation with which to coordinate via any 
means. However, 2401bis should provide guidance here, consistent with 
our goal of offering a well-defined, access control function for all 
traffic, relative to the IPsec boundary. To that end, I suggest that 
implementations MAY choose to support fragment reassembly for 
bypass/drop traffic when port fields are specified. An implementation 
also MUST permit a user or administrator to accept such traffic or 
reject such traffic using the SPD conventions described at the end of 
this note.

Just say no to ports?

It has been suggested that we could avoid the problems described 
above by not allowing port field selectors to be used in tunnel mode. 
But the discussion above shows this to be an unnecessarily stringent 
approach, i.e., since no problems arise for the native OS and BITS 
implementations. Moreover, some WG members have described scenarios 
where use of tunnel mode SAs with (non-trivial) port field selectors 
is appropriate. So the challenge is defining a strategy that can deal 
with this problem in BITW and SG contexts. Also note that bypass/drop 
entries in the SPD that make use of ports pose the same problems, 
irrespective of tunnel vs. transport mode notions.

Some folks have suggested that a firewall behind an SG or BITW should 
be left to enforce port level access controls, and the effects of 
fragmentation. However, this seems to be an incongruous suggestion in 
that elsewhere in IPsec (e.g., in IKE payloads) we are concerned 
about firewalls that always drop fragments! If many (most?) firewalls 
don't pass fragments in general, why should we expect them deal with 
fragments in this case? So, this analysis rejects the suggestion of 
disallowing use of port field selectors with tunnel mode SAs.

Other Suggested Solutions

One suggestion is to reassemble fragments at the sending IPsec 
implementation, and thus avoid the problem entirely. This approach is 
invisible to a receiver and thus could be adopted as a purely local 
implementation option.

A more sophisticated version of this suggestion calls for 
establishing and maintaining minimal state from each initial fragment 
encountered, to allow non-initial fragments to be matched to the 
right SAs or SPD/cache entries. This implies an extension to the 
current processing model (and the old one). One would intercept all 
fragments, capture S/D address, protocol, packet ID, and port fields 
from initial fragments and then use this data to map non-initial 
fragments to SAs that require port fields. If this approach is 
employed, the receiver needs to employ an equivalent scheme, as it 
too must verify that received fragments are consistent with SA 
selector values. A non-initial fragment that arrives prior to an 
initial fragment could be cached or discarded, awaiting arrival of 
the corresponding initial fragment.

A downside of both approaches noted above is that they will not 
always work. When a BITW device or SG is configured in a topology 
that might allow some fragments for a packet to be processed at 
different SGs or BITW devices, then there is no guarantee that all 
fragments will ever arrive at the same IPsec device. This approach 
also raises possible processing problems. If the sender caches 
non-initial fragments until the corresponding initial fragment 
arrives, buffering problems might arise, especially at high speeds. 
If the non-initial fragments are discarded rather than cached, there 
is no guarantee that traffic will ever pass, e.g., retransmission 
will result in different packet IDs that cannot be matched with prior 
transmissions. In any case, housekeeping procedures will be  needed 
to decide when to delete the fragment state data, adding some 
complexity to the system. Nonetheless, this is a viable solution in 
some topologies, and these are likely to be common topologies.

Issue #81, which the WG rejected, suggested the convention of 
creating an SA to carry only non-initial fragments, something that 
was supported implicitly under the 2401 model via use of OPAQUE port 
fields, but never clearly articulated in the RFC. The (rejected) text 
called for each non-initial fragment to be treated as protocol 44 
(the IPv6 fragment header protocol ID) by the sender and receiver. 
This approach has the potential to make IPv4 and v6 fragment handling 
more uniform, but it does not fundamentally change the problem, nor 
dies it address the issue of fragment handling for bypass/drop 
traffic. Given the fragment overlap attack problem that IPv6 poses, 
it does not seem that it is worth the effort to adopt this strategy.

Consistency

Earlier the WG agreed (Issue #88) to allow an IPsec BITS, BITW or SG 
to perform fragmentation prior to IPsec processing, after Mark Duffy 
explain the motivation for this. If this fragmentation is performed 
after SA lookup at the sender, there is no "mapping to the right SA" 
problem. But, the receiver still needs to be able to verify that the 
non-initial fragments are consistent with the SA via which they are 
received. Since the initial fragment might be lost en route, the 
receiver encounters all of the potential problems noted above. Thus, 
if we are to be consistent in our decisions, we need to say how a 
receiver will deal with the non-initial fragments that arrive.

Conclusions

There is no simple, uniform way to handle fragments in all contexts. 
Different approaches work better in different contexts.  Thus I 
suggest we require support for two approaches, and offer a third, and 
allow a user or administrator to choose from among these based on 
topology constraints and security requirements. Hence the following 
proposed text:

1. All implementations MUST support tunnel mode SAs that pass traffic 
without regard to port field values. If the SA will carry traffic for 
specified protocols, the two selector sets MUST be used to specify 
the port fields for the SA: ANY and OPAQUE. An SA defined in this 
fashion will carry all traffic for the indicated source/destination 
addresses and specified protocol(s). If the SA will carry traffic 
without regard to a specific protocol value (i.e., ANY is specified), 
then the port field values MUST be set to ANY as well.

2. All implementations MUST support tunnel mode SAs that will carry 
only non-initial fragments, separate from non-fragmented packets and 
initial fragments. The OPAQUE value will be used to specify port 
field selectors for an SA to carry non-initial fragments. Specific 
port selector values will be used to define SAs to carry initial 
fragments and non-fragmented packets. This approach can be used if a 
user or administrator wants to create one or more tunnel mode SAs 
between the same source/destination addresses that discriminate based 
on port fields.  These SAs MUST have non-trivial protocol selector 
values, otherwise approach #1 above can be used. Receivers MUST 
perform a minimum offset check on IPv4 (non-initial) fragments to 
protect against overlapping fragment attacks when SAs of this type 
are employed. Because such checks cannot be performed on IPv6 
non-initial fragments, users and administrators are advised that 
carriage of such fragments may be dangerous, and implementers may 
choose to NOT support such SAs for IPv6 traffic. Also, because a SA 
of this sort will carry ALL non-initial fragments that match a 
specified source/destination address pair and protocol value, users 
and administrators are advised to protect such traffic using ESP 
(with integrity) and the "strongest" integrity and encryption 
algorithms available at both peers. (Determination of the "strongest" 
algorithms requires imposing a total ordering of the available 
algorithms, a local determination at the discretion of the initiator 
of the SA.)

3. An implementation MAY choose to support some form of stateful 
fragment checking for a tunnel mode SA with non-trivial port field 
values (not ANY or OPAQUE). Implementations that will transmit 
non-initial fragments on a tunnel mode SA that makes use of 
non-trivial port selectors MUST notify a peer via an IKE payload 
(TBD). The peer MUST reject this proposal if it will not accept 
non-initial fragments in this context. If an implementation does not 
successfully negotiate transmission of non-initial fragments for such 
an SA, it MUST NOT send such fragments over the SA. This standard 
does not specify how peers will deal with such fragments, e.g., via 
reassembly or other means, at either sender or receiver. However, a 
receiver MUST drop non-initial fragments that arrive on an SA with 
non-trivial port selector values unless this feature has been 
negotiated. Dropping such packets is an auditable event. Note that in 
configurations where fragments of a packet might be sent or received 
via different security gateways or BITW implementations, stateful 
strategies for tracking fragments may fail.

---

From: Ravi <[email-masked]>
Date: Tue, 23 Mar 2004 10:15:18 +0530

I like to thank Steve for thorough,detailed and clear description
      on the problem. I could understand the whole background,
      even though I did not go through quite a number of emails on this
      subject in recent time. 

      It is true that port selectors are being used in IPSEC policies to give
      differential security for different kinds of traffic. Also, I noticed that some 
      applications (even TCP, which is majority of traffic in Internet today) don't
      set DF bit and don't initiate PMTU processing. It means that there would be
      fragments and today many IPSEC implementations do the reassembly 
      (Or pseudo reassembly) of the clear packets before applying security.
      I feel, any suggestion/solution make this case default. With respect to this
      I have following comments.

      I agree on Conclusion 1 i.e.. All implementations MUST support tunnel mode SAs
      that pass traffic without regard to port field values.    

      In regards to second point in conclusions section, I have some reservations.
      In many cases, the reassembly of the fragments is done for several reasons. It is not only 
      in regards to IPSEC, but also in regards to other security functionality such as 'Stateful
      inspection firewall' or 'Intrusion Protection System' etc..   In these cases, the IPSEC 
      implementation may would like always send all fragments using the right SA, rather than
      sending non-initial fragments on different SA. Due to this, the IPSEC implementation may not
      have even provide this kind of flexibility.

      I like the idea of providing negotiation option in IKE. 
      If an implementation does not intend to support of allowing non-initial fragments on a different SA,
      it can indicate so as part of IKE negotiation. In this case, the implementations must not use separate
     SA for non-initial fragments and must use local methods to map fragments (initial or non-initial) to the
     same SPD policy and must use same SA.

    Regards
    Ravi

Stephen Kent wrote:

> This is my second attempt to get this memo out to the list. The first 
> try was late last week. Hopefully this one will be more successful
>
> fragmenting an outbound packet after IPsec processing has been applied 
> and reassembling it at the receiver. These are well understood 
> mechanisms that work, modulo one's ability to get fragments through 
> any firewalls that may be fragment-averse.) We've discussed a number 
> of scenarios and delved into considerable detail, and its easy to lose 
> track of what we are doing and why. I apologize for taking longer than 
> anticipated to complete this note, and for the fact that it has grown 
> to double the size I originally estimated.
>
> Steve
> -----
>
>
> The Requirement
>
> - mapping a non-initial, outbound fragment to the right SA (or finding 
> the right SPD entry)
> - verifying that a received, non-initial fragment is authorized for 
> the SA via which it is received
> - mapping outbound and inbound non-initial fragments to the right 
> SPD/cache entry, for bypass/drop traffic.
>
> to not carry fragments. This is a carryover from 2401, where transport 
> mode SAs always terminated at end points. This is a fundamental 
> requirement because, in the worst case, an IPv4 fragment to which 
> IPsec was applied, might then be fragmented (as a ciphertext packet), 
> en route to the destination. IP fragment reassembly procedures at the 
> IPsec receiver would not be able to distinguish between pre-IPsec 
> fragments and fragments created after IPsec processing.
>
> problems, but I thought I would mention it in the name of completeness.
>
> carriage of fragments was not a problem, since we assumed that the end 
> system could be configured to not offer a fragment to IPsec. For a 
> native host implementation this seems reasonable, and, as someone 
> In 2401bis, we have explicitly said that it's OK to use transport mode 
> in cases where the IPsec implementation is not the ultimate 
> transport mode SA for IPsec processing. However, in these new contexts 
> in which a transport mode SA is now approved for use, it seems likely 
> that we can continue to prohibit transmission of fragments, as seen by 
> IPsec. For example, in an IP overlay network, packets being sent over 
> transport mode SAs are IP-in-IP tunneled and thus have the necessary 
> inner header to accommodate fragmentation prior to IPsec processing. 
> When carried via a transport mode SA, IPsec would not examine the 
> inner IP header for such traffic, and thus would not consider the 
> packet to be a fragment. Thus it seems reasonable to retain the 
> prohibition on carrying IPv4 fragments on transport mode SAs, even 
> when the source or destination is an SG.
>
>
> This problem largely, though not exclusively, motivated the definition 
> of OPAQUE as a selector value for port fields in RFC 2401. The other 
> motivation for OPAQUE is the observation that port fields might not be 
> accessible due to the prior application of IPsec. For example, if a 
> host applied IPsec to its traffic and that traffic arrived at an SG, 
> these fields would be encrypted. The algorithm specified for locating 
> the "next layer protocol" described in 2401 also motivated use of 
> OPAQUE to accommodate an encrypted next layer protocol field in such 
> circumstances. Nonetheless, the primary use of the OPAQUE value was to 
> match traffic selector fields in packets that did not contain port 
> fields (non-initial fragments), or packets in which the port fields 
> were already encrypted (as a result of nested application of IPsec). 
> 2401 was ambiguous in discussing the use of OPAQUE vs. ANY, suggesting 
> in some places that ANY might be an alternative to OPAQUE.
>
> OPAQUE values. OPAQUE can be defined to match only fields that are not 
> accessible. We could define ANY as the complement of OPAQUE, i.e., it 
> would match all values but only for accessible port fields. If we 
> simplify the procedure employed to locate the next layer protocol in 
> 2401bis, so that we treat ESP and AH as next layer protocols, then the 
> notion of an encrypted next layer protocol field has vanished, and 
> there is also no need to worry about encrypted port fields either. (We 
> probably need to clarify the notion that ESP is not an "extension 
> header" re IPv6, despite the fact that the IPv6 spec calls it that. 
> The same is true for AH.) In that case, OPAQUE will be applicable only 
> to non-initial fragments.
>
> if that protocol has no port fields, then the port field selectors are 
> to be ignored and ANY MUST be specified as the value for the port 
> then this should be treated as equivalent to specifying a protocol for 
> which no port fields are defined, and thus the port selectors should 
> be ignored, and MUST be set to ANY.
>
>
> earlier, native host implementations and BITS implementations probably 
> can avoid the problems described below.) In the worst case, fragments 
> from a packet might arrive at distinct BITW or SG instantiations and 
> thus preclude reassembly as a solution option. Hence, in 2401 we 
> adopted a general requirement that fragments must be accommodated in 
> tunnel mode for all implementations. However, 2401 did not provide a 
> perfect solution. The use of OPAQUE as a selector value for port 
> fields (a SHOULD in 2401) allowed an SA to carry non-initial fragments.
>
> fragments would NOT map to this SA, if we adopt a strict definition of 
> OPAQUE. However, 2401 did not provide detailed guidance on this and 
> thus it may not have been apparent that use of this feature would 
> the fragment-only SA is not offered degraded security relative to what 
> it would have been offered if the packet were not fragmented. A 
> fragment-only SA for that address pair might cause a dramatic increase 
> in the volume of traffic afforded crypto processing. If the crypto 
> implementation cannot support high traffic rates, this could cause 
> problems. (An IPsec implementation that is capable of line rate or 
> near line rate crypto performance would not be adversely affected by 
> this SA configuration approach, so the performance impact is a 
> Another concern is that non-initial fragments sent over a dedicated SA 
> might be used to effect overlapping reassembly attacks, when combined 
> with an apparently acceptable initial fragment. (This sort of attack 
> assumes creation of bogus fragments, and is not a side effect of 
> normal fragmentation.) This concern is easily addressed in IPv4, by 
> checking the fragment offset value to ensure that no non-initial 
> fragments have a small enough offset to overlap port fields that 
> should be contained in the initial fragment. Recall that the IPv4 MTU 
> minimum is 576 bytes, and the max IP header length is 60 bytes, so any 
> ports should be present in the initial fragment. If we require all 
> non-initial fragments to have an offset of say 128 or greater, just to 
> be on the safe side, this should prevent successful attacks of this 
> sort. If the intent is only to protect against this sort of reassembly 
> attack, this check need be implemented only by a receiver.
>
> field checks by IPsec (or firewalls) when passing non-initial fragments.
>
> implementations for the same address pairs and protocol. So, it is not 
> an exactly equivalent alternative.
> local matter for two reasons: 1) we have no means for coordinating SPD 
> entries for such traffic between IPsec implementations since IKE is 
> not invoked; 2) many of these entries refer to traffic that is NOT 
> It has been suggested that we could avoid the problems described above 
> by not allowing port field selectors to be used in tunnel mode. But 
> the discussion above shows this to be an unnecessarily stringent 
> that elsewhere in IPsec (e.g., in IKE payloads) we are concerned about 
> firewalls that always drop fragments! If many (most?) firewalls don't 
> pass fragments in general, why should we expect them deal with 
> A more sophisticated version of this suggestion calls for establishing 
> and maintaining minimal state from each initial fragment encountered, 
> to allow non-initial fragments to be matched to the right SAs or 
> SPD/cache entries. This implies an extension to the current processing 
> model (and the old one). One would intercept all fragments, capture 
> S/D address, protocol, packet ID, and port fields from initial 
> fragments and then use this data to map non-initial fragments to SAs 
> that require port fields. If this approach is employed, the receiver 
> needs to employ an equivalent scheme, as it too must verify that 
> received fragments are consistent with SA selector values. A 
> non-initial fragment that arrives prior to an initial fragment could 
> be cached or discarded, awaiting arrival of the corresponding initial 
> fragment.
>
> A downside of both approaches noted above is that they will not always 
> work. When a BITW device or SG is configured in a topology that might 
> allow some fragments for a packet to be processed at different SGs or 
> BITW devices, then there is no guarantee that all fragments will ever 
> arrive at the same IPsec device. This approach also raises possible 
> processing problems. If the sender caches non-initial fragments until 
> the corresponding initial fragment arrives, buffering problems might 
> arise, especially at high speeds. If the non-initial fragments are 
> discarded rather than cached, there is no guarantee that traffic will 
> ever pass, e.g., retransmission will result in different packet IDs 
> that cannot be matched with prior transmissions. In any case, 
> housekeeping procedures will be needed to decide when to delete the 
> fragment state data, adding some complexity to the system. 
> Nonetheless, this is a viable solution in some topologies, and these 
> are likely to be common topologies.
>
> Issue #81, which the WG rejected, suggested the convention of creating 
> an SA to carry only non-initial fragments, something that was 
> supported implicitly under the 2401 model via use of OPAQUE port 
> called for each non-initial fragment to be treated as protocol 44 (the 
> IPv6 fragment header protocol ID) by the sender and receiver. This 
> approach has the potential to make IPv4 and v6 fragment handling more 
> uniform, but it does not fundamentally change the problem, nor dies it 
> address the issue of fragment handling for bypass/drop traffic. Given 
> the fragment overlap attack problem that IPv6 poses, it does not seem 
> that it is worth the effort to adopt this strategy.
>
>
> Consistency
>
> Different approaches work better in different contexts. Thus I suggest 
> we require support for two approaches, and offer a third, and allow a 
> user or administrator to choose from among these based on topology 
> constraints and security requirements. Hence the following proposed text:
>
> specified protocols, the two selector sets MUST be used to specify the 
> port fields for the SA: ANY and OPAQUE. An SA defined in this fashion 
> will carry all traffic for the indicated source/destination addresses 
> and specified protocol(s). If the SA will carry traffic without regard 
> to a specific protocol value (i.e., ANY is specified), then the port 
> field values MUST be set to ANY as well.
>
> initial fragments. The OPAQUE value will be used to specify port field 
> selectors for an SA to carry non-initial fragments. Specific port 
> selector values will be used to define SAs to carry initial fragments 
> and non-fragmented packets. This approach can be used if a user or 
> administrator wants to create one or more tunnel mode SAs between the 
> same source/destination addresses that discriminate based on port 
> fields. These SAs MUST have non-trivial protocol selector values, 
> otherwise approach #1 above can be used. Receivers MUST perform a 
> minimum offset check on IPv4 (non-initial) fragments to protect 
> against overlapping fragment attacks when SAs of this type are 
> employed. Because such checks cannot be performed on IPv6 non-initial 
> fragments, users and administrators are advised that carriage of such 
> fragments may be dangerous, and implementers may choose to NOT support 
> such SAs for IPv6 traffic. Also, because a SA of this sort will carry 
> ALL non-initial fragments that match a specified source/destination 
> address pair and protocol value, users and administrators are advised 
> to protect such traffic using ESP (with integrity) and the "strongest" 
> integrity and encryption algorithms available at both peers. 
> (Determination of the "strongest" algorithms requires imposing a total 
> ordering of the available algorithms, a local determination at the 
> discretion of the initiator of the SA.)
>
> an SA, it MUST NOT send such fragments over the SA. This standard does 
> not specify how peers will deal with such fragments, e.g., via

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 23 Mar 2004 15:33:29 +0200

> problems, but I thought I would mention it in the name of 

I agree for not allowing that. 

> Tunnel Mode and Fragments
...
> OPAQUE vs. ANY, suggesting in some places that ANY might be an 

Note, that IKEv1 does not have way to negotiate OPAQUE, it only offers
port number - 0 => Port field should be ignored == ANY+OPAQUE. 

> will be applicable only to non-initial fragments.

I think that treating ESP and AH as next layer protocol would be good
idea.

> value for port fields (a SHOULD in 2401) allowed an SA to carry 

And as IKEv1 didn't offer any support for OPAQUE, there cannot really
be implementations using that method with IKEv1 (i.e. IKEv1 cannot
negotiate such SA for OPAQUE traffic). 

> reject such traffic using the SPD conventions described at the end of 

If you have SA with port selectors between SGWs you cannot allow clear
text non-first fragments without (partial) reassembly between SGWs.

I.e. if you have rules

     A <-> B port 25 ESP with auth
     A <-> B non-first fragments in clear (i.e. bypass)

Then attacker who sees or (or forces) the A to send fragmented packet
can modify the non-first fragments regardless whether the SGW1
encrypted all the fragments of the packet from A, and the SGW2 will
accept them based on the second policy rule. .

> Conclusions
...
> then the port field values MUST be set to ANY as well.

Is this for traffic where the SGWs ignore the port field completely?

Is this negotiated with IKEv2 by setting the port field range to
0-65535 (==ANY). 

> fragments and non-fragmented packets. This approach can be used if a 

If this is added, I think negotiating it in the IKE using the protocol
44 (issue #81), is much cleaner way than the special port values. On
the other hand that does not allow negotiation of the only TCP
fragments. Perhaps the special port range is then better, i.e. in IKE
v2 use port range of 65535-0 (= non-first fragment).

> choose to NOT support such SAs for IPv6 traffic. Also, because a SA 

The beginning says this is MUST, and here you say implementators can
choose not to support it. I think it shoud say it is MUST for IPv4 and
MAY/SHOULD for IPv6

> (TBD).

Why? If the other end only supports the case #2, then it only needs to
check that the SA which is used to carry the traffic has enough
security to take care of the non-initial fragments. I.e. if the
senders policy is use ESP AES for port 25, and the responders is use
ESP AES for port 25, and any ESP stronger than 80-bits for non-inigial
fragments, then it can safely accept the non-initial packets coming
from the SA negotiated for the port 25.

> The peer MUST reject this proposal if it will not accept 
-- 
[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Tue, 23 Mar 2004 14:54:31 +0100

In your previous mail you wrote:

   (We probably need to clarify the notion that ESP is 
   not an "extension header" re IPv6, despite the fact that the IPv6 
   spec calls it that.  The same is true for AH.)

=> in a private discussion a fine proposal was defined: talk about
extension headers using the generic extension header format.
(ESP, AH and IPCOMP don't use the generic format, AH because the
length field is in another unit).

   In that case, OPAQUE 
   
=> in theory the upper layer header can be in a non-initial fragment
when a (large) destination option header is used, so in IPv6 OPAQUE
can be applicable to all fragments.

Regards

[email-masked]

PS: BTW there is no OPAQUE encoding in the current IKEv2 draft...

---

From: Markku Savela <[email-masked]>
Date: Tue, 23 Mar 2004 18:06:18 +0200

Somewhat related to the "2nd try" text. I'm somewhat curious how
implementations plan to handle this fragmentation issue:

 (1) IPSEC must verify the policy of packets before they are given to
 the reassembly, and

 (2) IPSEC must ALSO verify the policy for the complete the packet
 after it has been reassembled. This is the normal case where IPSEC is
 applied to complete packet and the result fragmented (IPSEC can be
 done only after reassembly).

           TCP/IP
   ------> Fragment  ---->
     (1)   Assembly   (2)
    IPSEC            IPSEC
    Policy           Policy
    Check            Check

"2nd try" text relates to (1) IPSEC. How does the (2) IPSEC know that
a complete packet coming out of fragment assembly is has been checked
or not? (The packet looks like plain unprotected packet, which by all
normal rules should be dropped, if policy required it to be
protected).

To work, IPSEC must be able to associate some additional information
with the packet in the assembly?

---

From: Stephen Kent <[email-masked]>
Date: Tue, 23 Mar 2004 12:32:51 -0500

>  (1) IPSEC must verify the policy of packets before they are given to

I don't think this is true if one chooses to support reassembly, or 
partial reassembly in IPsec. That process requires maintaining state 
on a per SA basis, and thus might be expected to be performed as part 
of SA- processing.

>  done only after reassembly).

this sounds like reassembly on the ciphertext/unprotected side of an 
IPsec receiver, a very different case from what we have been 
discussing.

>with the packet in the assembly?

this seems to assume a particular implementation approach, and is 
analogous to the issue we have discussed previously, i.e., performing 
firewall checks outside of the IPsec context requires access to SA 
info that would not normally be available at that point.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 24 Mar 2004 14:33:50 -0500

Tero,

<SNIP>

>port number - 0 => Port field should be ignored == ANY+OPAQUE.

Yes, there was a disconnect between IKEv1 and what 2401 said, and the 
goal here is to fix that with 2401bis and IKEv2.

<SNIP>

>negotiate such SA for OPAQUE traffic).

Agreed, But 2401bis assumes use of IKEv2 in several instances, so I 
don't see this as a problem.

<SNIP>

>accept them based on the second policy rule. .

I agree that the second rule would be a bad config choice. But I 
disagree with the conclusion that one must do some form of reassembly 
if fragments are allowed to bypass. We ought not impose this 
requirement just to counter the bad effects of a bad config choice.

>Is this for traffic where the SGWs ignore the port field completely?

yes.

>Is this negotiated with IKEv2 by setting the port field range to

ANY and OPAQUE must both be specified to accommodate all possible 
traffic types (whole packets, as well as all fragments).

>v2 use port range of 65535-0 (= non-first fragment).

I'm flexible on what the encoding should be for OPAQUE in IKEv2.

>choose not to support it. I think it shoud say it is MUST for IPv4 and

I intended to convey the notion that it is a MUST for v4, but not for 
v6, for the reason cited. I'm comfortable with a MAY for v6.

>from the SA negotiated for the port 25.

Since it appears that nothing short of reassembly will be safe for 
v6, I think it is important to add this case. Also,  you and some 
other folks have indicted that this approach seems reasonable for 
many contexts, where very high speed
processing it not an issue. So, my reason for including #3 above is 
to allow folks who want to do reassembly to do it, but not to impose 
it as a burden for folks who don't feel that this strategy is 
compatible with their system requirements/architecture.

Steve

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 25 Mar 2004 15:22:14 +0200

> don't see this as a problem.

I was commenting that IKEv1 does not support it, thus there cannot be
implementations supporting that format => if we mandate that now in
the RFC2401bis then all implementations needs to add new code to
support that.

On the other hand there is (several?) implementations out which do
partial reassembly, which means that it is already tested and working
method of fixing that problem. 

> requirement just to counter the bad effects of a bad config choice.

If we do not add that requirements, then the problem is that if user
uses vendor 1 IPsec with that configuration and which uses the partial
reassembly it is secure, but if he switches to vendor 2 IPsec which do
not do partial reassmebly his working policy suddenly comes insecure.
That can be quite suprise to the adminstrator, and I think some kind
of warning for the implementators should be in the text, if there is
no requirement for partial reassembly.

> v6, I think it is important to add this case.

The "why?" was for "why do you need to notify that with IKE?".

> Also,  you and some 

I think we do need case #3, but I do not think we need to negotiate it
with notifications. I also think that case #2 and case #3
implementations can interoperate without any problems.

I use port fragment to indicate the fragment which contains the port
numbers, and non-port fragment to indicate the fragment which do not
have port numbers.

If you ONLY support #2, then you create non-port fragment SA, and you
accept any non-port fragments from there. You MUST also accept any
non-port fragments from any port fragment SA, provided that the
security of that port fragment SA is "enough" compared to the non-port
fragment SA. There is no need to do any partial-reassembly for any of
the traffic regardless whether it was received from the non-port
fragment SA or from port fragment SA.

If you support #3, then you MUST send all non-port fragments to same
port-fragment SA which was used for the fragment containing the port
numbers of the packet. When you receive fragments from the any source,
you do the partial-reassembly and verify that the packet is allowed by
policy. If the fragment was received from the any other SA than which
would carry the port-fragment of the packet, then you also need to
verify that the security of that SA is "enough" compared to the
port-fragment SA, which should have been used.

This way you are always putting the fragments to the same SA which
contained the port-fragment if you support #3 and to the non-port
fragment SA if you only support #2. Note, that traffic for each
direction may use different SAs, i.e. traffic from SGW 1 to 2 may use
non-port fragment SA for non-port fragment, and traffic from SGW 2 to
1 may always use port-fragment SAs, and never send any traffic inside
the non-port fragment SA.

When you receive packet from any SA, you do the policy checks, and if
your policy check is that any non-port fragment can go through, then
there is no need to do partial reassembly at all (even in case #3). If
you policy is that always verify the port selectors, then you need to
do partial reassembly for all fragment regardless which SA (or bypass
rule) was used to receive it.

This mixing of case 2 and 3, assumes that you can have some kind of
ordering of the SAs, saying that this security is enough for the
non-port fragments. This can be also done so that the adminstrator
creates the list of allowed algorithms for the non-port fragments
(incoming), and if system only supports #2, then adminstrator needs to
specify algorithm for the outgoing non-port fragments too.
-- 
[email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Thu, 25 Mar 2004 12:56:59 -0500

>the RFC2401bis then all implementations needs to add new code to

agreed, but 2401bis also requires support for other features that 
arise only in IKEv2, so this would not be the only reason that 
new/changed code is required.

>method of fixing that problem.

yes, and that's a good reason to include it as an option, but not as 
a mandatory facility.

>no requirement for partial reassembly.

I'm all in favor of a warning.

>The "why?" was for "why do you need to notify that with IKE?".

The need to notification is required, I think, because support for 
reassembly is not mandated in my proposal. So if an implementation 
sends fragments across an SA that requires port checking, the 
receiver should reject non-initial fragments  unless it has said that 
it is prepared to deal with them via reassembly (prior to checking).

>fragment SA or from port fragment SA.

agreed, but this works only for IPv4.

>port-fragment SA, which should have been used.

A sender might choose approach #3 because he will receive 
non-fragmented packets, map them to a port-specific SA, then fragment 
them on the protected side, and send them over the port-specific SA. 
in this simple case the receiver needs to be willing to deal with the 
fragments that otherwise would not be acceptable on the SA in 
question. This case, by itself, motivates the need to check with the 
receiver to ensure that the receiver will accept fragments on a 
port-specific SA. In this case there is no need to check to see if 
the security of the SA in question is "good enough," as there there 
was no ambiguity in mapping the non-fragmented packet to the SA.

Steve

---

From: Mark Duffy <[email-masked]>
Date: Thu, 25 Mar 2004 19:10:37 -0500

Thanks, Steve.  This gives a very nice summary of the issues!  And, I agree 
in general with the recommendations.  Some specific comments/questions 
embedded below...
--Mark

At 09:05 PM 3/22/2004 -0500, Stephen Kent wrote:
...
>In 2401bis, we have explicitly said that it's OK to use transport mode in 
>cases where the IPsec implementation is not the ultimate destination, 
>e.g., between two SGs. In principle, this creates a new opportunity for 
>outbound, plaintext fragments to be mapped to a transport mode SA for 
>IPsec processing. However, in these new contexts in which a transport mode 
>SA is now approved for use, it seems likely that we can continue to 
>prohibit transmission of fragments, as seen by IPsec. For example, in an 
>IP overlay network, packets being sent over transport mode SAs are 
>IP-in-IP tunneled and thus have the necessary inner header to accommodate 
>fragmentation prior to IPsec processing. When carried via a transport mode 
>SA, IPsec would not examine the inner IP header for such traffic, and thus 
>would not consider the packet to be a fragment. Thus it seems reasonable 
>to retain the prohibition on carrying IPv4 fragments on transport mode 
>SAs, even when the source or destination is an SG.

My suggestion would be to simply say (e.g. in 2401bis sect 4.1):

The use of transport mode by intermediate devices (e.g. SGs) is permitted 
only when applied to packets whose source (for outbound packets) or 
destination (for inbound packets) address is an address belonging to the 
intermediate system itself.  In these cases the intermediate system is 
essentially acting as a host with respect to those packets.

...
>If we simplify the procedure employed to locate the next layer protocol in 
>notion of an encrypted next layer protocol field has vanished, and there 
>is also no need to worry about encrypted port fields either.

Yes please.  In fact, I thought this was already decided.  I.e. in 
2401bis-01 section 4.4.2 Selectors:  'Next Layer Protocol: Obtained from 
the IPv4 "Protocol" or ...'

...
...

>without regard to port field values.

And must support bypass/drop rules that operate without regard to port 
field values, no?

...
>2. All implementations MUST support tunnel mode SAs that will carry only 
>non-initial fragments, separate from non-fragmented packets and initial 
>fragments.

And must support bypass/drop rules that will match only non-initial 
fragments, no?

...
>Also, because a SA of this sort will carry ALL non-initial fragments that 
>match a specified source/destination address pair and protocol value, 
>users and administrators are advised to protect such traffic using ESP 
>(with integrity) and the "strongest" integrity and encryption algorithms 
>available at both peers. (Determination of the "strongest" algorithms 
>requires imposing a total ordering of the available algorithms, a local 
>determination at the discretion of the initiator of the SA.)

Isn't it also at the discretion of the responder?

>3. An implementation MAY choose to support some form of stateful fragment 
>checking for a tunnel mode SA with non-trivial port field values (not ANY 
>or OPAQUE). Implementations that will transmit non-initial fragments on a 
>tunnel mode SA that makes use of non-trivial port selectors MUST notify a 
>peer via an IKE payload (TBD). The peer MUST reject this proposal if it 
>will not accept non-initial fragments in this context. If an 
>implementation does not successfully negotiate transmission of non-initial 
>fragments for such an SA, it MUST NOT send such fragments over the SA. 
>This standard does not specify how peers will deal with such fragments, 
>e.g., via reassembly or other means, at either sender or receiver. 
>However, a receiver MUST drop non-initial fragments that arrive on an SA 
>with non-trivial port selector values unless this feature has been negotiated.

This wording does not preclude an implementation from negotiating this 
feature but then failing to do the expected checking on received 
packets.  Should it state that if the feature has been negotiated, the 
receiver MUST NOT accept non-initial fragments without verifying that they 
comply with the security policy called for for the overall packet?

Also, I think that #3 also should state that a receiver that has negotiated 
the feature must not accept non-initial fragments for bypass without 
verifying that they comply with the security policy called for for the 
overall packet.

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

One final issue, does port selector ANY encompass OPAQUE?  To my 
sensibilities ANY means any value in the range (e.g. 0..65535) and the port 
values of an opaque packet are surely in this range even if we don't know 
them.

If there is some value (what is it?) in having an ANY concept that does not 
include OPAQUE, it should be clearly named e.g. ANY_NONOPAQUE.

Here is at least one specific reason why ANY *should* include 
OPAQUE.  (Yes, I realize that this is an arcane case.)  For approach #1 we 
use port-blind policies.  If ANY includes opaque then the port selectors 
are simply:

     source port = ANY, dest port = ANY.

But if ANY and OPAQUE are disjoint then (here's where it gets arcane 
;-)  it is possible that a an initial fragment will come along that 
contains the source port but not the dest port.  The policy for approach #1 
to cover this case would need to be:

     source port = ANY, dest port = ANY
or  source port = ANY, dest port = OPAQUE
or  source port = OPAQUE, dest port = OPAQUE

What administrator is going to think to provision that?

--Thanks, Mark

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 30 Mar 2004 18:00:19 -0800

Steve,

I am okay with your recommendations except for the second.

<SNIP>

> v6, for the reason cited. I'm comfortable with a MAY for v6.
Why is it a MUST for IPv4 ? You have just mentioned one case as a problematic
case for IPv4 in the conclusion and given a solution as to how one may overcome
this for IPv4. But the earlier sections in the document mentioned a few others
which indicate that one could get into problems by configuring fragment-only SAs.
If  the implementation takes the conservative approach of keeping it simple and secure
(Vs performance), isn't MUST a bit too strong ? 

thanks
-mohan

---

From: Stephen Kent <[email-masked]>
Date: Wed, 31 Mar 2004 15:55:25 -0500

At 7:10 PM -0500 3/25/04, Mark Duffy wrote:
>Thanks, Steve.  This gives a very nice summary of the issues!  And, 
>I agree in general with the recommendations.  Some specific 
>comments/questions embedded below...
>--Mark
>
>>destination, e.g., between two SGs. In principle, this creates a 
>>new opportunity for outbound, plaintext fragments to be mapped to a 
>>packets being sent over transport mode SAs are IP-in-IP tunneled 
>>and thus have the necessary inner header to accommodate 
>>fragmentation prior to IPsec processing. When carried via a 
>>transport mode SA, IPsec would not examine the inner IP header for 
>>such traffic, and thus would not consider the packet to be a 
>>fragment. Thus it seems reasonable to retain the prohibition on 
>>carrying IPv4 fragments on transport mode SAs, even when the source 
>>or destination is an SG.
>
>The use of transport mode by intermediate devices (e.g. SGs) is 
>permitted only when applied to packets whose source (for outbound 
>packets) or destination (for inbound packets) address is an address 
>belonging to the intermediate system itself.  In these cases the 
>intermediate system is essentially acting as a host with respect to 
>those packets.

I think some words along these lines can be used.

>>...If we simplify the procedure employed to locate the next layer 
>>protocols, then the notion of an encrypted next layer protocol 
>>field has vanished, and there is also no need to worry about 
>>encrypted port fields either.
>
>2401bis-01 section 4.4.2 Selectors:  'Next Layer Protocol: Obtained 
>from the IPv4 "Protocol" or ...'

just wanted to reiterate and make sure we all agree.

>
>>1. All implementations MUST support tunnel mode SAs that pass 
>>traffic without regard to port field values.
>
>And must support bypass/drop rules that operate without regard to 
>port field values, no?

  we should group the bypass/drop requirements together. just as they 
were discussed separately in the memo. sorry that I didn't make this 
explicit.

>>only non-initial fragments, separate from non-fragmented packets 
>>and initial fragments.
>

ibid.

>...
>>Also, because a SA of this sort will carry ALL non-initial 
>>fragments that match a specified source/destination address pair 
>>and protocol value, users and administrators are advised to protect 
>>such traffic using ESP (with integrity) and the "strongest" 
>>(Determination of the "strongest" algorithms requires imposing a 
>>total ordering of the available algorithms, a local determination 
>>at the discretion of the initiator of the SA.)
>

in the sense that a responder must agree to SA parameters proposed by 
the initiator. The initiator must propose only what he considers to 
acceptable algorithms given the context.

>>non-initial fragments in this context. If an implementation does 
>>not successfully negotiate transmission of non-initial fragments 
>>for such an SA, it MUST NOT send such fragments over the SA. This 
>>standard does not specify how peers will deal with such fragments, 
>>However, a receiver MUST drop non-initial fragments that arrive on 
>>an SA with non-trivial port selector values unless this feature has 
>>been negotiated.
>
>This wording does not preclude an implementation from negotiating 
>this feature but then failing to do the expected checking on 
>received packets.  Should it state that if the feature has been 
>negotiated, the receiver MUST NOT accept non-initial fragments 
>without verifying that they comply with the security policy called 
>for for the overall packet?

good point. we'll add that note.

>Also, I think that #3 also should state that a receiver that has 
>negotiated the feature must not accept non-initial fragments for 
>bypass without verifying that they comply with the security policy 
>called for for the overall packet.

we can say that too. but it is implied by the required, normal SA 
receiver processing rules.

>sensibilities ANY means any value in the range (e.g. 0..65535) and 
>the port values of an opaque packet are surely in this range even if 
>we don't know them.
>
>If there is some value (what is it?) in having an ANY concept that 
>does not include OPAQUE, it should be clearly named e.g. 
>ANY_NONOPAQUE.
>
>OPAQUE.  (Yes, I realize that this is an arcane case.)  For approach 
>#1 we use port-blind policies.  If ANY includes opaque then the port 
>selectors are simply:
>
>contains the source port but not the dest port.  The policy for 
>approach #1 to cover this case would need to be:
>

The memo says that ANY and OPAQUE are disjoint and it explicitly said 
that you would need to define an SA that used BOTH ANY and OPAQUE 
port selectors if you wanted a single SA for all traffic of this sort.

Nonetheless, I think you are right, i.e., we can redefine ANY to 
encompass OPAQUE and still be OK. OPAQUE must be kept separate to 
allow us to have a fragment only SA when we have port-specific SAs, 
but defining ANY the way you suggest makes it easier to define an SA 
that carries all traffic (non-fragmented, as well as initial and 
non-initial fragments) that otherwise matches the other selectors, 
when we want to not be port-specific. This makes it easier for admins 
too, as you note. Is also is more consistent with the convention I 
proposed for protocols that have no ports (or only on port), since I 
had suggested using ANY as the port field selector value for such 
protocols.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 31 Mar 2004 15:20:27 -0500

At 6:00 PM -0800 3/30/04, Mohan Parthasarathy wrote:
>Why is it a MUST for IPv4 ?

We would like to have at least one, mandatory way for two IPsec peers 
to carry fragments via SAs, when port-specific SAs are employed, 
hence we need at least one approach that is a MUST. The third 
recommendation would satisfy the requirement, but the reassembly 
process may be a hardship for very high speed implementations. That's 
why I suggested this option as a MAY. The reason for making the 
second recommendation the MUST, for IPv4, is because it satisfies the 
requirement, and does not seem likely to impose performance 
penalties. It is only a MAY/SHOULD for IPv6 because there are 
security problems for v6 when dealing with fragments w/o reassembly, 
as noted in the analysis.

>You have just mentioned one case as a problematic
>this for IPv4.

I noted a problem for v6 under recommendation #2, not for v4.

>But the earlier sections in the document mentioned a few others

There have been discussions about possible problems for IPv4 fragment 
handling w/o reassembly, but I think my analysis dealt with all of 
these concerns and thus I feel comfortable recommending that approach.

>(Vs performance), isn't MUST a bit too strong ?

Reassembly or reassmebly-like state tracking is not simple, although 
if properly implemented it is secure for both IPv4 and v6. That is 
its major benefit, in my view.

Steve