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

Re: Question on SA Bundle

At 10:36 PM +0300 4/14/03, Markku Savela wrote:
Back to bundle issue, why I want "bundle" to be a rather loose concept:

- bundle is just a collection of SA's that are required

You ignored my example from MIPv6. As I earlier presented

I ignored your example because there is a separate document from the MIPv6 WG that talks about how to support those requirements. I am working with the authors to try to understand what it requires and how it relates to 2401. I find it confusing enough to focus on that for now :-)



1) MN is at home, talks to CN. CN could be web server or mailbox that
   requires some IPSEC for access. We have policy

remote CN -> CN-SA()

2) MN moves away from home. Suddenly MN needs IPSEC with HA agent

remote HA -> HA-SA()

3) MN still wants to communicate with CN. MIPv6 calls for tunneling
   the traffic via HA. From IPSEC viewpoint HA is like a SG, and the
   whole internet is the protected network.

Now, the packets at MN need to look like

   Outgoing:             Incoming:
   ---------             ---------
   IP: dst=HA            dst=COA
       src=COA           src=HA
       IPSEC with HA-SA  IPSEC with HA-SA
   IP: dst=CN            dst=HOME
       src=HOME          src=CN
       IPSEC with CN-SA  IPSEC with CN-SA
       Payload           Payload

SOMEHOW, above MUST be achieved. Surely there are many ways. BUT, in
MY IPSEC policy I could express the requirement and rule to achieve
above as (roughly, not going here into detail of how I separate "at
home" and "at away", trust me I can do it :-)

MUST is a very strong term :-) It may be very desirable, but whether it must be supported is yet to be decided. As we have discussed in our off-list message exchanges, your ideas about policy expression may go beyond 2401. As part of revising 2401 it is possible that the SPD policy expression may be expanded to accommodate more complex policies, BUT the WG will have to decide if the added complexity is something we want to impose on all IPsec implementations. Also, you and I disagree over whether it is necessary for IPsec peers to notify one another of the policy that will be applied to packets as part of the IKE negotiation. I believe that, in general, IKE v2 has moved in the direction of providing this info, even more so than IKE v1. For example, in v2 the initiator sends SPD selector data showing the range of values associated with an SA that is being created, to enable the peer to know the range of traffic that can be carried on the SA. Your proposals seem to head in the other direction, i.e., not wanting peers to exchange this data in IKE.


remote CN -> CN-SA(), HA-SA(tunnel to HA)

I don't want this solution to become "non-conformant". It works for
me!

I don't understand the example well enough to comment, but I will say that just because someone has implemented some features does not mean that the features are conformant today.

Now, this looks like a "bundle": a selector and two SA's, and this is
how it's handled in IPSEC packet processing. Packets matching "remote
CN" must have both CN-SA and HA-SA(tunnel) successfully applied for
incoming and outgoing.

However, as far as key management (IKEv1 or IKEv2) are concerned, this
is really two different Phase1 associations, one negotiated between
HOME and CN, and other negotiated between HOME and HA.

Again, we seem to have a mismatch between a desire to decouple SA parameters in each peer from what IKE negotiates. In general, I think the WG has adopted the position that this is not a good idea. Rather, it seems desirable to have each peer understand the other's view of the SA, to avoid confusion.

------------

Above is prime example why I don't like IKE (or any key management) to
mess/check policy in phase2. Policy is just too complex for them to
handle. I want to be able to work on policy definitions and
echancements independently of key negotiation implementation.

If one looks at what IKE does (both v1 and v2) it is clear that most of the complexity resides in the SA management aspects of the task, not in the key management aspects. So, what I think you are saying is that you would like to have a protocol that focuses mostly on key management, and a separate protocol that addresses other aspects of SA management, including policy aspects. This sounds like what JFK was doing, but the WG elected to not pursue that path. I think in part this is because the WG realized that policy support is critical and if we don't deal with it now, we will have implementations that create SAs but fail because of a lack of a standard way to express policy over what traffic is supposed to flow over the SAs.

Similar example can occur even without mobile IP, say

      |
   A -|--- SG ====== B

where A has some highly classified data. You don't want to pass it
clear, even within internal net. Thus any communication with A needs
IPSEC. Now, if B wants to access A outside, it needs IPSEC with SG and
A simultaneously!


I have trouble following your text, but this sounds like the nested SA example (case 4) that 2401 calls out. Unfortunately, we've not had a means to specify this in IKE v1, so it seems that it is hard to make work in practice. If the WG feels that we need this capability, we can retain it in 2401bis, but we need to be able to say how the nesting is specified, from a management perspective.

Steve