[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

2nd try



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.