[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.
- Follow-Ups:
- Re: 2nd try
- From: Ravi <ravivsn@roc.co.in>
- 2nd try
- From: Tero Kivinen <kivinen@iki.fi>
- Re: 2nd try
- From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
- Re: 2nd try
- From: Mark Duffy <mduffy@quarrytech.com>