Subject: Re: Question on SA Bundle

From: Stephen Kent <[email-masked]>
Date: Wed, 9 Apr 2003 18:34:03 -0400

Markku,

>  > From: Stephen Kent <[email-masked]>
>
>>  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

---

From: Markku Savela <[email-masked]>
Date: Fri, 11 Apr 2003 00:48:55 +0300

> 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 :-)

> 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.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Apr 2003 09:56:05 -0400

>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.

>idea of unidirectional SA being a good choice for a primitive

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

---

From: Markku Savela <[email-masked]>
Date: Mon, 14 Apr 2003 22:36:50 +0300

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

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 :-)

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

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

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.

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

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.

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!

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Apr 2003 16:42:03 -0400

>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 :-)

>    Now, the packets at MN need to look like

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.

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

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.

>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.

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.

>IPSEC. Now, if B wants to access A outside, it needs IPSEC with SG and

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

---

From: Markku Savela <[email-masked]>
Date: Tue, 15 Apr 2003 01:04:46 +0300

Oh, I need to expand my example a bit. I said

  "protocol = tcp" -> "use different SA-pair for each connection"

and got from values extracted from the packet

  TS for SA: protocol=tcp, src_port=x, dst=port=y

Before someone says: "but IKEv2 has address and port ranges! Your
implementation does not support those, if it just extracts values from
packet!"

Answer: it's all in the local policy definition. It can use any
suitable method of mapping the packet into TS data. Even, actually
using the SPD selector ranges.

  "address-range" -> "use SA with matched address-range"

and TS would contain the address range (instead of single
address). But the key issue is: IKE does not need to know about
this. It would just see the TS.

---

From: Markku Savela <[email-masked]>
Date: Tue, 15 Apr 2003 00:54:47 +0300

> BUT the WG will have to decide if the added complexity is something
> we want to impose on all IPsec implementations.

This exactly why I want to separate policy from IKE. Policy syntax and
features would be just local implementation choice. This is then
mapped into standard "SA+TS" construct. IKE should operate with
this, without knowing anything about the original policy.

> For example, in v2 the initiator sends SPD selector data showing the
> the SA.

I want the same, except that what is sent over is NOT the SPD selector
data, but something that is extracted from the packet triggering the
negotiation. I think we have "terminology problem". An example, I can
have a policy

In my terminology, from above it follows:

  SPD selector: "protocol = tcp"

My claim is just: IKE does not need the "SPD selector". It just needs
the "TS for SA" -part. And, that it should just negotiate this single
unidiretional SA, and let the other end trigger negotiation of the
other SA of the pair.

I think, TS as defined in IKEv2 is fine. Just don't equate it with SPD
policy selector.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 15 Apr 2003 18:33:33 -0400

>I think, TS as defined in IKEv2 is fine. Just don't equate it with SPD

If one just sends over data from the packet that triggers creation of 
an SA, the responder does not know what range of traffic can be sent 
over the newly created SA. Only if both peers have identical SPD 
entries for the packet in question would this be sufficient. 
Otherwise, the responder, not knowing the initiator's policy, might 
either create unnecessary SAs for other traffic he wanst to send, 
(which is a waste of resources) or the responder may send traffic 
over the SA that will be rejected by the initiator (which causes 
trouble shooting problems, another form of wasted resources).

By sending over the SPD data relevant to the SA being created, the 
initiator avoids these problems. In the past, we insisted on 
perfectly matched SPD entries for SAs, and I am told that it creates 
lots of config management problems. So, the goal going forward is to 
allow communication to occur when there is an overlap in the 
acceptable traffic relative to a proposal, and to communicate that in 
the IKE exchange. This will alleviate some config management problems 
and yet not create any problems with the two forms of resource waste 
noted above.

I guess I don't really understand your motivation for not having IKE 
convey the policy info from the SPDs to avoid future problems. Do you 
envision other ways to convey this data, or do you not believe that 
it is worthwhile to avoid the sort of problems noted above?

Steve

---

From: Markku Savela <[email-masked]>
Date: Wed, 16 Apr 2003 23:42:59 +0300

> it is worthwhile to avoid the sort of problems noted above?

The current IPSEC/IKE architecture seems to be something like

    +-------------------------+
    | TCP/IP Stack +          |
    |   IPSEC processing      |
    |   ^  (AH/ESP/RFC-2401)  |
    +---|----------|----------+
        |          | Key API
        |          | 
      Policy ---> IKE

I believe the "Policy --> IKE" link should not be there (not for
PHASE2 SA's at least). For IKE all that is needed, is KEY API.

This would be simpler architeru, with clean interfaces between
modulesK:

    +-------------------------+
    | TCP/IP Stack +          |
    |   IPSEC processing      |
    |   ^  (AH/ESP/RFC-2401)  |
    +---|----------|----------+
        |          | Key API
        |          | 
      Policy      IKE

IPSEC asks the keys via Key API (in my case, this is PFKEYv2). The
"ACQUIRE" just contains the requested TS parameters.

With this architecture, building IKE and IPSEC can be done
independently. If you have two IPSEC implementations for the host, you
could swap IKE implementations freely between them, and still have a
working system.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 17 Apr 2003 16:47:28 -0400

>The current IPSEC/IKE architecture seems to be something like

I would not draw the diagram that way. When I speak on IPsec I don't 
have a diagram that looks at all like that.  I won't try to convert 
my PPT slides for outbound and inbound processing into ASCII diagrams 
now, but they will appear in the 2401bis I-D later this summer.

Note that 2401 does not refer to a "Key API" nor does it say how in 
detail how the SPD is populated.

Steve