Re: 2nd try

[Ravi <ravivsn@roc.co.in>]

      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
>
> 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.
>