Subject: [Ipsec] Number of SPD Policies

From: "Subha" <[email-masked]>
Date: Fri, 1 Apr 2005 12:21:02 -0800

Hi List-members,

If I need to apply both ESP and AH SAs between the two 
security gateways for a given traffic stream, do I need to 
create two policies or one policy ? 

Can someone indicate this with repect to the following combinations

1) IKEv1 + 2401
2) IKEv1 + 2401bis
3) IKEv2 + 2401
4) IKEv2 + 2401bis

>From IKEv1 or IKEv2 perspective, my understanding is that there are
no restrictictions posted. 

2401bis seems to indicate that if there is nested tunneling  i.e. if
the security tunnel is going to terminate in 2 different remote gateways, 
then we need to have two SPD policies. (Reference Appendix -E in 2401-bis)

However if the terminating tunnel endpoint is the same remote gateway and
both ESP and AH needs to be applied to a particular traffic stream, then 
a single SPD Policy should suffice. I did not see any statement in 2401-bis 
restricting this.

Can someone please clarify ?

Thanks,
Subha 

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Stephen Kent <[email-masked]>
Date: Fri, 1 Apr 2005 17:32:11 -0500

>Can someone indicate this with repect to the following combinations

YES, the status quo

>2) IKEv1 + 2401bis

not a good match, because 2401bis mandates support for features 
available in IKEv2 that are not in IKE v1.

>3) IKEv2 + 2401

this combination should work.

>4) IKEv2 + 2401bis

YES, the intended match up

>then we need to have two SPD policies. (Reference Appendix -E in 2401-bis)

What 2401bis says is that to accommodate a nested SA, in general, one 
will need multiple SPD entries and coordinated entries in the 
forwarding tables on both the protected and unprotected sides of the 
IPsec boundary. It does not say this is an issue that arises when the 
endpoints for the tunnel are distinct. The example in Appendix E is 
just an example, not a comprehensive discussion of how one configures 
the SPD and forwarding tables to accommodate nesting in general.

>a single SPD Policy should suffice. I did not see any statement in 2401-bis

In the example you cited above, applying AH and ESP to traffic, note 
that the SPD definition in 2401bis specifies application of only one 
security protocol per SA. So I believe that more than one SPD entry 
is required to achieve even this simple nested SA example.

Steve

---

From: "Subha" <[email-masked]>
Date: Fri, 1 Apr 2005 16:35:59 -0800

Re: [Ipsec] Number of SPD PoliciesHi  Steve,

I have some follow-up questions.

In the following questions I have assumed that 3 IPsec Protocols shall be applied
on a given traffic stream.

1) When IKEv2 is used with RFC2401 compliant implementation, can a single IKEv2 
CREATE_CHILD_SA negotiate IPcomp, ESP and AH SAs for the given traffic 
selector? 

2) When IKEv2 is used with RFC2401-bis compliant implementation, there has to 
be theee IKEv2 CREATE_CHILD_SA Exchanges.

(1) Plain Traffic selectors for IPcomp SA
(2) Same Source IP, Destination IP and IPComp for Protocol  - Traffic Selectors for ESP SA
(3) Tunnel Outer Header Source IP, Tunnel Outer Header Destination IP and Protocol=ESP
 for AH SA.

3) An implementation needs to know through some other means, 
whether the peer supports RFC2401 or 2401-bis. 

Thanks,
Subha

  ----- Original Message ----- 
  From: Stephen Kent 
  To: Subha 
  Cc: [email-masked] 
  Sent: Friday, April 01, 2005 2:32 PM
  Subject: Re: [Ipsec] Number of SPD Policies

    1) IKEv1 + 2401

  YES, the status quo

    2) IKEv1 + 2401bis

  not a good match, because 2401bis mandates support for features available in IKEv2 that are not in IKE v1.

    3) IKEv2 + 2401

    4) IKEv2 + 2401bis

  What 2401bis says is that to accommodate a nested SA, in general, one will need multiple SPD entries and coordinated entries in the forwarding tables on both the protected and unprotected sides of the IPsec boundary. It does not say this is an issue that arises when the endpoints for the tunnel are distinct. The example in Appendix E is just an example, not a comprehensive discussion of how one configures the SPD and forwarding tables to accommodate nesting in general.

  In the example you cited above, applying AH and ESP to traffic, note that the SPD definition in 2401bis specifies application of only one security protocol per SA. So I believe that more than one SPD entry is required to achieve even this simple nested SA example.

  Steve

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 4 Apr 2005 14:55:14 +0300

