Re: 2nd try

[Stephen Kent <kent@bbn.com>]

At 4:36 PM +0300 4/1/04, Tero Kivinen wrote:
>Stephen Kent writes:
>>  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
>
>I think we should select the most secure protocol (i.e. case #3) as
>MUST, and allow #2 protocol for high-speed implementations as MAY.

#2 and #3 are equally secure in terms of IPv4. But, as you note 
below, #2 does not accommodate IPv6 securely. So, only in that sense 
is there a difference.

>This way we would always have one MUST to implement version which
>allows secure transport of fragments over port selector SAs, and the
>requirements would be same for the IPv4 and IPv6.
>
>>  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.
>
>So for IPv6 there is no MUST to implement protocol at all?

yes. I admit that this is not ideal, but you are correct that this 
would be the result if we made #2 a MUST and #3 a MAY.

>  > >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
>
>It is not that complicated either. Full reassembly code in the netbsd
>kernel is about 200 lines (not counting code for general queue macros
>etc), our partial and full reassembly code is about 1000 lines (it
>does quite a lot more than only partial reassembly).

As Paul noted, it is a lot more difficult in hardware, especially at 
very high speeds. My experience in designing such devices convinces 
me of that fact, as much as your experience in developing software 
has convinced you that it is not too complex in that context. (BTW, 
was this software for an end systems or an SG?)

>
>>  if properly implemented it is secure for both IPv4 and v6. That is
>>  its major benefit, in my view.
>
>Which is the reason I would like it to be MUST, or at least SHOULD,
>and the case #2 to be MAY.

How about a compromise? We could make #2 a MAY and #3 a SHOULD. A 
SHOULD is almost a MUST, with a loophole as noted below (from RFC 
2119):

SHOULD   This word, or the adjective "RECOMMENDED", means that there
    may exist valid reasons in particular circumstances to ignore a
    particular item, but the full implications must be understood and
    carefully weighed before choosing a different course.

This would allow a hardware implementation to not support #3, if 
doing so would adversely impact overall performance.

Steve