Re: 2nd try

[Stephen Kent <kent@bbn.com>]

At 3:22 PM +0200 3/25/04, Tero Kivinen wrote:
>Stephen Kent writes:
>>  >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.
>
>I was commenting that IKEv1 does not support it, thus there cannot be
>implementations supporting that format => if we mandate that now in
>the RFC2401bis then all implementations needs to add new code to
>support that.

agreed, but 2401bis also requires support for other features that 
arise only in IKEv2, so this would not be the only reason that 
new/changed code is required.

>On the other hand there is (several?) implementations out which do
>partial reassembly, which means that it is already tested and working
>method of fixing that problem.

yes, and that's a good reason to include it as an option, but not as 
a mandatory facility.

>  > >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.
>
>If we do not add that requirements, then the problem is that if user
>uses vendor 1 IPsec with that configuration and which uses the partial
>reassembly it is secure, but if he switches to vendor 2 IPsec which do
>not do partial reassmebly his working policy suddenly comes insecure.
>That can be quite suprise to the adminstrator, and I think some kind
>of warning for the implementators should be in the text, if there is
>no requirement for partial reassembly.

I'm all in favor of a warning.

>  > >>  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.
>
>The "why?" was for "why do you need to notify that with IKE?".

The need to notification is required, I think, because support for 
reassembly is not mandated in my proposal. So if an implementation 
sends fragments across an SA that requires port checking, the 
receiver should reject non-initial fragments  unless it has said that 
it is prepared to deal with them via reassembly (prior to checking).

>
>>  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.
>
>I think we do need case #3, but I do not think we need to negotiate it
>with notifications. I also think that case #2 and case #3
>implementations can interoperate without any problems.
>
>I use port fragment to indicate the fragment which contains the port
>numbers, and non-port fragment to indicate the fragment which do not
>have port numbers.
>
>If you ONLY support #2, then you create non-port fragment SA, and you
>accept any non-port fragments from there. You MUST also accept any
>non-port fragments from any port fragment SA, provided that the
>security of that port fragment SA is "enough" compared to the non-port
>fragment SA. There is no need to do any partial-reassembly for any of
>the traffic regardless whether it was received from the non-port
>fragment SA or from port fragment SA.

agreed, but this works only for IPv4.

>If you support #3, then you MUST send all non-port fragments to same
>port-fragment SA which was used for the fragment containing the port
>numbers of the packet. When you receive fragments from the any source,
>you do the partial-reassembly and verify that the packet is allowed by
>policy. If the fragment was received from the any other SA than which
>would carry the port-fragment of the packet, then you also need to
>verify that the security of that SA is "enough" compared to the
>port-fragment SA, which should have been used.

A sender might choose approach #3 because he will receive 
non-fragmented packets, map them to a port-specific SA, then fragment 
them on the protected side, and send them over the port-specific SA. 
in this simple case the receiver needs to be willing to deal with the 
fragments that otherwise would not be acceptable on the SA in 
question. This case, by itself, motivates the need to check with the 
receiver to ensure that the receiver will accept fragments on a 
port-specific SA. In this case there is no need to check to see if 
the security of the SA in question is "good enough," as there there 
was no ambiguity in mapping the non-fragmented packet to the SA.

Steve