RE: CONSENSUS TEST: Fragmentation handling

[Stephen Kent <kent@bbn.com>]

At 5:06 PM +0100 4/7/04, Michael Roe wrote:
>This proposal is OK with me, although I have a few small quibbles:
>
>(a) I'd prefer "MAY" rather than "SHOULD" for #3 (stateful fragment
>     checking), but don't feel very strongly about it.

if neither #2 or #3 is a SHOULD, then I would like to add text that 
every implementation MUST implement at least one of these, to give us 
a decent chance of having a way to accommodate fragments for 
port-specific SAs. in fact, maybe that is the best way to state this, 
given the current set of comments on this topic.

>(b) In #1, I agree with Steve Kent's proposal to have the "ANY" selector
>     match non-initial fragments (the packets that match "OPAQUE" are
>     a subset of the packets that match "ANY") -- See Steve's revised version
>     of #1.
>
>(c) > 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.)
>
>     (i) To be pedantic, you don't need a total ordering - it can work with
>         some partial orderings.
>
>         forall x in initiatorAlgorithms
>             Less_Than_Or_Equal_Initiator (x, negotiatedAlgorithm)
>
>         forall y in responderAlgorithms
>             Less_Than_Or_Equal_Responder (y, negotiatedAlgorithm)
>
>          As long as negotiatedAlgorithm exists, you're OK -
>          Less_Than_Or_Equal_Initiator and Less_Than_Or_Equal_Responder
>          can be partial orderings.
>
>     (ii) It's not just at the discretion of the initiator. As I understand it,
>          both intiator and responder take their local ipsec policies,
>          and their own idea of what the ordering on algorithms is, 
>and separately
>          decide which algorithms are acceptable for the fragment 
>only SA. IKE then
>          attempts to negotiate a choice in the intersection of these 
>two sets of
>          acceptable algorithms.

I thought that a responder may choose only from among the set of 
proposals the initiator offers. if so, then the intitiator could look 
at all of the alg suites that he would use for any traffic that is to 
be protected when negotiating SAs for the peer in question, and 
choose the strongest as the only one proposed. If he imposed a total 
ordering, this would be possible. It is not clear that, in practice, 
people select different alg suites on a per-peer basis, and we do 
have mandatory to implement defaults. So, if the defaults are good, 
it is not clear that we would have problems. in the past, when DES 
was the default, it was probably common to see folks negotiate "up" 
to a better algorithm, but going forward this would seem to be a moot 
issue.

Steve