Subha writes:
> 1) When IKEv2 is used with RFC2401 compliant implementation, can a
> single IKEv2 CREATE_CHILD_SA negotiate IPcomp, ESP and AH SAs for
> the given traffic selector?

Trying to use IKEv2 and RFC2401 is not very good idea, as some of the
features of the IKEv2 cannot be expressed in the RFC2401 policy. Also
the same thing applies to other way around, meaning that IKEv2 is
mostly matching RFC2401bis. This means that especially implementations
will only support IKEv2 for the features required for the RFC2401bis.
As RFC2401bis does NOT require ESP and AH to be negotiated
simultaenously, I guess most of the implementations WILL NOT support
it.

IPcomp can be negotiated in addition to the ESP or AH in the IKEv2
too, but the negotiation is quite different than what was for IKEv1
(or RFC2401).

Also note, that IKEv2 draft explicitly mandates RFC2401bis handling of
the ECN flag, i.e. meaning that you cannot use base RFC2401 with
IKEv2, you need to extend your RFC2401 implementation to include
RFC2401bis ECN handling if you want to use IKEv2. 

> 2) When IKEv2 is used with RFC2401-bis compliant implementation,
> there has to be theee IKEv2 CREATE_CHILD_SA Exchanges.

No. IKEv2 allows IPcomp to be negotiated only when some other child SA
is negotiated. IPComp is mostly outside the scope of IPsec,and
RFC2401bis does not really cover that at all (it just mentions that it
can be negotiated).

You do 2 CREATE_CHILD_SA exchanges.

> (1) Plain Traffic selectors for IPcomp SA

There is no way to do that in IKEv2, you MUST have either ESP or AH.

>     Traffic Selectors for ESP SA

No, Plain traffic selectors for ESP SA, and include IPCOMP_SUPPORTED
notify to mention that you want to do ip compression. 

> (3) Tunnel Outer Header Source IP, Tunnel Outer Header Destination
>     IP and Protocol=ESP for AH SA.

Yes, this is the second one. 
-- 
[email-masked]

---

From: "Subha" <[email-masked]>
Date: Mon, 4 Apr 2005 13:08:13 -0700

Hi, 

It looks like 2401bis brings up a limitation that we cannot
define different AH strength for ESP encrypted packets
between the same two security gateways.

For e.g. let us assume the following scenario. 

Local           local            Remote     Remote
LAN              GW                GW        LAN
10.1.5.x-------66.80.90.10----66.80.10.2----192.168.1.x
10.1.6.x--------66.80.90.10----66.80.10.2----192.168.2.x

As per RFC 2401, we could define two SPD Policies for each of them, 
especially AH strength can be different for both of them.

for 10.1.5.x to 192.168.1.x.We could define AH= MD5 and ESP=DES.
for 10.1.6.x to 192.168.2.x We could define AH=SHA and ESP=3DES.

But with 2401bis, we can define only one AH encryption strength 
for both the policies.

i.e.for SPD1 10.1.5.x to 192.168.1.x ESP = DES  -ReturntoIpsec
i.e.for SPD2 10.1.6.x to 192.168.2.x ESP = 3DES -ReturntoIpsec
i.e for SPD3 66.80.90.10 to 66.80.10.2 AH = MD5 -ForwardOut

We can no longer specify service based cryptographic strength, 
if the Service is ESP between the two tunnel endpoints.

Is this understanding correct ? 

To overcome this limitation, a configuration can allow 
Administrator to enter ESP and AH transform in the same policy.
If the Policy is 2401bis, the implementation can negotiate
using IKEv2 with the peer, for 2 sets of traffic selectors,
one with Plain Taffic selectors and the other with Tunnel header
IPs + ESP traffic selector.  By this mechanism, the AH Algorithm 
applied to a given packet will depend on the selectors of the 
clear text packet. Of-course, there may be implications on
IKEv2 also based on this. But this is one mechanism that can 
be considered  to provide service level cryptography strength.

