[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: On the Use of SCTP with IPsec
Ari,
>Jari Arkko wrote:
>>
>> First, I'd like to note that the recursive identity
>> type might be useful for also other purposes. For
>> instance, I could specify that a per-port tunnel
>> includes not just e.g. TCP:23 but also ICMP traffic,
>> by using an identity (TCP:23 n.n.n.n) AND (ICMP n.n.n.n).
>> If the recursive type is to be used for such purposes,
>> then we should allow more component types than
>> IPSEC_ID_IPV4_ADDR, and we would need a clear
>> semantics for the treatment of the multiple protocol
>> and port fields in the recursive identity payload.
>
>I haven't read that draft you refer to, but I'd vote against
>'recursive identity types'. An ordinary identity type is
>already pretty complex to encode/decode, with all checks.
>
>I'd be very happy, however, if we could have the identity payload have
>1) minimum and maximum protocol ID, if both are zero then to be ignored
>2) minimum and maximum port, if both are zero then to be ignored
>3) In QM we could have several identity payloads for allowed
> initiator traffic values, and similarly several identity payloads
> for allowed responder traffic values
>
>This would enable tight integration of firewall aspects of
>our product with the IPsec aspects. Customers would be mighty happy.
I've made similar suggestions earlier, i.e., we have an inconsistent
set of options for expressing selector values. Originally 2401
allowed individual values, ranges, and enumerated lists for all
selectors. It was late in the process when we discovered that IKE
didn't allow all of these, and was uneven in what it supported for
different selector fields. I'd recommend that IKE be enhanced to
support those three means of specification of values for all 5
selectors.
While recursive identities are sexy, I too worry that we could easily
make the selector processing too complex, with adverse implications
for high speed IPsec implementations.
Steve
Follow-Ups:
References: