Re: 2nd try

[Stephen Kent <kent@bbn.com>]

Tero,

<SNIP>

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

Yes, there was a disconnect between IKEv1 and what 2401 said, and the 
goal here is to fix that with 2401bis and IKEv2.

<SNIP>

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

Agreed, But 2401bis assumes use of IKEv2 in several instances, so I 
don't see this as a problem.

<SNIP>

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

I agree that the second rule would be a bad config choice. But I 
disagree with the conclusion that one must do some form of reassembly 
if fragments are allowed to bypass. We ought not impose this 
requirement just to counter the bad effects of a bad config choice.


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

yes.

>Is this negotiated with IKEv2 by setting the port field range to
>0-65535 (==ANY).

ANY and OPAQUE must both be specified to accommodate all possible 
traffic types (whole packets, as well as all fragments).

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

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

Since it appears that nothing short of reassembly will be safe for 
v6, I think it is important to add this case. Also,  you and some 
other folks have indicted that this approach seems reasonable for 
many contexts, where very high speed
processing it not an issue. So, my reason for including #3 above is 
to allow folks who want to do reassembly to do it, but not to impose 
it as a burden for folks who don't feel that this strategy is 
compatible with their system requirements/architecture.

Steve