Re: 2nd try

[Tero Kivinen <kivinen@iki.fi>]

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.

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. 

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

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

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

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.

This way you are always putting the fragments to the same SA which
contained the port-fragment if you support #3 and to the non-port
fragment SA if you only support #2. Note, that traffic for each
direction may use different SAs, i.e. traffic from SGW 1 to 2 may use
non-port fragment SA for non-port fragment, and traffic from SGW 2 to
1 may always use port-fragment SAs, and never send any traffic inside
the non-port fragment SA.

When you receive packet from any SA, you do the policy checks, and if
your policy check is that any non-port fragment can go through, then
there is no need to do partial reassembly at all (even in case #3). If
you policy is that always verify the port selectors, then you need to
do partial reassembly for all fragment regardless which SA (or bypass
rule) was used to receive it.

This mixing of case 2 and 3, assumes that you can have some kind of
ordering of the SAs, saying that this security is enough for the
non-port fragments. This can be also done so that the adminstrator
creates the list of allowed algorithms for the non-port fragments
(incoming), and if system only supports #2, then adminstrator needs to
specify algorithm for the outgoing non-port fragments too.
-- 
kivinen@safenet-inc.com