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

Re: Question on SA Bundle




Markku,

>  > From: Stephen Kent <kent@bbn.com>
>
>>  If folks think this is not the right path for 2401bis, let me know.
>
>In my understanding "bundle" is loose concept, e.g. in a policy I
>could specify
>
>   selector1 -> apply SA1(AH), apply SA2(ESP), apply SA2(ESP)
>   selector2 -> apply SA2(ESP)
>
>Bundle is just a set of IPSEC transformations (and SA's) that are
>specified to be applied to a packet that maches a particular
>selector. The same component SA can be used in different "bundles".

I don't think the term bundle is all that vague. It is intended to 
specify how multiple IPsec protocols are to be applied to a single 
traffic flow, as defined by a single set of selectors.

>That's about all that "bundle" means to me. Unfortunately, IKEv1
>thinks/requires more strict "bundle" concept. It cannot negotiate
>individual SA's belonging to same "bundle" separately, or share SA's
>between bundles.

Yes, that's what I said.

>Key management should negotiate SA's individually.

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.

>Speaking of bundles, I just currently trying examine how to get IPSEC
>to work with MIPv6.
>
>Assume you have mobile node (MN) and correspondent node (CN), home
>agent (HA). Assume CN is some service that requires IPSEC to be
>used. Thus I have a policy
>
>   remote=CN -> use CN-SA
>
>works just fine, as long as MN is at home, with packets
>
>   IP: dst=CN
>       src=MN-home
>       IPSEC(CN-SA)
>       Payload
>
>Now, when MN moves away from home, one possibility is tunneling the
>packets via home agent. However, MN - HA path must also be protected
>by IPSEC. Thus the required packet leaving from MN must look
>
>   IP: dst=HA
>       src=MN-care
>       IPSEC(HA-SA)
>   IP: dst=CN
>       src=MN-home
>       IPSEC(CN-SA)
>       Payload
>
>It just happens that I can generate above packet using existing IPSEC
>implementation by writing a policy (because it allows pretty random
>combination of IPSEC transforms)
>
>   away-from-home and remote=CN -> use CN-SA, use HA-SA (tunnel=HA)
>   at-home and remote=CN -> use CN-SA
>
>However, there is no hope for IKEv1 or IKEv2 to handle this. Manual
>keys work. (system will ask the two SA's with two separate ACQUIRE
>requests using PFKEYv2).
>
>I've been fairly happy with 2401 as is. I hope the flexibility that it
>allowed is not reduced too much to make things like in above
>non-standard.

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.

Steve