[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: On the Use of SCTP with IPsec
In message <p05010407b6bc5f290fe2@[128.33.4.39]>, Stephen Kent writes:
>
>Creating a bunch of SPD entries would have an impact on steady state
>processing, except to the extent that one decorrelates the SPD (and
>it's newly created entries) and thus can cache them. This is because
>the base spec calls for a linear search of the SPD for every outbound
>packet. But, yes, if we're clever, this may be overcome to a great
>extent.
The SPD entries in the SCTP case are almost by definition decorrelated (each
endpoint is identified by a set of distinct IP* addresses, the SPD entries
generated are simply the pairwise combinations of these). You have a choice
of simply more SPD entries, or more "complex" ones, in the implementation.
>I'll have to look into the proposal in more detail, but it does seem
>that it might entail potentially greater steady state processing
>costs.
I'm not sure what you mean by "steady state processing"; as I said, the end
result of any negotiation involving SCTP is either a larger number of SPD
entries, or the need for more complex structures/processing (both outlined
in the draft). There's simply no way around it: think of SCTP with n*m
addresses as n*m distinct host-to-host flows.
>Also, if I understand your comment, you're suggesting that we
>can keep current IKE payload formats, but change the processing of
>the content, which really is a protocol change. I'm not sure its
>preferable to focus so much on preservation of formats vs. processing
>in this case; either is a change of the protocol in the bigger
>implementation sense, right?
It's a change of protocol only to the extend that adding (for example) a new
encryption algorithm identifier (as happened with AES) was a change in the
protocol. The contents of one of the payloads changed, but not the number or
type of payloads in any messages. Processing costs in both cases (recursive IDs
vs. multiple IDs/message) is likely to be the same -- the same IDs will have to
be verified, stored, and processed in exactly the same way.
All that said, I'm not sure which case is preferable either, which is why both
are listed in the draft.
-Angelos
References: