[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@xxxxxxx>

 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