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

2nd try

Stephen Kent writes:
> 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.

I agree for not allowing that. 

> Tunnel Mode and Fragments
...
> 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.

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

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

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

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

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

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

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

> 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 

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

> 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 

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

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

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 
> 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.
-- 
kivinen@safenet-inc.com