Re: Question on SA Bundle

[Stephen Kent <kent@bbn.com>]

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