[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Question on SA Bundle



At 12:48 AM +0300 4/11/03, Markku Savela wrote:
>  > From: Stephen Kent <kent@bbn.com>
>
>>  In general I agree, but if we do that, and if we want to be able to
>>  support bundles, then we need to add complexity to IKE to be able to
>>  specify how multiple SAs relate to one another. In the general case,
>>  that seems to be messy, which is why I believe we probably ought not
>>  try to support this going forward, consistent with our overall
>>  attempt to simplify IPsec.
>
>It would be GREAT simplification of IPSEC if the key management
>negotiated only individual unidirectional SA's by default. No policy
>checking for Phase2 SA's. I've repeated this for 4 years now, and been
>ignored. Let this be my one yearly reminder of the fact :-)

Yes, you are consistent in your views :-)  However, we've had this 
discussion before and I believe the consensus is that IPsec is a 
security protocol, not just a crypto protocol. Access control really 
underlies why many folks will use IPsec, and thus access control is 
an essential feature of the protocol.

>  > Flexibility is good, except to the extent that it introduces
>>  complexity. I don't think flexibility is good if it serves primarily
>>  to allow non-interoperable implementations to claim conformance with
>>  a "flexible" standard. We have to be careful in that regard.
>
>Flexibily can be achieved without complexity. Consider analogy of high
>level language and machine code. In my view IPSEC base RFC's should
>describe the easy to implement "machine code", consisting of primitive
>operations, that are clear and easy to implement. Everything is
>already almost there (RFC 2401, PFKEY, ESP/AH). I always liked the
>idea of unidirectional SA being a good choice for a primitive
>unit.

I agree that what you suggest would be simpler, but very few 
applications deal with only unidirectional traffic.  Thus the 
offered, simpler service you suggest would not match well what 
applications really do. In that case, the loss of functionality that 
would accompany the increased simplicity is a poor tradeoff, IMHO, 
since we would have to do do additional work establishing pairs of 
unidirectional SAs via separate negotiations, which hardly seems 
worth the extra effort.

I think the bottom line is that we have an ability to create paired 
AH/ESP SAs now, and we can retain that going forward, even though 
this will not be the common case, i.e., usually just ESP will be 
used.  If folks really want to add in the ability to do nesting of 
SAs by creating bundles, then we need to add it now to IKE v2, or 
I'll plan to drop it from 2401bis.

Steve

Steve