[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Interoperability issues in setting up SAs
Paul,
>[...]
> After the WG has decided what it wants to do about SA specification,
> the WG should help increate interoperability by specifying that
> TheNextKeyExchangeAlgorithm *only* allow one type (probably range,
> the most flexible). No need to get into that now, other than to
> possibly disagree with the statement above about how wonderful
> interop is today on this.
I agree on the interop issue from first hand experience... ;)
There are also IKEv1 implementations that will choke if they get a pair of
single IP address selectors in QM, when they are negotiating transport
mode. Such payloads would, of course, be redundant, but may result from
some generic policy lookup algorithm.
An alternative to what you suggested is to have the specification say
unambiguously which type must be used, and allowing just a single encoding
for a given case. I.e., a single address MUST be encoded as a single
address, a subnet or a range that can be represented as subnet MUST be
encoded as a subnet, and others as ranges.
The same should apply to e.g. IKEv2 attributes. The specification should
(in my opinion) mandate a unique encoding for attributes (minimum length).
I don't think has been a really big issue, though. (I think there was an
implementation that didn't accept 3-byte attribute encodings, though.)
In any case, specifying just one generic type (as you proposed) above
seems like the best choice wrt selectors, since it's much simpler.
-Sami
References: