Re: 2nd try

[Stephen Kent <kent@bbn.com>]

At 6:00 PM -0800 3/30/04, Mohan Parthasarathy wrote:
>  Steve,
>
>I am okay with your recommendations except for the second.
>
><SNIP>
>
>     > >  > 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).
>>
>>  I'm flexible on what the encoding should be for OPAQUE in IKEv2.
>>
>>  >  > 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
>>
>>  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.
>>
>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
>case for IPv4 in the conclusion and given a solution as to how one 
>may overcome
>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
>which indicate that one could get into problems by configuring 
>fragment-only SAs.

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.

>If  the implementation takes the conservative approach of keeping it 
>simple and secure
>(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