Also, in the above example, if the forwarding entries such 
as ReturntoIpsec was not present for SPD1, rather 
ForwardOut was configured, the encrypted ESP packet would 
be directly sent out.  Is this a correct understanding ?

Thanks,
Subha

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 5 Apr 2005 12:14:48 +0300

> between the same two security gateways.

Yes, I think you are right.

The question is: Is there any reason to really do that? Why are you
doing AH+ESP between the local GW and Remote GW in any case, why are
you not simply using ESP with suitable auth algorithm?

As you are using tunnel mode there AH does not offer anything more
compared to the ESP.

The only case where I can see there would be use for AH+ESP is when
the AH and ESP are terminated by different hosts, i.e. AH goes to from
host to firewall, and the ESP goes from host through the firewall to
the other end host.

As there EVER any valid scenario where you would need to use AH+ESP
where both of those are terminated by same peers?
-- 
[email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Wed, 6 Apr 2005 04:44:52 -0400

At 4:35 PM -0800 4/1/05, Subha wrote:
>Hi  Steve,
>single IKEv2

yes, but as Tero noted, it would be a mistake, in general, to use 
IKEv2 with 2401.

>(3) Tunnel Outer Header Source IP, Tunnel Outer Header Destination 

yes, one needs to negotiate all three, if you did all three. Again, 
there seems to be very little motivation for using BOTH AH and ESP, 
vs. just using ESP with an appropriate integrity algorithm.

>whether the peer supports RFC2401 or 2401-bis.

I would generally expect an implementation that supports IKEv2 to 
implement 2401-bis, given certain defaults adopted by IKEv2, e.g., 
ESN for AH or ESP.

Steve

---

From: "Subha" <[email-masked]>
Date: Wed, 6 Apr 2005 15:48:12 -0700

Hi ,

If AH+ESP between the same two gateway devices is not 
actually providing any extra crypographic protection,
why have it at all. 

2401bis could have simply removed that combination. 

Also, my understanding is that having AH over ESP provides
additional protection on the tunnel header, which is otherwise
not handled by ESP with Auth. 

Thanks,
Subha

---

From: Stephen Kent <[email-masked]>
Date: Thu, 7 Apr 2005 03:58:22 -0400

At 3:48 PM -0700 4/6/05, Subha wrote:
>Hi ,
>
>If AH+ESP between the same two gateway devices is not actually 
>providing any extra crypographic protection,
>why have it at all.

it is largely a holdover from the early days. Note that we do not 
mandate support for AH any more, so there is no mandate to support 
the combination of AH+ESP.

>2401bis could have simply removed that combination.

we DID remove mandatory support for this combination.

>not handled by ESP with Auth.

yes, it does provide protection for the tunnel header, but as we have 
discussed on this list in the past, this protection is only rarely of 
use. Remember, in most cases, the tunnel header is discarded upon 
arrival, so its integrity is is little importance in most cases.

Steve

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 7 Apr 2005 13:53:03 +0300

> actually providing any extra crypographic protection,

True.

> 2401bis could have simply removed that combination. 

2401bis did remove it as a single concept.

The reason there is still the forwarding step is when you have
following case:

Host A <-------> SGW <-----> Host B

and where Host A needs to authenticate all his packets with tunnel
mode AH to the SGW before it can get through it (i.e. the Host A might
be somewhere inside the internet, and the SGW is the corporate
firewall, requiring authentication before letting any traffic in, but
as all traffic is also protected by ESP end to end, AH is enough for
the SGW). In addition to that Host A needs to create transport mode
ESP to connect to the Host B (lets say financial server or something).

Now the Host A do need to have both AH and ESP applied to the packet,
and his policy would be:

Host A, Host B, ESP or IKE use tunnel mode AH to SGW
Host A, Host B, any traffic use transport mode ESP, reforward to IPsec

> not handled by ESP with Auth.

If the ESP is in tunnel mode the external header is thrown away, so
the protection AH offers to it is not useful. 
-- 
[email-masked]